minSdkVersion、compileSdkVersion、targetSdkVersion

文章目錄

• ​​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