瞎翻的，后来翻烦了，直接用 Google 翻译机翻的，英语好的还是看原文吧。
原文地址：Picking your compileSdkVersion, minSdkVersion, and targetSdkVersion
可能你刚开发完一个 app ，几个月后 Android 的新版本就发布了，那么，这对于你的 app 来说意味着什么呢？是否一切都完蛋了？
当你了解到向前兼容是 Android 的重大关注焦点时一定很开心，当用户升级 Android 版本时，现有的针对以前 SDK 开发的 app 不会崩毁。这就是 compileSdkVersion, minSdkVersion, 和 targetSdkVersion 发挥作用的地方: 它们分别控制着哪些 API 是可用的，需要的 API 等级是多少，以及采用的兼容模式是什么。
compileSdkVersion
compileSdkVersion 是你告诉 Gradle 使用哪个版本的 Android SDK 来编译应用程序的方法。使用该级别中添加的任何新 API 的要求是使用新的 Android SDK。
要强调的是改变你的 compileSdkVersion 并不会改变运行时的表现。当然，新的编译器 warnings/errors 可能会出现。你的 compileSdkVersion 并不包含在你的 APK 中，它纯粹是用在编译时的。（你真的应该修复那些 warnings，它们被添加是有原因的！）
因此，强烈建议你总是编译最新的 SDK，现有代码上新的编译检查会给你带来诸多好处，避开新的过时 API，准备好使用新的API。
注意，如果你使用 Support LIbrary，使用最新的 Support LIbrary 要求使用最新的 SDK 编译。举个例子，使用 23.1.1 Support Library，你必须使用最低 23 的 compileSdkVersion (第一个小数点前的数字要对上！）。一般来说，新版本的 Support LIbrary 会随着新版本 platform 的发布而发布，为新添加的API和新功能提供兼容性垫片。
minSdkVersion
如果说 compileSdkVersion 设置可供你使用的最新 API，那么 minSdkVersion 就是你的 app 的下限。minSdkVersion 是 Google Play 商店用来确定可以在用户的哪些设备上安装应用程序的信号之一。
它在开发过程中也起着重要作用：默认情况下，lint 会针对您的项目运行，当您使用任何 高于你的 minSdkVersion 的 API 时会发出警告，帮助您避免试图调用不存在的API的运行时问题。当仅在较新的平台版本上使用API时，在运行时检查系统版本是一种常见的技术。
请记住，你使用的库（如任何 Surpport LIbraries 或 Google Play 服务）可能有自己的minSdkVersion。你的 app 的 minSdkVersion 必须至少与依赖项的 minsdksversion 一样高，如果你有需要4、7和9的库，那么你的 minSdkVersion 必须至少为9。在极少数情况下，你希望继续使用 minSdkVersion 版本高于你的 app 的库（并处理所有边缘情况/确保该库仅用于较新的平台版本），您可以使用工具：overrideLibrary marker，但确保彻底测试！
在决定 minSdkVersion 时，您应该考虑仪表板上的统计数据，它可以让您全面了解过去 7 天内访问过 Google Play 商店的所有设备——这是您在 Google Play 上发布 app 时的潜在受众。支持额外3%的设备是否值得确保最佳体验所需的开发和测试时间，最终取决于业务决策。
当然，如果一个新的 API 是你整个 app 的关键，那么这会使关于 minSdkVersion 的讨论变得容易一些。请记住，即使 14 亿台设备中的 0.7% 也是很多设备。
targetSdkVersion
然而，这三个中最有趣的是 targetSdkVersion。 targetSdkVersion 是 Android 通过不应用行为更改来提供前向兼容性的主要方式，除非 targetSdkVersion 已更新。这允许您在处理行为更改之前使用新的 API（就像您确实更新了 compileSdkVersion 一样？）。
targetSdkVersion 暗示的许多行为更改都直接记录在 VERSION_CODES 中，但所有血腥细节也列在每个版本的平台亮点中，并在 API 级别表中很好地链接。
例如，Android 6.0 更改讨论了目标 API 23 如何将您的 app 转换为运行时权限模型，而 Android 4.4 行为更改详细说明了目标 API 19 或更高版本如何更改使用 set() 和 setRepeating() 设置的警报的工作方式。
由于某些行为变化对用户来说非常明显（菜单按钮的弃用、运行时权限等），因此更新以针对最新的 SDK 应该是每个 app 的高优先级。这并不意味着您必须使用引入的每一个新功能，也不应该在没有测试的情况下盲目更新您的 targetSdkVersion — 请在更新您的 targetSdkVersion 之前进行测试！您的用户会感谢您。.
Gradle and SDK versions
所以设置正确的 compileSdkVersion、minSdkVersion 和 targetSdkVersion 很重要。 正如您可能想象的那样，在使用 Gradle 和 Android Studio 的世界中，这些值通过包含在模块的 build.gradle 文件中（也可通过 Android Studio 中的 Project Structure 选项获得）集成到工具系统中：
android {
compileSdkVersion 23
buildToolsVersion “23.0.1”
defaultConfig {
applicationId “com.example.checkyourtargetsdk"
minSdkVersion 7
targetSdkVersion 23
versionCode 1
versionName “1.0”
}
}
compileSdkVersion 是编译时的事情（谁会猜到！），是与您的构建工具版本一起的 android 设置之一。 其他两个稍有不同，因为它们是在构建变体级别声明的——defaultConfig 是所有构建变体的基础，您将默认值放在哪里，但您可以想象一个更复杂的系统，其中您的特定版本 例如，应用程序具有不同的 minSdkVersion。
minSdkVersion 和 targetSdkVersion 也与 compileSdkVersion 不同，因为它们包含在您的最终 APK 中——如果您要查看生成的 AndroidManifest.xml，您会看到如下标签：
<uses-sdk android:targetSdkVersion=”23" android:minSdkVersion=”7" />
您会发现，如果您手动将其放入清单中，当您使用 Gradle 构建时它会被忽略（尽管其他构建系统可能肯定会依赖它）。
Putting it all together
如果您通过粗体注释进行操作，您会注意到三个值之间的关系：
minSdkVersion <= targetSdkVersion <= compileSdkVersion
这在直觉上是有道理的——如果 compileSdkVersion 是你的“最大值”而 minSdkVersion 是你的“最小值”，那么你的最大值必须至少与最小值一样高，而目标必须介于两者之间。
理想情况下，这种关系在稳定状态下看起来更像这样：
minSdkVersion (lowest possible) <=
targetSdkVersion == compileSdkVersion (latest SDK)
您将以较低的 minSdkVersion 吸引最大的受众，并通过使用最新的 SDK 进行定位和编译——这是#BuildBetterApps 的好方法。