minSdkVersion、compileSdkVersion、targetSdkVersion

我们在创建App的时候经常会设置这几个参数

android {
    compileSdkVersion 29
    buildToolsVersion "29.0.2"
    defaultConfig {
        applicationId "com.szy.yishopcustomer"
        minSdkVersion 16
        targetSdkVersion 29
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }
}

平时这些参数都是自动设置的，我们只需设置 minSdkVersion，即最低SDK版本，然后 compileSdkVersion 和 targetSdkVersion 可能是一致的，具体这几个值是什么意思？下面分别来说一下

minSdkVersion

最好理解的就是 minSdkVersion 了，就是我们的 app 能够运行的最小版本，如果选择16，那么就是 Android 4.1 以及以上的设备才能运行我们app，如果小于这个版本，那么抱歉运行不了，我们不支持。这是应用程序支持 api 的下限。这也是应用商店判断这个应用是否能运行在设备上的一个依据之一

在开发中也会根据这个下限去判断，是否可以用某个 api 方法，如果是下限之下的那么就会有警告，避免调用一些在新的版本已经改变或者过时的方法

当我们引用了第三方的库，如果某几个库的 minSdkVersion 分别是 API5，API10，API16 的方法，那么我们的minSdkVersion最少就是16

对于 minSdkVersion 的选择，我们应该看各个api的占比，不过因为基数太大了（十几亿）所以就算是 0.7% 也是个天文数字，所以我们需要根据自己应用的受众，以及是否需要适配低版本的需要，一般说来我们适配 4.1 以上，即 minSdkVersion=16，不过还要根据自己的实际情况，去选择相应的版本号

compileSdkVersion

compileSdkVersion 是我们告诉 Gradle，我们是用哪一版本的 Android Sdk 去编译程序的，可以使用这个版本的 API，比如我们使用的是 7.0 的版本，compileSdkVersion = 24，那么我们对于拍照裁剪图片等功能的操作，就可以使用FileProvider了

我们需要注意的是：我们改变 compileSdkVersion 的版本号，本质上改变不了我们程序的运行，虽然可能会报错误❌或者警告⚠️，但 compileSdkVersion 只会在编译期间起作用，因为环境是 compileSdkVersion 这个版本的SDK，所以你可以用一些这个版本的API，但是只是 IDE 给你的便利性帮助而已，帮助你检测代码，避免使用一些弃用的API。就算你用个低版本的 compileSdkVersion，你依然可以那么写，但是可能会报错，报警告，但是你强制打包，其实也是没有问题的。IDE 只是个工具，他的环境也只是工具的环境，不代表你应用运行时的表现

所以希望大家用最新的 sdk 版本作为开发环境，compileSdkVersion 设置成最新的，这样我们可以使用到最新 SDK 的 API 方法和机制

如果我们使用了比如V4，V7包，有没有发现必须和 compileSdkVersion 的版本相匹配，比如我们 compileSdkVersion = 26，那么V4，v7的版本也要相应的是26.xx.xx，首位的 26 必须一致，后两位没有要求，就是说明编译所依赖的 SDK 和依赖包必须是统一版本，不然两个不兼容，编译会通不过。同时也是为了使用该版本的新特性

targetSdkVersion

看到 targetSdkVersion 我们满满的疑问

• 什么是目标设备SDK版本？
• 是和minSdkVersion相对应的上限吗？
• 如果我运行在比targetSdkVersion高的设备上，会出现什么？
• 如果是比targetSdkVersion低的设备呢？

首先 targetSdkVersion 是 android 向前兼容的主要方式，怎么说呢？官方是这样说的：

除非更新 targetSdkVersion，否则不改变应用的行为。 这允许您在处理行为更改之前使用新的API（如您更新过的compileSdkVersion）

简单的说就是你的应用已经针对这个版本的手机，做了充分的兼容性处理和测试性处理，比如

if(Build.VERSION.SDK_INT >= 23) { ... } 

这样针对不同的SDK版本做不同的处理，这就说明我们不能随便的改变 targetSdkVersion 的值，我们必须做好充足的兼容性处理和测试处理才行

第一个问题：

在 Android 4.4 (API 19）以后，AlarmManager 的 set() 和 setRepeat() 这两个 API 的行为发生了变化。在 Android 4.4 以前，这两个 API 设置的都是精确的时间，系统能保证在 API 设置的时间点上唤醒 Alarm。因为省电原因 Android 4.4 系统实现了 AlarmManager 的对齐唤醒，这两个 API 设置唤醒的时间，系统都对待成不精确的时间，系统只能保证在你设置的时间点之后某个时间唤醒。虽然api的名字没有改变，但是功能结果已经发生改变，我们设置 targetSdkVersion 为16，Android4.4之前。那么我们在Android4.4之后运行会出现什么呢？难道就不能用了吗？不准确了吗？
当然不是，系统通过 targetSdkVersion 来保证 Android 的向前兼容性，在 Android4.4 之后的设备上，系统会判断你的 targetSdkVersion 是否小于19，如果小于的话，那就按照 19 之前的api 方法，如果大于等于19，那么就按照之后的 api 方法来走，保证了程序运行的一致性。也就是向前兼容性

targetSdkVersion 的大部分更新变化都会记录在VERSION_CODES，所有的细节也会在每个版本的平台亮点写明

targetSdkVersion 保证的是 api 的一致性
所以一般 minSdkVersion < targetSdkVersion <= compileSdkVersion
不随意更改 targetSdkVersion，更改 targetSdkVersion 必须做好兼容。

够用到 targetSDK 中最新的 API 和最酷的新功能，但你又不得不向下兼容到 minSDK ，保证这个区间内的设备都能够正常的执行你的 app 。换句话说，你想使用 Android 刚刚推出的新特性。但这对于你的 app 又不是必须的。你就能够将 targetSDK 设置为你想使用新特性的 SDK 版本号，minSDK 设置成低版本号保证全部人都能够使用你的app

举个栗子：假如你想给你的 app 增加大量的手势操作（sdk 7才引入的），然而这些手势操作能够被 Button 或 menu 等取代，在这样的情况下，手势操作就是一个额外的加分功能，而不是一个必须的功能，因此你就须要把 targetSDK 设置为7，把minSDK设置为3（这是举个栗子，如今没人还在用这么老的设备了）这样即使是使用老设备的用户也能够用你的 app 了

然后你所要做的就是要在代码里推断版本号，假设是大于等于 7 的版本号中就使用手势操作，小于 7 的版本号中就使用 button 等取代，这样使用了新手机的用户就能够体验到你 app 中酷炫的新功能了