我們在后臺和社區等各渠道收到了來自開發者們的反饋，也把一些開發者們常見的問題進行了簡單的收集和梳理，整理成這一篇關于現代 Android 開發的常見問題和解答，如果您在構建過程中有任何其他的問題，歡迎通過留言的方式讓我們知道。

問： 對初學者的 Jetpack 學習有哪些建議？

答： Jetpack 幫助開發者遵循現代 Android 的設計規范來構建 Android 應用。它是一個由多種庫構成的套件，可以幫助您輕松、快速地開發現代 Android 應用。其中包含的各種套件可以獨立使用，也可以結合在一起使用，您可以在實際的開發中體會到這個特點。Jetpack 還可以幫助您遵循一些最佳實踐、減少依賴樣板代碼，寫出在各種各樣的 Android 設備和版本都能正常運行的應用。

其實在設計和實現 Jetpack 之初，我們就已經充分考慮了如何讓初學者也能快速上手。您可以在 Android Jetpack 和 Android Jetpack 使用入門中找到學習 Jetpack 所需要的資源，比如文章、視頻、Codelab、在線培訓等。當您掌握到一定程度，可以嘗試閱讀 AndroidX/Jetpack 的源代碼來進一步提升自己。如果您在開發當中遇到了問題難以解決，我們也非常歡迎您向我們反饋，尋求我們的幫助。

Android Jetpackhttps://developer.android.google.cn/jetpack/

Android Jetpack 使用入門https://developer.android.google.cn/jetpack/getting-started

在線培訓https://developer.android.google.cn/courses/android-basics-kotlin/course

AndroidX/Jetpack 的源代碼https://github.com/androidx/androidx

問： 如何從 Android 界面中收集數據流？

答： 最安全同時也是最佳的方法是調用 repeatOnLifecycle 這個掛起函數。您可以在函數體內部的數據流當中進行收集。您也可以使用 flowWithLifecycle 這個數據流操作符，它們的實際效果是相同的。

使用這些 API 有哪些好處呢？最重要的一方面就是它們具有感知生命周期的能力。比如只有當您的應用正在前臺被用戶使用時，這些方法才會從 Flow 中收集數據流。而這種能力恰好是其他方法所不能實現的，因此我們向您推薦這兩種方法。

repeatOnLifecycle 和 flowWithLifecyclehttps://developer.android.google.cn/reference/kotlin/androidx/lifecycle/package-summary

問： 如何調試應用的性能問題？

答： 我們提供了一些專門用于優化應用性能的 Jetpack 庫，比如您可以用 Macrobenchmark 庫監測應用啟動、界面滾動性能或是監控掉幀時的性能表現。Benchmark 庫可以用來監測特定函數的 CPU 開銷。

對于上述的這些 Jetpack 庫，您既可以用持續集成的方式遠程測量應用的性能表現，又可以在本地執行，然后把結果顯示在 Android Studio 當中。另外，別忘了 Android Studio 本身就提供了許多性能分析工具供您使用。您可以用這些工具來衡量所關注的不同性能指標，從而有的放矢，找準改進的方向。

我們都有這樣的經驗： 調試應用的界面非常簡單，發現應用的性能問題也非常容易；但是到了真正要提升性能的時候，問題卻變得極其復雜。因為即使您獲得了性能指標，看到了統計數據，卻往往在如何排查和優化的問題上碰了壁。所以我們也提供了一些在線的指導，您可以通過這些具體的案例來了解性能調試調優的思路和方法，在調試自己的應用時可以較容易地找準分析性能數據的著眼點。

使用 Macrobenchmark 庫https://developer.android.google.cn/studio/profile/macrobenchmark-overview

Benchmark 庫https://developer.android.google.cn/jetpack/androidx/releases/benchmark

MAD Skills 系列文章

問： 使用 MotionLayout 還是 Compose？

答： 您可能會顧慮在構建新的應用或實現新功能時，是不是應該首選 MotionLayout 而不是 Compose。其實這樣對比不是很準確，因為 MotionLayout 和 Compose 屬于不同的視圖系統。 在理想情況下，我們推薦您使用 Compose，尤其是當您開發全新應用時更是如此。除非您的應用中包含了許多歷史遺留代碼，否則沒有必要嘗試使用舊版的視圖系統來編寫。目前 Compose 已經支持了 ConstraintLayout，雖然未來有可能會支持 MotionLayout，但我們建議您嘗試使用 Compose Animation API。您可以使用 Compose 實現很多內容，而且相比用視圖系統來實現要容易得多。 如果您不得不使用 MotionLayout，那么可以將常規的視圖嵌入到 Compose 應用中。在這種實現方式下兩者完全可以互操作，不過我們仍然建議您遷移到 Compose，這是現代 Android 開發的一個重要趨勢。

MotionLayout

https://developer.android.google.cn/training/constraint-layout/motionlayout

ConstraintLayout

https://developer.android.google.cn/reference/androidx/constraintlayout/widget/ConstraintLayout

問： 首選 MVVM 還是 MVI？

答： MVVM （Model-View-ViewModel） 和 MVI （Model-View-Intent） 其實沒有太大的區別，它們都是實現單向數據流 （UDF） 的具體方法，也是您構建應用的首選方式。因此，選擇哪一種方法完全取決于應用的具體需求，取決于您是否希望使用 MVI 建立用戶意圖模型并將幾乎所有內容都設置為響應式 （reactive）。所以，具體選擇哪一種架構完全取決于您的應用和需求，但不必過分拘泥，因為它們都可以實現您的目標。

問： 存儲區數據更新與 ViewModel 通信的最佳方式是什么？

答： 我們建議您使用 Flow 或掛起函數。如果這只是一次性的調用，那么您應該使用掛起函數，如果您需要使用流式數據，那么建議您使用 Flow。

在解決這個問題時，如果考慮讓存儲區類實例通知 ViewModel 發生了數據變化，您會發現這樣做很麻煩。因為 ViewModel 的生命周期往往比存儲區類實例要短。正確的思考方式應該是： 如果 ViewModel 需要用到存儲區中的某些數據，就讓它觀察或收集那些信息，這個過程可以通過 RxJava 或者協程來實現。這兩種思路之間有細微的差異，主動和被動方互換之后，很多復雜的問題也迎刃而解了。值得一提的是，這種新思路對于所有短生命周期對象觀察長生命周期對象中的數據都適用。當您處理其他單向數據流問題時，也可以試著從這個角度看問題，不論是存儲區類實例和 ViewModel 之間還是 ViewModel 和視圖之間的問題都會迎刃而解。

可能您還會思考是否可以使用 LiveData。不過需要明確的是，LiveData 其實是專門為界面構建的一組 API，它的設計用途非常清晰，就是用來保存界面狀態的。如果您想在存儲區類中使用 LiveData，會發現擴展性很差，因為在這種場景下有更適合的響應式庫供選擇。所以 LiveData 被設計為解決那一類非常具體的問題，超出這些范疇后就不再適合了。特別是當您正在使用 Kotlin 協程和 Flow 時就更不必再考慮 LiveData 了。另外，LiveData 是通過 XML 中綁定的形式使用的，以往人們使用它是因為與數據綁定緊密結合起來了。而現在，數據綁定支持使用 StateFlow，我們有了這種新的具有生命周期感知能力的協程 API，縱使 LiveData 在某些特定用途仍然表現出色，我們也沒有再使用的必要了。

LiveData 概覽

https://developer.android.google.cn/topic/libraries/architecture/livedata

Android 上的 Kotlin 數據流

https://developer.android.google.cn/kotlin/flow

問： 如何使用 Hilt 構建多模塊應用？

答： 我們建議您首先閱讀 Hilt 的文檔，這里幾乎有您需要的所有內容。多模塊應用的實現方式本質上和您將所有東西都放到應用 （app） 模塊中是一樣的，因為不同的模塊可以通過相同的方式向各個組件開放綁定。如果您希望構建動態功能模塊 （DFM），請參閱文檔： 在多模塊應用中使用 Hilt。

Hilt 的文檔https://developer.android.google.cn/training/dependency-injection/hilt-android

在多模塊應用中使用 Hilthttps://developer.android.google.cn/training/dependency-injection/hilt-multi-module

問： WorkManager 是否會取代后臺服務？

答： 如果您所指的后臺服務是 Android 中的舊服務類型的話，答案是肯定的。WorkManager 是專門為需要確保任務可靠運行而設計的，它有兩個重要特點： 保證任務可靠運行和可推遲運行任務。如果某個任務不需要獨立運行，那么使用 WorkManager 與使用后臺執行器、協程就沒有任何區別。某些工作，比如發送電子郵件或投屏到電視非常適合使用 WorkManager。

在非常早期的 Android 中，創建服務來實現這些任務是非常重要的，因為操作系統需要提前知道您的應用準備做某件事情。也許新版本的 Android 仍可能根據是否有服務在運行來判斷是否要繼續運行您的應用，但今后您都不必繼續使用了。所以，如果您不在意某些后臺工作沒有執行，那么可以使用常規的后臺執行器；如果您在意，那么請使用 WorkManager。WorkManager 還非常適用于持久作業，也就是需要在后臺持續運行的任務。如需了解近期 WorkManager 的新增功能，請參閱我們之前的推文： 現代 WorkManager API 已發布和 Android Studio 對現代 WorkManager 的支持。

Android 12 引入了一些新的限制，同時 WorkManager 2.7 也提供了新的 API 來幫助您適配這些限制，比如 setExpedited API。在早期，我們希望開發者們使用前臺服務，因為如果應用的確需要在后臺運行，就一定要用通知欄消息告訴用戶這樣做的必要性。但是很快，我們發現這個功能遭到某些應用的濫用，用戶的通知欄出現了大量的占用和騷擾。所以我們為 WorkManager 增加了加急作業 API，在 Android 12 運行時，它可以在 JobScheduler 中委托加急作業，而在低版本 Android 運行時又通過委托給前臺服務來提供更好的向后兼容性。

WorkManagerhttps://developer.android.google.cn/topic/libraries/architecture/workmanager

WorkManager 版本 2.7.0 的新變化https://developer.android.google.cn/jetpack/androidx/releases/work#version_27_2

問： 是否有只能用 LiveData 處理的場景？

答： 您可能在對比 LiveData 和 Flow 時會產生一個疑問： 是否有 LiveData 不能用 Flow 替代的例子？其實不用這樣對比，我們要從 LiveData 設計的思路來考慮。LiveData 是從專門解決界面顯示問題的角度來設計的，它的目的很明確，就是要在應用處于前臺時進行數據交互。這也意味著 LiveData 無法解決后臺運行時的數據獲取問題。所以這既是 LiveData 的優勢，也是它不能很好適應其他場景的原因。您可以查看《從 LiveData 遷移到 Kotlin 數據流》了解如何將 LiveData 轉換為 StateFlow 以及其中的差異。也可以閱讀《實戰 | 使用 Kotlin Flow 構建數據流 “管道”》來學習如何使用 Kotlin Flow。

所以如果您認為 LiveData 更適合您的用例，或者在您的用例中它實現起來更簡單，完全可以用 LiveData 實現。不過您需要了解，StateFlow 可以完成您用 LiveData 實現的所有任務，并且可以做得更多，也更符合 Android 開發的技術趨勢，同時讓您日后的維護更加輕松。

問： 如何減少 Android Studio 的構建時間？

答：構建是開發者們經常會進行的一個操作，但構建的操作包括了很多個過程： Gradle 和 Gradle 插件的處理、構建、編譯、打包資源等等。我們正在進行很多工作來優化這些方方面面，所以您需要做的就是使用最新版本的工具。每當 Android Gradle 插件、Kotlin 和其他您在構建過程需要用到的工具有更新時，請盡量更新它們。通常我們會在每次更新版本中修復近期的錯誤、提升穩定性或構建速度。

其次，像 KSP （Kotlin 符號處理） 這類工具可以在某些場景加快您的構建，建議您開始使用它們。另外我們還建議不要在構建中添加太多自定義的內容，設置不當可能會適得其反。因為自定義 Gradle 插件之類操作需要您對 Gradle、Gradle Android 插件有充分的了解，不適合新人去操作。如果您有像使用自定義構建這樣的需求，應該盡可能只使用聲明式的 DSL 樣式配置。

如需了解更多，請參閱我們之前的推文《使用新 Android Gradle 插件加速您的應用構建》。

問： 如何將應用過渡到 Jetpack？

答： 您不必過分拘泥于是不是每一處地方都使用了 Jetpack。我們無法給到您這樣一個清單來一一檢查，因為這是沒有意義的。開發中是否使用 Jetpack 來實現完全取決于您的應用架構。如果您的架構是可擴展的，比如所用到的接口都可以替換、數據庫中的依賴次序可以交換等等，那么這些都是幫助您的應用取得成功的基石。因此，我們只想建議您盡可能選擇一個合理的架構，讓依賴項能夠很容易進行替換——比如您可以很方便地用 DataStore 替換 SharedPreferences。

另外，Jetpack 已經推出好幾年了，在這期間涌現出一大批優秀的官方或第三方庫。所以我們建議您在自己實現某個功能前，先找找是不是已經有非常方便的庫可以取用。重復造輪子固然能提升您的研發水平，但會浪費大量時間，您完全可以依托強大的開源力量創造出優秀的應用。舉個例子，過去人們使用前臺服務來實現某些功能，但是 Android 12 的發布，這些方法都不再適用了，開發者們不得不重新實現來兼容新的系統。但是如果您用 WorkManager 的 setExpedited API 來實現，那么不需要任何操作就可以同時兼容新、舊系統的特性，節省大量的時間并省去了反復調試的成本。

最后一個建議，請您一定養成充分測試的習慣。在開發的過程中，非常容易因代碼變化而產生不確定因素。及時而充分的測試可以為代碼質量提供保障。我們以 Jetpack 開源代碼庫為例，其中有一個分支適配了最新的 Android 代碼，因此不論 Android 源代碼主實例中有什么變化，我們都會為它進行所有的測試。這樣就可以最大程度保證能在數月之前就發現可能出現的問題并做好修復工作，從而在新版本 Android 發布后，您可以放心地更新 Jetpack 庫進行適配而無需擔心出現兼容性問題。

如需了解更多，請參閱：

遷移至 AndroidX https://developer.android.google.cn/jetpack/androidx/migrate

問： ViewModel 和 Hilt 或者 Dagger 在 Compose 中可以使用嗎？

答： 答案是肯定的。在我們之前的推文《實踐 | Jetpack Compose 中的狀態管理》中詳細介紹了在 Compose 中處理狀態復雜性的不同方法。您會了解到 ViewModel 是一種負責提供對應用業務邏輯的訪問的狀態容器，它提供特定界面的界面狀態，所以位于整個界面的最外層。如果您使用了 Compose Navigation，那么 ViewModel 就可以看作是一個路由來使用。

如需了解更多，請參閱：

使用 Compose 進行導航 https://developer.android.google.cn/jetpack/compose/navigation

問： 需要在構建多平臺應用上投入精力嗎？

答： 這個問題與 Kotlin Multiplatform （KMP） 相關，目前我們的建議是暫時不要。KMP 仍然是我們還在研究的領域 （目前是 Alpha 版），相關成果應該很快就會與您見面。我們知道很多開發者都對這項技術感興趣，同時大家也在使用 Jetpack，所以我們不希望 Jetpack 阻礙您遷移到 KMP，您也不需要在兩者中糾結。

我們在設計 KMP 時，首先需要驗證它的可行性。比如構建 Room Multiplatform 庫就需要確保它不會影響到只使用 Android 的用戶。因此開發和推廣 KMP 是一個平穩過渡的過程，從文檔到 API 兼容性都必須能按照預期執行。對我們來說，將一個庫遷移到 Kotlin Multiplatform 需要做大量的工作，比如構建一些小型的 Jetpack 庫來進行測試和評估。未來您會看到很多這方面的進展，敬請期待！

Kotlin Multiplatform （KMP）https://kotlinlang.org/docs/multiplatform.html

問： 使用協程處理異常的最佳實踐是什么？

答：建議您直接使用協程提供的異常處理機制。您不需要進行額外的處理，直接使用協程內置的方法即可。這種機制會自動幫您處理異常傳播過程，不過您可能需要了解 SupervisorJob、SupervisorScope 以及 CoroutineScope 的工作原理。如需了解如何使用內置機制處理協程中的異常，請參閱文檔：

Kotlin 異常處理 https://kotlinlang.org/docs/exception-handling.html

問： 如何自動化發布到 Google Play 商店？

答： 目前 Android Studio 或者 Android Gradle 插件還不支持這項功能，但是開發者社區非常期待能實現它。不過您可以嘗試一款非常好用的第三方工具，它可以同 Android Gradle 插件一起工作，將這個發布流程自動化。我們會探索未來把這項功能集成進 Android Studio 的可能性，但在我們計劃完成之前，建議您通過開源庫實現這個功能：

開源庫： GitHub - fastlane/fastlane https://github.com/fastlane/fastlane

問： 能否使用 RemoteMediator 對 Pager 類單元測試？

答：未來您可以實現這樣的測試，不過目前還只能通過真實界面來測試操作。我們的確有這樣的計劃要實現一個測試輔助類來解決分頁測試相關的問題，但目前它依賴一些尚未公開的內部 API。所以您的理想做法是對 RemoteMediator 進行單元測試或是對實際分頁進行集成測試。

分頁功能的一個重要特點是非常依賴界面展示。它會在實際顯示時優化您看到的內容，因此如果沒有相關的代碼上下文，就很難控制和測試它。

RemoteMediator API 參考文檔 https://developer.android.google.cn/reference/kotlin/androidx/paging/RemoteMediator

問： Macrobenchmark 庫的作用是什么？

答：您可以使用 Macrobenchmark 庫測試應用自啟動、冷啟動、暖啟動時的加載用時。它可以幫助您測試應用的卡頓情況、分析不同幀的性能表現。如果您的應用涉及到大量的滾動操作，Macrobenchmark 可以幫助您找到掉幀的原因并進行有目的的改善。您還可以用它來實現對特定場景的測試，確保相關場景、功能更符合實際用戶的需求。 目前開發者們最關心的是測量啟動事件和分析卡頓情況兩大特性，因為這兩個性能指標會真正影響到應用的易用性和業務。而除了兩大功能，我們還在研究讓 Macrobenchmark 跟蹤應用中的其他關鍵性能指標，從而幫助您有選擇地對應用性能進行追蹤分析。

使用 Macrobenchmark https://developer.android.google.cn/studio/profile/macrobenchmark-overview

問： DataStore 是否支持加密？

答： DataStore 沒有自帶加密功能，但我們有計劃將加密集成進來。所以目前您使用 DataStore 時可以選擇先將數據序列化再寫入存儲中。您可以在 DataStore 的基礎上自行加密，只不過還沒有模塊能幫您直接完成加密工作。

一種可行的方式是將一個加密庫注入到 DataStore 中使用。我們希望能為您提供像 EncryptedSharedPreferences 那樣的 API，不過這個過程還需要時間。目前的想法是創建單獨的庫，然后利用 DataStore 的 API 實現對數據的直接加密。

對方塊的大小和顏色同時進行

原文標題：FAQ | 現代 Android 開發常見問題解答

文章出處：【微信公眾號：谷歌開發者】歡迎添加關注！文章轉載請注明出處。