從Preference組件的更迭看Jetpack的前世今生

談到Jetpack，大家都以為是一堆框架，事實上它的內容要大的多，本文以大家熟知的Preference組件為切入點，逐步探究它的前世今生，

Preference作為設定畫面的標準實作，大家都不陌生，這個組件跟隨Android系統一同誕生，之后便不斷地變更，先是Support庫中出現了獨立版本，接著整合到了AndroidX中，最后在Android 10的時候完全廢棄了SDK版本，

1. Preference的設計

Preference組件的API設計得非常簡單、清晰，

• PreferenceActivity或PreferenceFragment管理畫面的生命周期和事件互動
• PreferenceScreen構建整個設定串列
• PreferenceCategory和Preference展示一組或單個設定條目

2. 落寞的SDK

Preference組件是Android 1.0發布就引入的元老級組件，那會RecyclerView還未推出，自然采用經典的ListView構建整個設定串列，

使用起來非常簡單，跟普通視圖的寫法并無二致，

<PreferenceScreen android:title="@string/my_preference_settings">
    <PreferenceCategory
        android:title="@string/my_preference_general" >
        <Preference
            android:fragment="com.android.settings.applications.ManageApplications"
            android:key="app"
            android:title="@string/my_preference_general_apps" />
    </PreferenceCategory>
    ...
</PreferenceScreen>

public class SettingsActivity extends PreferenceActivity {
    public void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        addPreferencesFromResource(R.xml.my_preference_layout);
    }
}

原理也不復雜：

1. PreferenceManager和PreferenceInflater負責決議Preference布局構建Preference實體樹
2. PreferenceScreen采用Preference實體樹創建PreferenceGroupAdapter實體，并系結到ListView視圖
3. Adatper#getView()回呼到各Preference組件的onBindView()去準備相應的View視圖

ListView的性能欠佳，不再適應復雜的設定畫面，尤其是內容眾多的系統設定App，

3. 混戰的Support庫

Support庫是為新API提供向后兼容性的支持庫，包含大量應用組件、視圖、Material Design等功能類，重新改寫的Preference組件也包含其中，

依據兼容API版本的不同，Support庫的分支眾多且凌亂，使用起來也愈發繁瑣和呆板，

V7包

Preference組件的變更首次出現在Support庫的V7包，主要是將SDK版本的Preference組件拷貝過來進行了重寫，

對外的API只是微調，區別大體集中在內部的實作細節上：

1. 不再提供專用的PreferenceActivity，只提供面向Fragment的專用類
2. 構建設定串列的PreferenceScreen改為性能更加優秀的RecyclerView來實作
3. 新增PreferenceViewHolder類，用以復用設定條目的視圖
4. Preference移除onBindView() API，新增onBindViewHolder()來向RecyclerView提供條目的視圖
   另外，針對實作變化較大的API，在原有命名上增加Compat字樣，比如PreferenceFragment改為PreferenceFragmentCompat，

使用的話需匯入額外依賴：

implementation 'com.android.support:preference-v7:28.0.0'

另外要注意的是Fragment里加載布局的API由addPreferencesFromResource()改為setPreferencesFromResource()，由于API只是微調，其他使用起來幾乎沒有變化，

public static class PrefsFragment extends PreferenceFragmentCompat {
    @Override
    public void onCreatePreferences(Bundle savedInstanceState, String rootKey) {
        setPreferencesFromResource(R.xml.preferences, rootKey);
    }
}

V14包

第二次變更發生在V14包，區別只是將命名里的Compat字樣去掉了，榷訓了和SDK版本的API差異，

比如：

• PreferenceFragmentCompat → PreferenceFragment
• SwitchPreferenceCompat → SwitchPreference
• PreferenceDialogFragmentCompat → PreferenceDialogFragment

匯入只需要細微調整即可：

implementation 'com.android.support:preference-v14:28.0.0'

V17包

隨著Android系統逐漸流行到TV等大屏設備，Google推出了Leanback導航模式，并引入到了V17中，Preference組件也針對Leanback模式進行了跟進，新增了一系列新組件，

4. 一統江湖的AndroidX

比如Support庫各分支下Preference組件在AndroidX下的對應關系：

? 使用也很方便，只需指定對應的包名和版本即可：

    def preference_version = "1.1.1"
    implementation "androidx.preference:preference:$preference_version"

AndroidX和原有Support庫的API對應關系，可以到官方的映射表里進行查詢：

• 包的關系：https://developer.android.com/jetpack/androidx/migrate/artifact-mappings

• 類的映射關系：https://developer.android.google.cn/jetpack/androidx/migrate/class-mappings

和Support庫到底有無區別？

將最核心的Preference類進行對比，可以發現：除了格式、書寫風格的差異以外，代碼邏輯幾乎完全一致，

再比如AndroidX里提供的PreferenceFragment類，其實作和Support庫的版本幾乎是一樣的，

AndroidX replaces the original support library APIs with packages in the androidx namespace. Only the package and Maven artifact names changed; class, method, and field names did not change.

像官方描述的那樣，AndroidX是針對Support庫的整合和替代，區別僅僅體現在倉庫的地址和包名，正因為此，AndroidX擁有清晰統一的版本管理，開發者能便捷和靈活地使用，

ROM開發需留意

之前，Preference組件等新API分散在Support庫的各個分支包里，源檔案也會集成到AOSP原始碼，ROM廠商可以修改，

比如V14包的Preference組件在AOSP原始碼的對應位置如下，

? /frameworks/support/v14/preference/src/android/support/v14/preference/

Android 9開始整合到了AndroidX里，但為了過渡，源檔案在AOSP原始碼里仍然保留，也就是我們仍然可以修改其原始碼，

? /frameworks/support/preference/src/main/java/androidx/preference/

Android 10開始全面轉向AndroidX，徹底廢棄Support庫的使用，AOSP原始碼里也不再集成源檔案，只提供了對應的AAR包，這也使得ROM廠商更改實作變得困難，需要額外留意，

? /prebuilts/sdk/current/androidx/m2repository/androidx/preference/

如何遷移至AndroidX

為了簡化向后兼容的開發作業，將Support庫全面遷移至AndroidX極為必要，設定如下的Gradle 插件標志即可，

• android.useAndroidX：Android 插件會使用對應的 AndroidX 替代Support庫
• android.enableJetifier：Android 插件會通過重寫其二進制檔案來自動遷移現有的第三方庫，以使用 AndroidX 依賴項

當然在AndroidStudio選單里也可以手動地遷移至AndroidX：Menu → Refactor → Migrate to AndroidX，

更詳細的遷移細節可以參考如下這篇文章：

https://www.jianshu.com/p/41de8689615d

AndroidX的構成

依照官方提供的AndroidX構成串列，我概括并制作了一張AndroidX的構成圖，

可以看到，實際上AndroidX在集成了Support庫的以外，還涵蓋了眾多知名的Jetpack框架，這些框架實際上來源于2017年發布的Android Architecture Components（AAC），

5. 短暫的AAC庫

Android App開發有很多痛點，包括Activity/Fragment生命周期的管理較為呆板，執行緒間資料傳遞的復雜，SQLite封裝的繁瑣等等，為了改善這些狀況并對App架構進行指導，Google IO 2017上發布了Android Architecture Components，簡稱AAC，

它包含了幾個較為經典的框架：

• Lifecycle
• LiveData
• ViewModel
• Room
• 其他的還有Paging、Navigation和WorkManager

同時Google還給Android開發者展示了推薦的應用架構，隨著Jetpack家族的日益壯大，先在看來這個架構圖略顯簡單，

AAC庫在完善的程序中，和Support庫一起，也逐步往AndroidX中遷移，并孕育出一個更大更強的概念Jetpack，

6. Jetpack又是何方神圣

短短一年后，Android Architecture Components就退出了舞臺，Google IO 2018上發布了全新的Jetpack開發套件，

• 核心的Architecture模塊涵蓋了熟知的框架，前身就是去年發布的AAC庫

• 以及從Support庫整合過來的包，比如Preference、Framgent、AppCompat等

• 除此之外，還包括KTX和Test工具包等

Android Jetpack is a set of libraries, tools and architectural guidance to help make it quick and easy to build great Android apps. It provides common infrastructure code so you can focus on what makes your app unique.

所以說，將Jetpack理解為一系列框架不夠準確，實際上它是包含了框架、KTX、開發工具和開發向導的開發套件，期望在多個層面提升與Android開發的效率，

• 提供Android App開發的最佳實踐
• 消除大量的樣板代碼，幫助開發者更輕松地撰寫優質應用
• 提供向后兼容性，在不同版本、不同配置的設備上提供一致性的開發體驗
• 改變混亂的散碎的版本管理

和AndroidX到底啥關系？

Jetpack開發套件的原始碼管理在AndroidX內，包括之前的Support庫，還有后來吸收的AAC庫等等，簡要繪制了一下Jetpack的演變圖，（畫著畫著，竟畫成了Android機器人的形象，哈哈）

非要總結下Jetpack和AndroidX關系的話，像fundroid大神描述的那樣比較貼切，

AndroidX是對SDK以外API的內部管理包，Jetpack則是對外宣傳的開發套件，

“AndroidX”的名字也很酷啊，那為什么不直接用它來進行宣傳?
個人的一些理解：

• “AndroidX”的命名過于抽象、不易理解，也沒有特別的含義
• “Jetpack”本意是噴氣背包、助推器的意思，它更能傳達助力開發效率騰飛的設計初衷，也易于理解和傳頌，再搭配上Android Logo塑造一個火箭機器人的形象，非常有趣和具備辨識度

7. Jetpack大事記

• 2011年3月，Support庫 V4包發布首個版本
• 2014年10月，Support庫新增RecyclerView，AppCompat支持
• 2015年8月，Support庫新增Preference支持
• 2016年2月，Support庫新增VectorDrawable支持
• 2017年5月17日，Google IO 2017 宣布推出Android Architecture Components
• 2017年9月21日，Android Architecture Components 1.0.0 beta版正式發布
• 2018年3月，Support庫代碼逐步整合至AndroidX
• 2018年5月8日，Android Architecture Components的代碼逐步遷至AndroidX
• 2018年9月21日，Google IO 2018 推出AndroidX，Jetpack開發套件一同發布，Support庫終結并轉向AndroidX
• 2019年5月7日，Jetpack CameraX 1.0.0 alpha版發布
• 2020年7月22日，Jetpack Hilt 1.0.0 alpha版發布
• 2021年3月10日，Compose 1.0.0 beta版發布

8. Googleの野望

Android的分支眾多、迭代太快，開發者疲于應對，Google一直在試圖改變這種混亂局面，從經典的Support庫，到變革的AAC庫，再到持續火爆的Jetpack套件，

與此同時，隨著Android系統愈加完善，SDK也趨于穩定，一年一度的OSV終將是小修小補，但行業的持續發展必將催生層出不窮的新理念、新技術，Google自然不會停下腳步，它將以更高頻次、更大范圍的動作去變革和應對，而這多將聚焦在SDK以外的領域，比如Jetpack、MAD等，

MAD，全稱Modern Android Development，是Google針對Android平臺的全新開發理念，它站在比Jetpack更高的視野，旨在通過語言、工具、發行格式、框架等多個層面去指導新型的Android開發，

在Jetpack套件以外MAD還囊括了諸多內容，包括：

• 持續改進的官方IDE，Android Studio
• Android平臺首推的Kotlin開發語言
• 先進的Android App Bundle發行格式
• 未來的UI開發方式Compose工具包

可以說，MAD是每個Android開發者都應了解和掌握的重要技術，后續我將解讀這個全新的開發理念，

參考資料

AndroidX的版本說明

Support庫的說明

Jetpack的組成

基于Android Architecture Components的應用架構指南

Jetpack與AndroidX的關系

推薦閱讀

Android 12上煥然一新的小組件：美觀、便捷和實用

Android 12上全新的應用啟影片面，還不適配一下？

全面復盤Android開發者容易忽視的Backup功能