本文轉(zhuǎn)自：是讓人耳目一新的 Jetpack MVVM 精講啊
作者：KunMinX
Github開源項(xiàng)目：https://github.com/KunMinX/Jetpack-MVVM-Best-Practice

前言

很高興見到你岗憋！

最近在后臺 時(shí)有收到 讀者的留言墨辛，說能不能出一期 Jetpack MVVM 精講嵌削，以及配套一份簡練的案例徽级，好 把玩把玩篓跛、感受感受止喷、加深對 MVVM 的印象旅东。

答案當(dāng)然是肯定的谣光。??

面向標(biāo)準(zhǔn)化開發(fā)已成現(xiàn)實(shí)

金九銀十毅往，相信有不少讀者在抓緊機(jī)會面試牵咙。

Android 市場已今非昔比。在過去攀唯，迫于招人的壓力洁桌，應(yīng)試者只需了解四大組件、視圖侯嘀、網(wǎng)絡(luò)請求另凌，即可謀得一份滿意的工作。

現(xiàn)如今戒幔，Jetpack 架構(gòu)組件 及 標(biāo)準(zhǔn)化開發(fā)模式 的確立吠谢，意味著 Android 開發(fā)已步入成熟階段：

許多 樣板代碼 不再需要開發(fā)者手寫，而是可以通過模版工具 自動生成诗茎，在取締繁雜耗時(shí)的重復(fù)工作的同時(shí)工坊，避免因人工操作的疏忽，而造成難以排查、不可預(yù)期的錯(cuò)誤王污。

這十分符合企業(yè)的利益罢吃，因而面試官在招人的時(shí)候，也更加看重應(yīng)試者對 架構(gòu)組件 —— 至少是 MVVM 的理解程度昭齐。??

像“解耦”等 含糊其辭的說法尿招，已經(jīng)不能夠被面試官所認(rèn)可，稍微對 MVVM 有一點(diǎn)經(jīng)驗(yàn)的面試官都會請你舉例說明阱驾，好證明你確實(shí)對 MVVM 有著正確就谜、深入的理解，能夠自然而然地寫出標(biāo)準(zhǔn)化啊易、規(guī)范化的代碼吁伺，能夠迅速適應(yīng) 各家公司自制的 自動化模版工具。

本文的目標(biāo)

本人擁有 3 年的 移動端架構(gòu) 踐行和設(shè)計(jì)經(jīng)驗(yàn)租谈，領(lǐng)導(dǎo)團(tuán)隊(duì)重構(gòu)的中大型項(xiàng)目多達(dá)十?dāng)?shù)個(gè)篮奄，對 Jetpack MVVM 架構(gòu)在確立規(guī)范化、標(biāo)準(zhǔn)化 開發(fā)模式 以減少不可預(yù)期的錯(cuò)誤 所作的努力割去，有著深入的理解窟却。

因而本文的目標(biāo)，就是結(jié)合前幾期我們分別 深入淺出 介紹過的 Lifecycle呻逆、LiveData夸赫、ViewModel、DataBinding咖城，來融匯貫通地演繹一下：

作為 應(yīng)用開發(fā)骨架 的 標(biāo)準(zhǔn)化狀態(tài)管理框架茬腿，究竟為 快速開發(fā)過程中 減少不可預(yù)期的錯(cuò)誤 做了哪些努力。

不同于 東拼西湊宜雀、人云亦云切平、徒添困擾 的網(wǎng)文，愿意將 標(biāo)準(zhǔn)化開發(fā)模式的 深度思考知識 和 實(shí)戰(zhàn)反思經(jīng)驗(yàn) 無保留地分享辐董，全網(wǎng)僅此一家悴品。這樣的文章可以說是 看一篇、少一篇简烘，因此苔严，就算不去 hold 住面試官，也請務(wù)必跟隨本文的腳步孤澎，無障礙地將 Jetpack MVVM 過一遍届氢！??

文章目錄一覽

• 前言
• 面向標(biāo)準(zhǔn)化開發(fā)已成現(xiàn)實(shí)
• 本文的目標(biāo)
• Jetpack Lifecycle
  • Lifecycle 存在前的混沌世界
  • Lifecycle 為什么能解決上述這些問題？
• Jetpack LiveData
  • LiveData 存在前的混沌世界
  • LiveData 為什么能解決上述這些問題亥至？
  • LiveData 有個(gè)坑需要注意
• Jetpack ViewModel
  • ViewModel 存在前的混沌世界
  • ViewModel 為什么能做到這幾點(diǎn)悼沈？
• Jetpack DataBinding
  • DataBinding 存在前的混沌世界
  • DataBinding 就是來解決這些問題
• 綜上

Jetpack Lifecycle

Lifecycle 的存在贱迟，主要是為了解決 生命周期管理 的一致性問題

Lifecycle 存在前的混沌世界

在 Lifecycle 面市前，生命周期管理 純靠手工維持絮供，這樣就容易滋生大量的一致性問題衣吠。

例如跨頁面共享的 GpsManager 組件，在每個(gè)依賴它的 Activity 的 onResume 和 onPause 中都需要 手工 激活壤靶、解綁 和 叫停缚俏。

那么 隨著 Activity 的增多，這種手工操作 埋下的一致性隱患 就會指數(shù)級增長：

一方面贮乳，凡是手工維持的忧换，開發(fā)者容易疏忽，特別是工作交接給其他同事時(shí)向拆，同事并不能及時(shí)注意到這些細(xì)節(jié)亚茬。

另一方面，分散的代碼不利于修改浓恳，日后除了激活刹缝、叫停，若有其他操作需要補(bǔ)充（例如狀態(tài)監(jiān)聽）颈将，那么每個(gè) Activity 都需要額外書寫一遍梢夯。

image.png

Lifecycle 為什么能解決上述這些問題？

Lifecycle 通過 模板方法模式 和 觀察者模式晴圾，將生命周期管理的復(fù)雜操作颂砸，全部在作為 LifecycleOwner 的基類中（例如視圖控制器的基類）封裝好，默默地在背后為開發(fā)者運(yùn)籌帷幄死姚，

開發(fā)者因而得以在視圖控制器（子類）中只需一句 getLifecycle().addObserver(GpsManager.getInstance) 人乓，優(yōu)雅地完成 第三方組件在自己內(nèi)部 對 LifecycleOwner 生命周期的感知。

image.png

除了解決一致性問題都毒，這樣做還 順帶地提供了其他 2 個(gè)好處：

1.規(guī)避 為監(jiān)聽狀態(tài) 而 注入視圖控制器 的做法

當(dāng)需要監(jiān)聽狀態(tài)時(shí)撒蟀，以往我們的做法是 通過方法手工注入 Activity 等參數(shù)，這埋下了內(nèi)存泄漏的隱患 —— 因?yàn)閳F(tuán)隊(duì)中的新手容易因這是個(gè) Activity温鸽，而在日后誤將其依賴給組件中的其他成員。

現(xiàn)如今手负，我們可以直接在組件內(nèi)部 點(diǎn)到為止 地監(jiān)聽 LifecycleOwner 的狀態(tài)涤垫，從而規(guī)避這種不恰當(dāng)?shù)氖褂谩?/p>

2.規(guī)避 為追溯事故來源 而 注入視圖控制器 的做法

當(dāng)發(fā)生事故時(shí)，以往我們?nèi)粝朐诮M件中 追溯事故來源竟终，同樣不得不從方法中直接注入 Activity 等蝠猬，這同樣埋下了內(nèi)存泄漏的隱患。現(xiàn)如今組件因?qū)崿F(xiàn)了 DefaultLifecycleObserver统捶，而得以通過生命周期回調(diào)方法中的 LifecycleOwner 參數(shù)榆芦，在方法作用域中 即可得知事故來源柄粹，無需更多帶有隱患的操作。

如果這么說還不理解的話匆绣，可具體參考我在 《為你還原一個(gè)真實(shí)的 Jetpack Lifecycle》 中提供的 GpsManager 案例驻右，本文不再累述。

Jetpack LiveData

LiveData 的存在崎淳，主要是為了幫助 新手老手 都能不假思索地遵循 通過唯一可信源分發(fā)狀態(tài) 的標(biāo)準(zhǔn)化開發(fā)理念堪夭，從而使在快速開發(fā)過程中 難以追溯、難以排查拣凹、不可預(yù)期 的問題所發(fā)生的概率降低到最小森爽。

LiveData 存在前的混沌世界

在 LiveData 面市前，我們分發(fā)狀態(tài)嚣镜，多是通過 EventBus 或 Java Interface 來完成的爬迟。不管你是用于網(wǎng)絡(luò)請求回調(diào)的情況，還是跨頁面通信的情況菊匿。

那這造成了什么問題呢付呕？首先，EventBus 只是純粹的 Bus捧请，它 缺乏上述提到的 標(biāo)準(zhǔn)化開發(fā)理念 的約束凡涩，那么人們在使用這個(gè)框架時(shí)，容易因 去中心化 地濫用疹蛉，而造成 諸如 毫無防備地收到 預(yù)期外的 不明來源的推送活箕、拿到過時(shí)的數(shù)據(jù) 及 事件源追溯復(fù)雜度 為 n2 的局面。

并且可款，EventBus 本身缺乏 Lifecycle 的加持育韩，存在生命周期管理的一致性問題。這是 EventBus 的硬傷闺鲸，也是我拒絕使用 EventBus 的最主要因素筋讨。

對上述狀況不理解的，可具體參考我在 《LiveData 鮮為人知的 身世背景 和 獨(dú)特使命》 中提供的 播放器狀態(tài)全局通知 的案例

LiveData 為什么能解決上述這些問題摸恍？

首先悉罕，LiveData 是在 Google 希望確立 標(biāo)準(zhǔn)化、規(guī)范化 的開發(fā)模式 —— 這樣一種背景下誕生的立镶，因而為了達(dá)成這個(gè)艱巨的 使命壁袄，Google 十分克制地將其設(shè)計(jì)為，僅支持狀態(tài)的輸入和監(jiān)聽媚媒，從而嗜逻，它不得不 在單例的配合下，承上啟下地完成 狀態(tài) 從 唯一可信源 到 視圖控制器 的輸送缭召。

（ViewModel 姑且也算是一種單例栈顷，一種工廠模式實(shí)現(xiàn)的偽單例逆日。唯一可信源是指 生命周期獨(dú)立于 視圖控制器的 數(shù)據(jù)組件，通常是 單例 或共享 ViewModel）

這使得任何一次狀態(tài)推送萄凤，都可預(yù)期室抽、都能方便地追溯來源，而不至于在 事件追溯復(fù)雜度為 n2 的迷宮中白費(fèi)時(shí)間蛙卤。（即狠半，無論是從哪個(gè)視圖控制器發(fā)起的 對某個(gè)共享狀態(tài)改變的請求，狀態(tài)最終的改變 都由 作為唯一可信源的 單例或 SharedViewModel 來一對多地通知改變）

image.png

并且颤难，這種承上啟下的方式神年，使得單向依賴成為可能：單例無需通過 Java Interface 回調(diào)通知視圖控制器，從而規(guī)避了視圖控制器 被生命周期更長的單例 依賴 所埋下的內(nèi)存泄漏的隱患行嗤。

LiveData 有個(gè)坑需要注意

不過已日，LiveData 的設(shè)計(jì)有個(gè)坑，這里我順帶提一下栅屏。

為了在視圖控制器發(fā)生重建后飘千，能夠 自動灌倒 所觀察的 LiveData 的最后一次數(shù)據(jù)，LiveData 被設(shè)計(jì)為粘性事件栈雳。

—— 我姑且認(rèn)為這和 Jetpack Navigation 只支持 replace 方式切換 Fragment 一樣护奈，是個(gè)拓展性不佳的設(shè)計(jì)，甚至可以說是一個(gè) bug哥纫，

因?yàn)?MVVM 是一個(gè)整體霉旗，既然 ViewModel 支持共享作用域，并且官方文檔都承認(rèn)了通過 共享 ViewModel 來實(shí)現(xiàn)跨頁面通信的需求蛀骇，

那么基于 “開閉原則”厌秒，LiveData 理應(yīng)提供一個(gè)與 MutableLiveData 平級的底層支持，專門用于非粘性的事件通信的情況擅憔，否則直接在跨頁面通信中使用 MutableLiveData 必造成 事件回調(diào)的一致性問題 及 難以預(yù)期的錯(cuò)誤鸵闪。

關(guān)于非粘性 LiveData 的實(shí)現(xiàn)，網(wǎng)上存在通過 “事件包裝類”（只適合 kotlin 的情況） 和 “反射干預(yù) LastVersion” （適用于 Java 的情況）兩種方式來解決：

juejin.im/post/5b2b1b…

blog.csdn.net/geyuecang/a…

無論是使用哪一種實(shí)現(xiàn)暑诸，我都建議 遵循傳統(tǒng) LiveData 所遵循的開發(fā)理念蚌讼，通過唯一可信源分發(fā)狀態(tài)，來方便事件源頭的追溯个榕。對于 “去中心化” 的 Bus 方式啦逆，我拒絕在項(xiàng)目中這樣使用。

（具體我會在未來開源的最佳實(shí)踐項(xiàng)目中 展示 UnPeekLiveData 的使用）

Jetpack ViewModel

ViewModel 的存在笛洛，主要是為了解決 狀態(tài)管理 和 狀態(tài)共享 的問題。

ViewModel 存在前的混沌世界

ViewModel 的本職工作是 狀態(tài)托管 和 狀態(tài)管理的分治乃坤，也即當(dāng)視圖控制器重建時(shí)苛让，

對于輕量的狀態(tài)沟蔑，可以通過視圖控制器基類的 saveInstanceState 機(jī)制，以序列化的方式完成存儲和恢復(fù)狱杰。

對于重量級的狀態(tài)瘦材，例如通過網(wǎng)絡(luò)請求得到的 List，可以通過生命周期長于視圖控制器的 ViewModel 持有仿畸，從而得以直接從 ViewModel 恢復(fù)食棕，而不是以效率較低的序列化方式。

在 Jetpack ViewModel 面市之前错沽，MVP 的 Presenter 和 MVVM - Clean 的 ViewModel 都不具備狀態(tài)管理分治的能力簿晓。

Presenter 和 Clean ViewModel 的生命周期都與視圖控制器同生共死，因而它們頂多是為 DataBinding 提供狀態(tài)的托管千埃，而無法實(shí)現(xiàn)狀態(tài)的分治憔儿。

到了 Jetpack 這一版，ViewModel 以精妙的設(shè)計(jì)放可，達(dá)成了狀態(tài)管理谒臼，以及可共享的作用域。

ViewModel 為什么能做到這幾點(diǎn)耀里？

其實(shí)這版主要是基于 工廠模式蜈缤，使得 ViewModel 被 LifecycleOwner 所持有、通過 ViewModelProvider 來引用冯挎，

所以 它既類似于單例： —— 當(dāng)被作為 LifecycleOwner 的 Activity 持有時(shí)底哥，能夠脫離 Activity 旗下 Fragment 的生命周期，從而實(shí)現(xiàn)作用域共享织堂，

實(shí)際上又不是單例： —— 生命周期跟隨 作為 LifecycleOwner 的視圖控制器叠艳，當(dāng) Owner（Activity 或 Fragment）被銷毀時(shí)，它也被 clear易阳。

此外附较，出于對視圖控制器重建的考慮，Google 在視圖控制器基類中通過 retain 機(jī)制對 ViewModel 進(jìn)行了保留潦俺。

因此拒课，對于 作用域共享 和 視圖重建 的情況，狀態(tài)因完好地被保留事示，而得以被視圖控制器在恢復(fù)時(shí)直接使用早像。

再者，由于存在 共享作用域的考慮肖爵，所以 ViewModel 本身也承擔(dān)了跨頁面通信（例如事件回調(diào)）的職責(zé)卢鹦。前面在介紹 LiveData 時(shí)，對于 LiveData 在事件通信時(shí)粘性設(shè)計(jì)的問題已經(jīng)介紹過了劝堪，這里不再累述冀自。

Jetpack DataBinding

DataBinding 的存在揉稚，主要是為了解決 視圖 的一致性問題。

DataBinding 存在前的混沌世界

在 DataBinding 面市前熬粗，我們?nèi)粢淖円晥D的狀態(tài)搀玖，首先就要引用該視圖，例如 textView.setText()驻呐，

這造成什么問題呢灌诅？

當(dāng)頁面存在橫、豎布局含末，且兩種布局的控件存在差異猜拾，例如橫屏存在 textView 控件，而豎屏沒有答渔，那么我們就不得不在視圖控制器中為 textView 做判空處理关带，這就造成了一致性問題 —— 容易疏忽而忘記判空，畢竟頁面多達(dá)數(shù)十個(gè)沼撕、每個(gè)頁面的控件也無數(shù)宋雏。

那怎么辦呢？

DataBinding 就是來解決這些問題

通過在布局中與可觀察的數(shù)據(jù)發(fā)生綁定务豺，那么當(dāng)該數(shù)據(jù)被 set 新的內(nèi)容時(shí)磨总，控件也將得到通知和刷新。

換言之笼沥，在使用 DataBinding 后蚪燕，唯一的改變是，你無需手工調(diào)用視圖來 set 新狀態(tài)奔浅，你只需 set 數(shù)據(jù)本身馆纳。

因而，DataBinding 并非許多人不假思索認(rèn)為的汹桦，將 UI 邏輯搬到 XML 中寫 從而難以調(diào)試 —— 事實(shí)根本不是這樣的：

DataBinding 只負(fù)責(zé)綁定數(shù)據(jù)鲁驶、負(fù)責(zé)作為 UI 邏輯末端的狀態(tài)的改變（也即它是一個(gè)不可再分的原子操作，本來就不需要調(diào)試）舞骆，原本在視圖控制器中 UI 邏輯怎么寫钥弯，現(xiàn)在還是怎么寫，只不過不再需要 textView.setText(xxx)督禽，而是直接 xxx.set()脆霎。

所以在 DataBinding 的幫助下，好處總共有多少個(gè)呢狈惫？

1.規(guī)避了視圖狀態(tài)的 一致性問題 —— 無需手工判空睛蛛。

2.規(guī)避了視圖狀態(tài)的 一致性問題，乃至無需視圖調(diào)用，從而完全不用編寫 findViewById玖院。

3.就算要調(diào)用視圖菠红，也不用 findViewById，而是直接通過 binding 來引用难菌。

4.先前的 UI 邏輯基本不用改動，改的只是作為末端的狀態(tài)改變的方式蔑滓。

……

此外郊酒，DataBinding 有個(gè)大殺器就是，能為控件提供自定義屬性的 BindingAdapter键袱，它不僅可以解決 圓角 Drawable 復(fù)用的問題（你懂得）燎窘，還可以實(shí)現(xiàn) imageView 直接綁定 url 等需求，總之蹄咖，沒有它辦不到的褐健，只有你想不到的，DataBinding 的好處等著你挖掘澜汤。??

關(guān)于 DataBinding 的注意事項(xiàng)蚜迅，以及屢試不爽的排坑技巧，可具體參考 《從 被反對 到 真香 的 Jetpack DataBinding俊抵！》谁不，這里不做累述。

綜上

Lifecycle 的存在徽诲，主要是為了解決 生命周期管理 的一致性問題刹帕。

LiveData 的存在，主要是為了幫助 新手老手 都能不假思索地 遵循 通過唯一可信源分發(fā)狀態(tài) 的標(biāo)準(zhǔn)化開發(fā)理念谎替，從而在快速開發(fā)過程中 規(guī)避一系列 難以追溯偷溺、難以排查、不可預(yù)期 的問題钱贯。

ViewModel 的存在挫掏，主要是為了解決 狀態(tài)管理 和 狀態(tài)共享 的問題。

DataBinding 的存在喷舀，主要是為了解決 視圖 的一致性問題砍濒。

它們的存在 大都是為了解決一致性的問題、將容易出錯(cuò)的操作在后臺封裝好硫麻，方便使用者快速爸邢、穩(wěn)定、不產(chǎn)生預(yù)期外錯(cuò)誤地編碼拿愧。

這樣說杠河，你理解了嗎？??

結(jié)語：Jetpack MVVM 最佳實(shí)踐的案例，計(jì)劃于 2019 年 10 月底 在 GitHub 發(fā)布券敌。屆時(shí)我會以各種形式留下訪問方式唾戚，敬請期待！

作者：KunMinX
鏈接：https://juejin.im/post/5dafc49b6fb9a04e17209922
來源：掘金
著作權(quán)歸作者所有待诅。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)叹坦，非商業(yè)轉(zhuǎn)載請注明出處。