AndroidX 的前世此生

本文章首發於公衆號 Android丨Kotlin，歡迎關注！

對於在上一期《Jetpack 是什麼？》的推送中，根據 Google 官方對 Jetpack 的定義，咱們提煉出兩個核心點：

1. 它是一套組件庫。

2. 使用 Jetpack 能夠幫助咱們在不一樣的 Android 版本和不一樣的設備上，實現行爲一致的工做代碼。

同時，我也詳細的對 Jetpack 85個組件庫進行了分類和標記，一共分紅了 7 個大類，幫助你們從全局的角度，理解這些組件庫都是幹什麼的，方便咱們快速的在不一樣場景下，選擇合適的組件，幫助本身完成對應功能的實現。

沒有看過的同窗們，能夠去翻翻以前的文章哦～

今天咱們來聊聊定義中的第二個問題：爲何 Jetpack 能夠幫助咱們在不一樣的 Android 版本和不一樣的設備上，實現行爲一致的工做代碼？

Jetpack、AndroidX 以及 Support 庫的關係

Jetpack 和 AndroidX 是同一個東西，從產品的維度它叫作 Jetpack，從技術的維度它叫作 AndroidX。目前 Jetpack 中全部的組件庫的包名都是以 AndroidX 開頭的。

在 18 年的 Google I/O 上，Android 團隊首次向你們介紹了新的支持庫：AndroidX 的 Alpha 版本，能夠說 AndroidX 的出現就是爲了解決長久以來 Support 庫混亂的問題，你也能夠把 AndroidX 理解爲更強大的 Support 庫。

Support 庫是幹什麼的？

早以前的 Android 更新迭代是，全部的功能更新都是跟隨着每個特定的 Android 版本所發佈的，例如 Fragment 是在 Android 3.0 更新的，Material Design 組件是在 Android 5.0 上更新的，因爲 Android 用戶龐大，每一次 Android 更新都沒法覆蓋全部用戶的，同時由於手機廠商衆多，但支持有限，也沒法爲本身生產的全部設備保持迭代到最新的 Android 版本，因此用戶所持有的設備上 Android 版本是層次不齊的。

從技術的角度來講，由於用戶的設備版本不一致，致使 Android 工程師在維護項目的時候，會遇到不少難以解決的問題。

爲了解決這些因爲 Android 版本不一致而出現的兼容性問題，Google 推出了 Support 庫。

Support 庫是針對 Framework API 的補充，Framework API 跟隨每個 Android 版本所發佈，和設備具備強關聯性，Support API 是開發者自主集成的，最終會包含在咱們所發佈的應用中， 這樣咱們就能夠在最新的 Android 版本上進行應用的開發，同時使用 Support API 解決各類潛在的兼容性問題，幫助開發者在不一樣 Android 版本的設備上實現行爲一致的工做代碼。

Support 庫有什麼弊端？

最先的 Support 庫發佈於 2011 年，版本號爲：android.support.v4 ，也就是咱們所熟知的 v4 庫，2013 年在 v4 的基礎上，Android 團隊發佈了 v7 庫，版本號爲：android.support.v7，以後還發布了用於特定場景的 v八、v1三、v1四、v17。

若是是前幾年剛開始學習 Android 的同窗們，必定都對這些奇怪的數字很疑惑，四、七、八、1三、1四、17 到底都是什麼意思？

拿第一代支持庫 v4 舉例，最初本意是指：該支持庫最低能夠支持到 API 4 的設備，v7 表示最低支持 API 7 的設備，但隨着 Android 版本的持續更新，API 4 以及 API 7 的設備早就淘汰了。

在 2017 年 7 月 Google 將全部支持庫的最低 API 支持版本提升到了 API 14，但因爲包名沒法修改，因此仍是沿用以前的 v四、v7 命名標準，因此就出現了 Support 庫第一個沒法解決的問題：版本增加混亂。

與此同時 Support 庫還面臨一個很是嚴峻的問題：架構設計自己致使的嚴重依賴問題。 最先的 Support 庫是 v4，v7 是基於 v4 進行的補充，由於 v四、v7 太過龐大，功能集中，因此若是想要開發新的支持庫，也只能在 v四、v7 的基礎上進行二次開發，比方說咱們後期經常使用的，RecyclerView、CardView 等等。

這樣就會產生很嚴重的重複依賴的問題，在不管是使用官方庫，仍是第三方庫的時候，咱們都須要保持整個項目中 Support 庫版本一致，我相信不少人都在這個問題上踩過坑，雖然仍是有辦法解決這個問題，但無形中增長了不少工做量。

咱們都知道 「組合優於繼承」 這句話，但 Support 庫在最初的架構設計上，卻採用了重繼承輕組合的方式，我猜這多是由於開發 Support 庫的人和開發 Framework API 的是同一批人有關，Framework API 裏有種各類繼承邏輯，例如咱們經常使用的 Activity、Fragment、View。

雖然在後期 Google 嘗試拆分 Support 庫，例如推出了獨立的支持庫：support:design、support:customtabs 等，但並不能從根源解決依賴的問題。

Jetpack 的出現

因此爲了完全解決這兩個致命的問題：

1. Support 庫版本增加混亂

2. Support 庫重複依賴

Google 重寫了 Support 庫，推出了新的 AndroidX，AndroidX 將原有的 Support 庫拆分爲 85 個大大小小的支持庫，拋棄了以前與 API 最低支持相關聯的版本命名規範，重置爲1.0.0，而且每個庫在以後都會按照嚴格的語義版本控制規則進行版本控制。

同時經過組合依賴的方式，咱們能夠選擇本身須要的組件庫，而不是像 Support 同樣所有依賴，必定程度上也減少了應用的體積。

到這裏，若是你理解了最先 Support 出現的目的，那你應該就會明白爲何 Jetpack 能夠幫助咱們在不一樣的 Android 版本和不一樣的設備上，實現行爲一致的工做代碼。

很重要的一點，就是它不會隨着特定的 Android 版本而更新，它是由開發者自主控制，同時包含在咱們所發佈的應用程序中。

若是 Jetpack 僅僅是針對 Support 庫的重構，那它並無了不得的，由於這只是 Google 解決了它自身由於歷史緣由所產生的代碼問題。

更重要的是 Jetpack 爲你們提供了一系列的最佳實踐，包含：架構、數據處理、後臺任務處理、動畫、UI 各個方面，無需糾結於各類由於 Android 自己而出現的問題，而是讓咱們把更多的精力放在業務需求的實現上，這纔是 Jetpack 真正了不得的地方。

例如想要安全異步的處理數據，如今有 DataStore；想要方便的實現依賴注入，如今有 Hilt；想要實現安全的頁面導航，如今有 Navigation；想要實現 MVVM 架構，有 LiveData、ViewModel 幫助你。

若是你像我同樣常常關注 Android 的官方文檔，你會發現，上面的解釋、例子、最佳實踐相較以前變得詳細了不少，同時更新也很是頻繁，若是你是一個 Android 新手，那麼去讀一遍 Android 的官方文檔對你入門很是有幫助，若是你是一名資深的 Android 開發，持續關注 Android 的官方文檔的更新，這樣纔不會被技術所淘汰。

若是說 Android 的前十年是憑藉着開源社區繁榮的生態而發展，那麼我認爲後十年 Jetpack 能夠幫助 Android 變得更好。

感謝你們收看本期的文章，能夠留言告訴我，關於 Jetpack 你想知道什麼？以後我會爲你們帶來更多有關 Jetpack 的文章。

若是本期的內容有幫助到你，但願能夠轉發、評論和點贊，讓更多人看到這篇文章，這也會對我有很是大的幫助。

感謝，咱們下期再見。