Android jetpack總結和實踐

背景

在Android開發中常常面臨的問題： （1）在應用程序（Activity、Fragment）的生命週期管理困難，尤爲是Fragment的跳轉帶來的生命週期管理問題。 （2）在Activity須要從新建立的時候，界面控制器（View層）中存儲的數據丟失，須要從新初始化，影響用戶體驗。 （3）Android的異步操做（DB，NetWork）時，在界面控制器（View層）被銷燬後，界面控制器須要結束和任務的訂閱關係，避免內存泄漏和沒必要要的信息回調。 （4）Android的後臺服務和任務愈發困難。主要是因爲Android系統的DOZE省電模式，以及後來對於後臺任務和服務的限制。 （5）用戶偏好設置和網絡請求數據的本地存儲問題。

針對以上問題，Google推出Android Jetpack框架來解決以上問題。Jetpack主要分爲4個部分（下圖）： 基礎、架構、行爲、界面 。

同時Google也推出 AndroidX 庫，AndroidX 是對support library的重大改進。在AndroidX中將全部軟件包名都以字符串**androidx.**開頭，位於一致的命名空間中。

使用Android Jetpack組件的優點： （1）Lifecycles輕鬆管理應用程序的生命週期。 （2）LiveData構建可觀察的數據對象，以便在基礎數據更改時通知視圖。 （3）ViewModel存儲在應用程序輪換中未銷燬的UI相關數據，在界面重建後恢復數據。 （4）Room輕鬆的實現SQLite數據庫。 （5）WorkManager系統自動調度後臺任務的執行，優化使用性能。 （6）Navigation導航組件輕鬆管理Fragment等頁面跳轉問題。

google推薦的基於Jetpack的Android客戶端軟件開發架構圖： （1）經過定義Repository管理數據來源(Model)。 （2）使用LiveData驅動界面(View)更新。 （3）使用ViewModel代替Presenter管理數據(VM)。 （4）Room（Sqlite）儲存本地序列化的數據，Retrofit獲取遠程數據的數據。

關於該架構的疑問：該模式的是MVP仍是MVVM架構？

與傳統的MVP架構相比有如下優勢： （1）在MVP架構中，Presenter中持有View層的引用，若是生命週期處理不當，會存在內存泄露的風險。在MVVM架構中View層和VM層經過LiveData通訊，避免了內存泄漏。。 （2）傳統MVP架構因爲各層之間的通訊是經過接口，因此會致使接口數量驚人，上訴架構經過觀察者模式（LiveData）避免了接口問題。

若是在上訴架構中加入Databidning。實現View和Model的雙向綁定接能夠演變成MVVM架構。可是基於DataBinding的MVVM架構有以下缺點： （1）數據雙向綁定，致使View不可重用。 （2）經過DataBinding實現數據綁定，會增長Bug調試難度。 （3）業務的複雜，會帶來View頁面複雜，model層代碼也會增大。

jetpack架構

2.1 Lifecycles

1. 一句話概述： Lifecycles是一個持有組件生命週期狀態（Activity、Fragment）信息的類，用來解決生命週期管理問題的組件。Lifecycles源碼分析地址
2. 生命週期轉化圖：

   

3. 實現原理 （1）數據結構： 爲何使用該數據結構？ 具備以下優勢： 1.SafeIterableMap 的插入操做是時間複雜度O(1）直接經過指針的移動插入數據，並且不須要執行hash算法，效率高。 2.遍歷的過程當中刪除元素而不觸發ConcurrentModifiedException。 3.使用雙向鏈表來存儲會比 HashMap （java 8 紅黑樹）節省內存空間。

   

   （2）類圖
4. Lifecycle組件成員Lifecycle被定義成了抽象類，LifecycleOwner、LifecycleObserver被定義成了接口。
5. 組件（Activity、Fragment）實現了LifecycleOwner接口，該只有一個返回Lifecycle對象的方法getLifecyle(): LifecycleRegistry。
6. Lifecycle的內部類State標明狀態、Event表示事件
7. ObserverWithState的成員變量GenericLifecycleObserver繼承自LifecycleObserver

   

2.2 ViewModel

1. 一句話概述： ViewModel存儲和管理 UI 相關數據，保證組件（Activity）從新建立時能夠恢復歷史數據。 ViewModel源碼分析地址
2. 生命週期轉化圖：

   

3. 實現原理 （1）onRetainNonConfigurationInstance方法。 當發生屏幕切換時，將伴隨Destroying被系統調用。經過這個方法能夠像onSaveInstanceState()的方法同樣保留變化前的Activity數據和狀態，最大的不一樣在於這個方法能夠返回一個包含有狀態信息的Object對象，其中甚至能夠包含Activity Instance自己。用這個方法保存Activity State後。 （2）經過getLastNonConfigurationInstance()在新的Activity Instance中恢復原有狀態。好比: 在恢復窗口時，咱們能夠不使用onRestoreInstanceState，而代替的是 getLastNonConfigurationInstance 方法。

2.3 LiveData

1. 一句話概述： LiveData 是保存數據對象的類，經過註冊監聽器Observer 監聽數據的變化。LiveData最大的優點：LiveData 是感知Activity、Fragment等生命週期的組件。LiveData源碼分析地址
2. 實現原理 （1）使用LifecycleOwner的observe() 方法將觀察者對象附加到LiveData對象，將觀察者向LiveData對象訂閱，以便通知LiveData中數據的變化。 （2）當Lifecycle 沒有處於活動狀態（ (STARTED 、RESUMED)），Observer 則不會被通知，即便數據發生了變化，沒有處於活動狀態的 Observer 也不會被通知。 （3）Lifecycle 被銷燬（destroyed）Observer 也自動被刪除，無需用戶手動清理。 避免內存泄漏：Observer 和 Lifecycle 綁定，能夠感知組件生命週期，因此當 Lifecycle 被銷燬後，Observer 自動被remove避免內粗泄漏。

2.4 WorkManager

1. 一句話概述： WorkManager 負責用來管理後臺任務，它適用於須要保證系統即便應用程序退出也會運行的任務， WorkManager會根據設備API級別和應用程序狀態等因素選擇適當的方式來運行任務。。[WorkManager源碼分析地址](juejin.im/post/5d5e7d…
2. 實現原理 架構圖：

   

2.5 Navigation

1. 一句話概述： Navigation管理APP頁面跳轉。Navigation大部分部分狀況下做用於Fragment中，使用Navigation切換Fragment可使代碼簡潔，直觀。Navigation導航組件還支持：Fragment、Activity、導航圖和子圖、自定義目標等。。Navigation源碼分析地址
2. 實現原理 類圖：

   

2.6 Paging&Room

1. 一句話概述： Paging主要是用來結合RecyclerView進行使用，是一種分頁加載解決方案，這樣Paging每次只會加載總數據的一部分。 Room是Google提供的一個ORM庫。。Paging&Room組合使用

2. 實現原理 原理圖：

   

   

示例

基於Jetpack的架構圖總結：

架構圖： （1）View層：表示的Activity和Fragment等組件。 （2）ViewModel層：ViewModel存儲和View層相關的數據，能夠在View層從新繪製時恢復數據，並且負責和View層和倉庫層之間的通訊。 （3）倉庫層：負責從數據庫中獲取數據或者從網絡中獲取數據，並將數據返回給ViewModel層。 （4）數據層：數據層分爲網絡數據層（Retrofit）和是數據庫數據層（GreenDao）。 （5）View層和ViewModel層經過LiveData通訊，避免了接口的內存泄漏問題。 關於倉庫層存在必要性？：

官網解析：地址 Repository modules handle data operations. They provide a clean API so that the rest of the app can retrieve this data easily. They know where to get the data from and what API calls to make when data is updated. You can consider repositories to be mediators between different data sources, such as persistent models, web services, and caches.

大體意識：

倉庫模塊負責處理數據操做，提供了一個乾淨的API使得獲取數據更加容易。倉庫層知道從何處獲取數據以及更新數據時要調用的API。你能夠認爲倉庫層是做爲中介在不經過的數據源之間，好比持久模型，Web服務，緩存等。

總結：遵循關注點分離原則 通過Repository中介層使得ViewModel不須要具體的數據來源，這樣就能夠根據需求將其交換爲其餘實現。