Android：compileSdkVersion、buildToolsVersion、minSdkVersion与targetSdkVersion

Android开发常用的几种 Version

compileSdkVersion
buildToolsVersion
minSdkVersion
targetSdkVersion

下面一一详细介绍这些 Version 所代表的意义

compileSdkVersion

顾名思义，就是用来编译源代码所使用的 API 版本。也就是说在写代码的时候，所引入的 android.jar 的版本。这个只是编译期间使用，并不是真实设备上运行 APK 的 API Version。真实设备运行的永远是烤制的 ROM 的版本。

那么什么是编译期间使用的 API 版本呢，我举个例子说明：

假如 API 19 有一个这样的方法：

public void print(String message) {
    Log.d("xxx", message);
}

然后 API 20 对这个方法进行的改进

public void print(String message, int option) {
    if (option & 1 == 1){
        Log.d("xxx", message);
    }
}

那么当你写代码调用这个 print(message) 的方法的时候，如果 compileSdkVersion 指定的是 19，那么编译就不会出现问题；而如果 compileSdkVersion 指定的是20，那么就会编译不过，并且 AndroidStudio 会给一个错误的提示。

当然了，事实上 Google 是不会这样暴力的直接将一个方法进行修改或删除，通常是会在原方法标记一个 @Deprecated 用来警告开发者这个方法被废弃了，当前 API Version 是可以正常调用的，但是也许将来的某个版本会直接删除。然后再指向一个新增的用于替代的方法。此时虽然我们还能继续使用该方法，但是 AndroidStudio 会给一个警告。

至于为什么 compileSdkVersion 并不会影响真实运行的 API Version 呢，因为 android.jar 只是为了让我们写的代码能够成功生成 class 文件，真实运行的其实是设备上的 ROM 包，我们可以看到 android.jar 有很多类其实就只是一个空方法，并没有具体的实现。比如 BaseDexClassLoader 类。

buildToolsVersion

顾名思义，就是构建工具的版本。所谓的构建工具其实就是指我们 sdk 下面的 build-tools 目录。我的 build-tools 目录就有以下的版本

23.0.3 25.0.0 25.0.2 26.0.2 27.0.3 28.0.2

这个 build-tools 里面包含了我们打包构建所需要的一些工具，比如：

aapt: Android Asset Packaging Tool，也就是资源打包工具，将资源文件打包成 R.java 以及 .arsc资源文件
aidl: 将 aidl 文件编译为 java 接口类
dx: 将 class 文件打包成 dex 文件
apksigner: 将打包成的 apk 文件进行签名
zipalign: 将签名后的 apk 文件进行 zip 对齐，加快访问速度

buildToolsVersion 就是指定这些构建工具的版本

minSdkVersion

顾名思义，就是最小支持的 API 版本，这个值直接决定了你的 APK 是否能够安装在设备上。

比如说，minSdkVersion 指定为 19，而设备的 API Version 为16，那么安装此 APK 文件就会失败。

在编写代码的时候，如果 minSdkVersion 指定为 19，而要引入的一个方法是 API 20 才新增的，此时你把 compileSdkVersion 设置为 20，代码能够正常编译，但是 AndroidStudio 会给一个警告。

这是因为，minSdkVersion 指定为 19，也就会有 API 19 的设备安装此 APK，但是运行到那个 API 20 才引入的方法时，因为 API 19 是没有这个方法的，就会产生 MethodNotFoundException 异常而崩溃。

这个情况只能我们手动的进行差异化处理了：

if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.KITKAT_WATCH) {
    // 大于 20，直接调用方法
    invokeMethodWhenAPIGreatThan20();
} else {
    // 小于 20，只有自己手动实现或者调用其他方法
    invokeMethodCustom();
}

通常来讲，如果你把 minSdkVersion 设置得足够低，那么你的 APK 就能尽量地覆盖市场上大部分的设备，但是因为低版本的 API 缺少很多高版本新增的高效工具、或者存在很多在低版本存在的缺陷却在高版本解决了的，那么你就需要自己去实现这些高效工具或者自己去想办法解决这些缺陷。如果你想用高版本的方法，把 compileSdkVersion 设置得足够高，那么你的代码中就会大量充满上面的处理兼容性的代码。

这里我们也可以得出一个结论，就是 minSdkVersion 一定比 compileSdkVersion 小。想想也就明白了，minSdkVersion 都指定了最小可安装的版本了，如果 compileSdkVersion 还比 minSdkVersion 小了，那么编译出来的 APK，谁还能用啊？

targetSdkVersion

这里面所有的版本，也许就是 targetSdkVersion 最难理解了。用官方的描述来讲的话：

targetSdkVersion is the main way Android provides forward compatibility

什么意思呢？ targetSdkVersion 是 Android 系统提供前向兼容的主要手段。随着 Android 系统的升级，某个系统的 API 或者模块的行为可能会发生改变，但是为了保证老 APK 的行为还是和以前兼容。只要 APK 的 targetSdkVersion 不变，即使这个 APK 安装在新 Android 系统上，其行为还是保持老的系统上的行为，这样就保证了系统对老应用的前向兼容性。

回到最开始的例子，假如 API 19 有一个这样的方法：

public void print(String message) {
    Log.d("xxx", message);
}

在 API 20 的时候，如果 google 想改变这个方法的行为，除了上面所说的方式：给这个方法加一个 @Deprecated，然后指向一个新增的方法外。还可以用另外一种方式来做

public void print(String message) {
    final int targetSdkVersion = ctx.getApplicationInfo().targetSdkVersion;
    if (targetSdkVersion >= android.os.Build.VERSION_CODES.KITKAT_WATCH) {
        MyLog.d("xxx", message);
    } else {
        Log.d("xxx", message);
    }
}

首先获取我们配置的 targetSdkVersion，如果大于等于 20，就调用新的打印方法，否则就用旧的打印方式。

这样的话，即使我们设备的 API Version 是 20，但是只要设置的 targetSdkVersion 指定的是 19，那么还是会使用旧的方式而非新的方式。这就是前向兼容性。也可以说 targetSdkVersion 指定了我们希望的 API 所呈现的版本形式，但是只能向前。