長久以來,咱們致力於作到三件事: 實踐指南、減小模板代碼和簡化任務流程,咱們但願幫助開發者們集中精力專一在真正須要考慮的邏輯中去。Jetpack 爲此而生,它所包含的庫、工具和指南,能夠幫助您更輕鬆地編寫高質量的應用。android
Jetpack 和 AndroidX 有什麼關係呢? Jetpack 中全部庫都使用 AndroidX 做爲包名,咱們把 AndroidX 做爲一個開發、測試和發佈 Jetpack 庫的開源工程。bash
在 2018 年的 I/O 大會上咱們宣佈了把 Support Library 重構至 AndroidX 命名空間的計劃。在 Support Library 28,咱們完成了重構,而且發佈了 AndroidX 1.0。爲了可以享受 Jetpack 所帶來的便利,您須要將舊的 Support Library 遷移至 AndroidX。app
您可能會想: 既然 AndroidX 只是 Support Library 28 的重構,那爲何要遷移呢? 關於這個問題,咱們有下面幾個理由:ide
在開始遷移以前,爲了使接下來的工做能夠更加順暢平滑,咱們但願您能夠作到如下幾點:工具
在整個遷移步驟中,咱們將着重於解決錯誤,使您的應用編譯並經過全部測試。測試
下面是遷移工做的流程示意圖,雖然步驟很多,可是本文會對其中的每一步都作出說明:gradle
首先,咱們但願您把當前的 Support Library 依賴升級至版本 28。若是您從早期版本的 Support Library 進行遷移,可能會在須要修改命名空間的同時遭遇 API 不兼容的問題; 而 Support Library 28 的 API 與 AndroidX 之間只有命名空間上的不一樣。因此咱們建議,先嚐試將 Support Library 升級至版本 28,處理過全部 API 變動,而且確保編譯經過後,再進行下一步,這樣所作的修改是最少的。google
接下來須要作的是開啓 Jetifier。Jetifier 能夠幫助您遷移第三方依賴庫的依賴至 AndroidX。正如字面意思所說,Jetifier 會修改這些第三方依賴庫的代碼,從而使其與使用 AndroidX 的工程兼容。不過 Jetifier 不會修改您的源碼和自動生成的代碼,所以不用擔憂它會形成額外的不良影響。spa
開啓 Jetifier 十分的簡單,您只須要在 gradle.properties 文件中加入 "android.useAndroidX = true" 和 "android.enableJetifier = true" 便可。"useAndroidX" 設置用於開啓 AndroidX 庫的自動導入,當您自動補全或導入依賴庫時,會自動導入 AndroidX 庫。3d
當您開啓 Jetifier 以後,就要着手升級第三方依賴庫到兼容的版本。在您真的開始遷移以前,最好把全部依賴升級到最新。
爲何要這麼作? 其實咱們本身就在這方面 "栽過跟頭",咱們有一個演示應用: Plaid,它依賴了圖片加載庫 Glide,咱們原本打算使用 Plaid 來演示如何遷移應用至 AndroidX,但當咱們在沒有檢查 Glide 依賴庫版本就開始遷移時,咱們遭遇了一堆編譯錯誤。檢查後才發現,當時依賴的那個版本的 Glide 沒法兼容 AndroidX。
而當咱們把 Glide 和其餘依賴庫版本都升級後,再作遷移工做,就沒有再出現相同的錯誤。因此,建議在開始遷移前,先檢查和升級應用的第三方依賴,新版本的第三方庫可能已經兼容 AndroidX。因爲Jetifier 不會幫您遷移自動生成代碼的依賴庫,因此您仍是須要本身檢查這類依賴是否兼容 AndroidX。
若是跳過了前面兩步,您可能會遇到一些問題:
這一步開始前,您應該完成了前面三個步驟: 升級 Support Library 到 28 版; 開啓 Jetifier; 升級和檢查第三方依賴庫。肯定這些都沒問題後,咱們終於能夠開始真正的遷移工做了。這一步有如下三個方法供您參考:
咱們在 Android 3.2 穩定版中加入了 "Migrate to AndroidX" 選項,方便你們遷移。您能夠在 "Refactor" 菜單中找到 "Migrate to AndroidX" 選項:
這個按鈕的功能,就是遷移源碼中的依賴到 AndroidX,理想狀況下,它會幫您完成絕大部分工做。
咱們也意識到有些團隊使用的不是 Android Studio,並且也會有一些應用的結構過於複雜,使咱們的工具沒法生效。
因此還有兩種選擇,其中之一即是使用 bash 腳本中的 grep 和 sed 命令。在介紹如何使用腳本進行遷移以前,咱們要特別感謝 Dan Lew 爲咱們提供了這個工具。
您能夠經過短連接: goo.gle/androidx-migration-script 去到腳本源碼的 GitHub 頁面,在那裏您也能夠找到更多的社區貢獻內容。
腳本的工做原理並不複雜,以下所示,您須要手動作的是配置好類型映射表 "androidx-class-mapping.csv" 和工程路徑地址,而腳本中真正有效的部分,就只是 grep 命令後跟着一個 sed 命令來替換工程中導入的包名:
因爲腳本的處理十分簡單粗暴,因此可能會在某些狀況下形成一些錯誤。使用這種方式必定要本身內心有數。
另外一個選擇,是人工進行遷移工做。在 遷移到 AndroidX 中,您能看到前文提到過的 Support Library 與 AndroidX 的類型映射關係表。以下圖,有了這個映射關係表,您就能夠根據具體狀況進行替換:
這一步作完以後,只要您從新編譯工程,而且修復那些遷移工做中損壞的測試,就能夠得到一個基於 AndroidX 的工程。可喜可賀!
固然,真實的狀況每每不會那麼一路順風。下面咱們收集了一些遷移過程當中常見的問題,但願能幫到您。
如下圖爲例,咱們看到這裏依賴的仍然是 Support Library,其中 drawerLayout 和 recyclerview 的版本是用一組變量設置的:
遇到這種狀況時,自動遷移不會理會您以前的變量配置,它會直接把這些庫替換成一個肯定的 AndroidX 版,若是您仍然想要使用變量管理這些庫的版本號,就須要手動把 AndroidX 的依賴庫版本改成使用變量設置。
自動遷移工具也不會修改您的混淆文件和構建腳本。若是這些文件中包含相關的包名,您須要手動去把它們改好。
咱們前面有提到,必定要在一個新的分支中處理遷移工做,關於這點還有一些和你們分享的內容。
因爲遷移工做會修改大量的文件,因此咱們建議減緩或中止手頭的開發工做。雖然要求整個開發團隊停工聽起來十分離譜,可是這樣確實能夠大大減小可能產生的合併衝突。
退而求其次的話,若是條件容許,最好能安排一些人手在一個單獨的分支上專一於遷移的工做。與此同時,也要向團隊中的其餘成員預警即將到來的合併衝突。
在遷移依賴時,要專一於錯誤的修改,以編譯成功和經過全部測試爲首要目標。不要在遷移的同時進行重構或者引入新的功能。
當您運行完自動遷移功能後,您可能會發現新的依賴庫中既有穩定版,又有 Alpha 版。這其實取決於咱們最新發布的版本。您須要手動修改這些依賴庫的版本,以知足本身工程的特定須要。
咱們總結了一些與本文相關的文檔放在最後,來方便您回顧和查找。
AndroidX 概覽 包括: AndroidX 總覽、遷移指南以及 Support Library 到 AndroidX 庫穩定版和 Alpha 版的映射關係表。若是您想要使用腳本處理遷移,這裏也提供映射關係表的 CSV 文件。
咱們有一篇文章介紹 Kotlin & Jetpack 實踐技巧: 把 "格子衫" 改造得更時尚,描述了示例工程 Plaid 遷移至 AndroidX 的過程。在這篇文章中,咱們說明了遷移的步驟,遇到的問題和對應的解決方案。
咱們還提供了 問題追蹤頁,您能夠在這個頁面看到咱們正在解決的問題,也能夠經過左上角的按鈕創建新的問題給咱們。
祝你們都能順暢地遷移至 AndroidX!
您也能夠經過下面視頻回顧 2019 Android 開發者峯會演講 —— 是時候遷移至 AndroidX 了!