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

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

直到 11 月份 Android 官方架構(gòu)組件正式版發(fā)布, 并且 Google 也在 Support Library v26.1.0 以后的版本中內(nèi)嵌了 Android 官方架構(gòu)組件中的生命周期組件, 我想, 這是趨勢, 既然 Google 這么推崇, 那我也是時(shí)候?qū)W習(xí)一波并將它們引入 MVPArms 框架了

Github : 你的 Star 是我堅(jiān)持的動(dòng)力 ?

因?yàn)橄雽?Android 官方架構(gòu)組件引入 MVPArms 框架之中, 所以我認(rèn)真學(xué)習(xí)了 Android 官方架構(gòu)組件中除了 Room 之外的所有源碼, 以考察是否整個(gè)組件都適合引入 MVPArms 框架

在學(xué)習(xí)完源碼過后, 發(fā)現(xiàn) Android 官方架構(gòu)組件其實(shí)并沒有想象的那么高深, 原理反而是我們在日常開發(fā)中都會(huì)用到的知識點(diǎn), 那我就在文章的開頭先簡單的介紹下 Android 官方架構(gòu)組件中的這幾個(gè)組件

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

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

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

簡而言之就是, 當(dāng)某個(gè)頁面請求網(wǎng)絡(luò)數(shù)據(jù)成功后需要同步 UI, 但這個(gè)頁面已經(jīng)不可見, 這時(shí)就會(huì)停止同步 UI 的操作

ViewModel 有兩個(gè)功能, 第一個(gè)功能可以使 ViewModel 以及 ViewModel 中的數(shù)據(jù)在屏幕旋轉(zhuǎn)或配置更改引起的 Activity 重建時(shí)存活下來, 重建后數(shù)據(jù)可繼續(xù)使用, 第二個(gè)功能可以幫助開發(fā)者輕易實(shí)現(xiàn) Fragment 與 Fragment 之間, Activity 與 Fragment 之間的通訊以及共享數(shù)據(jù)

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

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

說到生命周期我就想到了我之前在 傳統(tǒng)MVP用在項(xiàng)目中是真的方便還是累贅? 中討論的一個(gè)內(nèi)容

現(xiàn)在市面上流行的 MVP 架構(gòu)有兩種, 第一種是將 Activity 或 Fragment 作為 View, 抽象一個(gè) Presenter 層出來, 第二種是將 Activity 或 Fragment 作為 Presenter, 抽象一個(gè) View 層出來

第一種類型代表的框架有 MVPArms, 第二種類型代表的框架有 TheMVP, 當(dāng)然第一種類型的 MVP 架構(gòu)在市面上用的是最多的, 那么第二種類型的優(yōu)點(diǎn)是什么呢?

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

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

經(jīng)過以上的分析, 我認(rèn)為生命周期組件對于我的框架來說是很有必要的, 這將使日常開發(fā)更加便捷

LiveData 與 RxJava 都是基于觀察者模式, 功能上也有重合, Google 在官方文檔上也明確表示, 如果你正在使用 RxJava, Agera 等類似功能的庫, 只要你能正確的處理數(shù)據(jù)流的生命周期, 就完全可以繼續(xù)使用它們來替代 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 等類似功能的庫, 你只使用一個(gè)即可

選擇 RxJava 還是 LiveData ?

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

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

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

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

ViewModel 中有一個(gè)功能讓我十分驚艷, 也十分好奇, 它可以使 ViewModel 以及 ViewModel 中的數(shù)據(jù)在屏幕旋轉(zhuǎn)或配置更改引起的 Activity 重建時(shí)存活下來, 重建后數(shù)據(jù)可繼續(xù)使用, 這個(gè)功能十分實(shí)用且十分重要, 因?yàn)橹耙矝]有一個(gè)官方解決方案, 所以我覺得很有必要將這個(gè)功能引入 MVPArms 框架

同樣另外一個(gè)功能, 它還可以幫助開發(fā)者輕易實(shí)現(xiàn) Fragment 與 Fragment 之間, Activity 與 Fragment 之間的通訊以及共享數(shù)據(jù), 同樣也正是我所需要的官方解決方案

但在我繼續(xù)深入研究, 準(zhǔn)備將它引入到項(xiàng)目中時(shí), 卻發(fā)現(xiàn) Google 將這個(gè)功能做了高度封裝并限制了它的使用范圍, 只能用于 ViewModel

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

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

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

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

在我看來 ViewModel 組件 的核心原理也就是 HolderFragment 中的一行代碼實(shí)現(xiàn)的:

setRetainInstance(true);

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

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

意思是只要將這個(gè)方法設(shè)置為 true, Fragment 以及 Fragment 之中的所有數(shù)據(jù)都會(huì)在 Activity 重建時(shí)存活下來

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

于是我們讓 Activity, Fragment 都綁定一個(gè)這樣的 Fragment, 將 ViewModel 存放到這個(gè) Fragment 的 Map 中, ViewModel 組件 就這樣實(shí)現(xiàn)了

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

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

ViewModel 組件 讓一個(gè)新的 ViewModel 必須繼承于它的基類, 并且讓開發(fā)者必須提供一個(gè) Factory 指明當(dāng)前 ViewModel 的構(gòu)建方式, ViewModel 組件 會(huì)在合適的時(shí)機(jī), 主動(dòng)去根據(jù) Factory 構(gòu)建 ViewModel 實(shí)例, 并放入 Map 中

這時(shí)整個(gè)構(gòu)建過程都被 ViewModel 組件 掌控并被限制于 ViewModel, 所以我需要做的就是將 Map 和 ViewModel 的構(gòu)建方式擴(kuò)展出來, 將更多的控制權(quán)交給外部的開發(fā)者

經(jīng)過上面的分析, 思路和方案都有了, 接下來就剩下如何把思路和方案實(shí)現(xiàn)了

于是我結(jié)合上文分析的思路和方案對官方源碼進(jìn)行了改造并做了適當(dāng)?shù)膬?yōu)化, LifecycleModel 就這樣誕生了

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

Github : 你的 Star 是我堅(jiān)持的動(dòng)力 ?

一個(gè)新技術(shù)是否真的適合自己還是需要自己去考察, 不應(yīng)該盲目跟風(fēng), 如果你只知道這個(gè)技術(shù)很火然后去用它, 不知道為什么用它, 用它的好處, 那你就會(huì)一直陷入被動(dòng)學(xué)習(xí)的窘境, 一直在學(xué)習(xí), 但是總覺得自己跟不上時(shí)代的進(jìn)步, 擔(dān)驚受怕, 這是現(xiàn)代技術(shù)人大部分都存在的處境

踩坑

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

通過 Activity 獲取 ViewModel 時(shí)遇到的坑:

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

在 Activity 的 onDestroy 方法中不能獲取 ViewModel, 會(huì)報(bào)錯(cuò)

通過 Fragment 獲取 ViewModel 時(shí)遇到的坑:

在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentAttached 方法中獲取 ViewModel 時(shí)也會(huì)出現(xiàn)和 Activity 一樣的情況, 獲取的 ViewModel 是重新構(gòu)建后的新實(shí)例, ViewModel 以及 ViewModel 中的數(shù)據(jù)不能幸免于 Activity 重建, 所以也不要在此方法中獲取 ViewModel

在 FragmentManager.FragmentLifecycleCallbacks 中的 onFragmentDestroyed 方法中也不能獲取 ViewModel, 會(huì)報(bào)錯(cuò)

在 Fragment 的 onDestroy 方法中不能獲取 ViewModel, 會(huì)報(bào)錯(cuò)

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

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架構(gòu)探究之旅—基礎(chǔ)篇

看完不會(huì)寫MVP架構(gòu)我跪搓板

MVP設(shè)計(jì)深度剖析+NDK技術(shù)FFmpeg應(yīng)用

帶你一起探究MVP架構(gòu)模式，讓你的項(xiàng)目更加有層次感

歡迎關(guān)注我的公眾號：終端研發(fā)部，一起交流和學(xué)習(xí)！