摘要：前言官方架構組件在今年月份大會上被公布直到月份一直都是測試版由于工作比較繁忙期間我只是看過類似的文章但沒有在實際項目中使用過更沒有看過源碼所以對這幾個組件的使用很是生疏同時也覺得這幾個組件非常高大上非常神秘直到月份官方架構組件正式版發布并且

Android 官方架構組件在今年 5 月份 Google I/O 大會上被公布, 直到 11 月份一直都是測試版, 由于工作比較繁忙, 期間我只是看過類似的文章, 但沒有在實際項目中使用過, 更沒有看過源碼, 所以對這幾個組件的使用很是生疏, 同時也覺得這幾個組件非常高大上, 非常神秘!

直到 11 月份 Android 官方架構組件正式版發布, 并且 Google 也在 Support Library v26.1.0 以后的版本中內嵌了 Android 官方架構組件中的生命周期組件, 我想, 這是趨勢, 既然 Google 這么推崇, 那我也是時候學習一波并將它們引入 MVPArms 框架了

Github : 你的 Star 是我堅持的動力 ?

因為想將 Android 官方架構組件引入 MVPArms 框架之中, 所以我認真學習了 Android 官方架構組件中除了 Room 之外的所有源碼, 以考察是否整個組件都適合引入 MVPArms 框架

在學習完源碼過后, 發現 Android 官方架構組件其實并沒有想象的那么高深, 原理反而是我們在日常開發中都會用到的知識點, 那我就在文章的開頭先簡單的介紹下 Android 官方架構組件中的這幾個組件

生命周期組件是 Android 官方架構組件中的核心組件, 它可以使各種實例作為觀察者與 Activity 和 Fragment 等具有生命周期特性的組件綁定在一起, LiveData 和 ViewModel 都是基于此組件, 簡而言之就是, 你將需要綁定生命周期的實例注冊給該組件, 該組件就會在你指定的某個生命周期方法執行時通知這個實例

應用場景很多, 比如之前在 MVP 架構中, 你需要在 Activity 執行 onCreate 時, 讓 Presenter 初始化一些操作, 這時就不用在 Activity 的 onCreate 中再調用 Presenter 的某個初始化方法了, 直接使用官方的生命周期組件即可完成, 在 Activity 執行 onDestroy 時需要釋放一些對象的資源, 也可以使用到生命周期組件

LiveData 具有兩個功能, 第一個功能是觀察者模式, 在 Value 發生變化時通知之前注冊的所有觀察者, 第二功能是基于生命周期組件與 Activity 和 Fragment 等具有生命周期特性的組件綁定在一起, 在生命周期發生改變時停止或恢復之前的事件

簡而言之就是, 當某個頁面請求網絡數據成功后需要同步 UI, 但這個頁面已經不可見, 這時就會停止同步 UI 的操作

ViewModel 有兩個功能, 第一個功能可以使 ViewModel 以及 ViewModel 中的數據在屏幕旋轉或配置更改引起的 Activity 重建時存活下來, 重建后數據可繼續使用, 第二個功能可以幫助開發者輕易實現 Fragment 與 Fragment 之間, Activity 與 Fragment 之間的通訊以及共享數據

用法就不多說了, 此類文章和 Demo 太多了, 明白了它們的功能和應用場景后, 我們才知道它們是否真的適合自己的需求, 而不是盲目跟風, 下面我就來分析下我是如何考察新技術, 以及如何判斷這些新技術是否有必要應用到自己的項目中

上面介紹了生命周期組件的功能, 這里就來分析一下生命周期組件是否有必要引入我的框架 MVPArms

說到生命周期我就想到了我之前在 傳統MVP用在項目中是真的方便還是累贅? 中討論的一個內容

現在市面上流行的 MVP 架構有兩種, 第一種是將 Activity 或 Fragment 作為 View, 抽象一個 Presenter 層出來, 第二種是將 Activity 或 Fragment 作為 Presenter, 抽象一個 View 層出來

第一種類型代表的框架有 MVPArms, 第二種類型代表的框架有 TheMVP, 當然第一種類型的 MVP 架構在市面上用的是最多的, 那么第二種類型的優點是什么呢?

我在上面這篇文章也說過, 主要優勢有兩個, 方便重用View, 以及 可直接與 Activity 或 Fragment 的生命周期做綁定, 這樣就可以直接使用 Activity 或 Fragment 的生命周期, 不用再去做多余的回調, 當然也有缺點, 我在文章中也有介紹, 有興趣的可以去看看

第一種類型的 MVP 架構是不具有可以和 Activity 或 Fragment 的生命周期直接做綁定的優勢的, 所以很是嫉妒第二種類型的 MVP 架構, 這也是兩種類型的 MVP 架構最大的區別, 但你想的沒錯, 現在使用生命周期組件就可以使第一種類型的 MVP 架構很輕易的具有綁定生命周期的優勢, 現在第一種類型的 MVP 架構將如虎添翼

經過以上的分析, 我認為生命周期組件對于我的框架來說是很有必要的, 這將使日常開發更加便捷

LiveData 與 RxJava 都是基于觀察者模式, 功能上也有重合, Google 在官方文檔上也明確表示, 如果你正在使用 RxJava, Agera 等類似功能的庫, 只要你能正確的處理數據流的生命周期, 就完全可以繼續使用它們來替代 LiveData

Note: If you are already using a library like RxJava or Agera, you can continue using them instead of LiveData. But when you use them or other approaches, make sure you are handling the lifecycle properly such that your data streams pause when the related LifecycleOwner is stopped and the streams are destroyed when the LifecycleOwner is destroyed. You can also add the android.arch.lifecycle:reactivestreams artifact to use LiveData with another reactive streams library (for example, RxJava2).

從官方文檔可以看出 Google 對此的建議就是 RxJava, Agera, LiveData 等類似功能的庫, 你只使用一個即可

選擇 RxJava 還是 LiveData ?

LiveData 和 RxJava 的功能的確過于重合, 我也十分贊同 Google 官方的建議, 兩者之中選擇其一就可以了, 沒必要兩者都引入項目, 而 MVPArms 框架, 也正好引入了 RxJava, 所以我也來分析分析在 MVPArms 框架中該選擇 LiveData 還是 RxJava?

于是我認真的研究了其源碼, LiveData 具有兩個功能, 通知觀察者更新數據和根據生命周期停止和恢復之前的事件, 而 Rxjava 加上 RxLifecycle, RxJava 加上 AutoDispose, 或 Rxjava 加上生命周期組件, 也可以輕易做到根據生命周期停止和恢復之前的事件, 在配上 Rxjava 強大的操作符, LiveData 能做的事 RxJava 都能做, LiveData 不能做的事 RxJava 也能做

并且 RxJava 不僅僅只是 RxJava, 他還是一個龐大的生態鏈, 他還有 RxCache, RxLifecycle, RxAndroid, RxPermission, Retrofit-Adapter 等大量并且強大的衍生庫, 我們離開它做很多事都非常不便, 剛剛出生, 羽翼未豐的 LiveData 相比于 RxJava 將沒有任何優勢, 甚至顯得非常簡陋

因此 LiveData 和 RxJava 之間如果只能選擇一個的話, 我沒有任何理由選擇 LiveData

ViewModel 中有一個功能讓我十分驚艷, 也十分好奇, 它可以使 ViewModel 以及 ViewModel 中的數據在屏幕旋轉或配置更改引起的 Activity 重建時存活下來, 重建后數據可繼續使用, 這個功能十分實用且十分重要, 因為之前也沒有一個官方解決方案, 所以我覺得很有必要將這個功能引入 MVPArms 框架

同樣另外一個功能, 它還可以幫助開發者輕易實現 Fragment 與 Fragment 之間, Activity 與 Fragment 之間的通訊以及共享數據, 同樣也正是我所需要的官方解決方案

但在我繼續深入研究, 準備將它引入到項目中時, 卻發現 Google 將這個功能做了高度封裝并限制了它的使用范圍, 只能用于 ViewModel

但我想 Google 既然能讓 MVVM 框架中的 ViewModel 具有這些功能, 那我為什么不能將這個功能擴展出來提供給 MVP 框架中的 Presenter, 乃至其他更多的模塊?

于是我認真的研究了其源碼, 準備通過修改源碼并封裝成庫的方式, 讓更多的開發者在更多的場景下能夠使用到這些功能

要想改造 ViewModel 組件 自然要對它的整個源碼分析一遍, 知道其原理, 才知道如何下手

篇幅有限, 就來簡單的分析下源碼把, 源碼其實也就幾個類, 經過了層層封裝, 核心代碼就在一個叫做 HolderFragment 的 Fragment 中,

在我看來 ViewModel 組件 的核心原理也就是 HolderFragment 中的一行代碼實現的:

setRetainInstance(true);

setRetainInstance(boolean) 是 Fragment 中的一個方法, 我想很多人應該都知道這個方法的意義

簡單來說將這個方法設置為 true 就可以使當前 Fragment 在 Activity 重建時存活下來, 如果不設置或者設置為 false, 當前 Fragment 會在 Activity 重建時同樣發生重建, 以至于被新建的對象所替代

意思是只要將這個方法設置為 true, Fragment 以及 Fragment 之中的所有數據都會在 Activity 重建時存活下來

這時我們在 setRetainInstance(boolean) 為 true 的 Fragment 中放一個專門用于存儲 ViewModel 的 Map, 自然 Map 中所有的 ViewModel 都會幸免于 Activity 重建

于是我們讓 Activity, Fragment 都綁定一個這樣的 Fragment, 將 ViewModel 存放到這個 Fragment 的 Map 中, ViewModel 組件 就這樣實現了

想要知道如何改造, 那我們就要明確這次改造的最終目的是什么, 我們的目的就是要讓 ViewModel 組件 能用于 Presenter, 乃至其他更多的模塊, 不止是用于 ViewModel

那為什么 Google 官方的 ViewModel 組件 不能用于其他模塊呢, 通過閱讀源碼可以知道, 是因為 Google 把上文提到的 Map, 封裝了起來, 并沒有提供出去, 并且限制了 ViewModel 的構建方式

ViewModel 組件 讓一個新的 ViewModel 必須繼承于它的基類, 并且讓開發者必須提供一個 Factory 指明當前 ViewModel 的構建方式, ViewModel 組件 會在合適的時機, 主動去根據 Factory 構建 ViewModel 實例, 并放入 Map 中

這時整個構建過程都被 ViewModel 組件 掌控并被限制于 ViewModel, 所以我需要做的就是將 Map 和 ViewModel 的構建方式擴展出來, 將更多的控制權交給外部的開發者

經過上面的分析, 思路和方案都有了, 接下來就剩下如何把思路和方案實現了

于是我結合上文分析的思路和方案對官方源碼進行了改造并做了適當的優化, LifecycleModel 就這樣誕生了

這篇文章主要還是講在完成一個目標前, 在從 0 到 1 期間進行的思路和分析的過程, 至于細節你如果感興趣的話還是去看我的源碼把, 哈哈, 注釋很詳細哦!

Github : 你的 Star 是我堅持的動力 ?

一個新技術是否真的適合自己還是需要自己去考察, 不應該盲目跟風, 如果你只知道這個技術很火然后去用它, 不知道為什么用它, 用它的好處, 那你就會一直陷入被動學習的窘境, 一直在學習, 但是總覺得自己跟不上時代的進步, 擔驚受怕, 這是現代技術人大部分都存在的處境

踩坑

在實際項目中使用 ViewModel 組件 時我也遇到了一些問題, 浪費了我很多時間, 所以有必要分享出來讓大家少走彎路

通過 Activity 獲取 ViewModel 時遇到的坑:

在 Application.ActivityLifecycleCallbacks 中的 onActivityCreated 方法中獲取 ViewModel 時, Activity 每重建一次, 獲取的 ViewModel 都是重新構建后的新實例, 并不能讓 ViewModel 以及 ViewModel 中的數據幸免于 Activity 重建, 所以不要在此方法中獲取 ViewModel

在 Activity 的 onDestroy 方法中不能獲取 ViewModel, 會報錯

通過 Fragment 獲取 ViewModel 時遇到的坑:

在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentAttached 方法中獲取 ViewModel 時也會出現和 Activity 一樣的情況, 獲取的 ViewModel 是重新構建后的新實例, ViewModel 以及 ViewModel 中的數據不能幸免于 Activity 重建, 所以也不要在此方法中獲取 ViewModel

在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentDestroyed 方法中也不能獲取 ViewModel, 會報錯

在 Fragment 的 onDestroy 方法中不能獲取 ViewModel, 會報錯

Hello 我叫Jessyan,如果您喜歡我的文章,可以在以下平臺關注我

GitHub: https://github.com/JessYanCoding

掘金: https://gold.xitu.io/user/57a9dbd9165abd0061714613

簡書: http://www.jianshu.com/u/1d0c0bc634db

微博: http://weibo.com/u/1786262517

作者：JessYan
鏈接：https://www.jianshu.com/p/963...

MVC，MVP 和 MVVM 模式如何選擇？

死磕安卓前序：MVP架構探究之旅—基礎篇

看完不會寫MVP架構我跪搓板

MVP設計深度剖析+NDK技術FFmpeg應用

帶你一起探究MVP架構模式，讓你的項目更加有層次感

歡迎關注我的公眾號：終端研發部，一起交流和學習！