前言
最近在后臺(tái) 時(shí)有收到 讀者的留言，說(shuō)能不能出一期 Jetpack MVVM 精講，以及配套一份簡(jiǎn)練的案例，好 把玩把玩、感受感受、加深對(duì) MVVM 的印象。
答案是肯定的。
面向標(biāo)準(zhǔn)化開發(fā)已成現(xiàn)實(shí)
金九銀十，相信有不少讀者在抓緊機(jī)會(huì)面試。
Android 市場(chǎng)已今非昔比。在過(guò)去，迫于招人的壓力，應(yīng)試者只需了解四大組件、視圖、網(wǎng)絡(luò)請(qǐng)求，即可謀得一份滿意的工作。
現(xiàn)如今，Jetpack 架構(gòu)組件 及 標(biāo)準(zhǔn)化開發(fā)模式 的確立，意味著 Android 開發(fā)已步入成熟階段：
許多 樣板代碼 不再需要開發(fā)者手寫，而是可以通過(guò)模版工具 自動(dòng)生成，在取締繁雜耗時(shí)的重復(fù)工作的同時(shí)，避免因人工操作的疏忽，而造成難以排查、不可預(yù)期的錯(cuò)誤。
這十分符合企業(yè)的利益，因而面試官在招人的時(shí)候，也更加看重應(yīng)試者對(duì) 架構(gòu)組件 —— 至少是 MVVM 的理解程度。
像“解耦”等 含糊其辭的說(shuō)法，已經(jīng)不能夠被面試官所認(rèn)可，稍微對(duì) MVVM 有一點(diǎn)經(jīng)驗(yàn)的面試官都會(huì)請(qǐng)你舉例說(shuō)明，好證明你確實(shí)對(duì) MVVM 有著正確、深入的理解，能夠自然而然地寫出標(biāo)準(zhǔn)化、規(guī)范化的代碼，能夠迅速適應(yīng) 各家公司自制的 自動(dòng)化模版工具。
本文的目標(biāo)
本人擁有 3 年的 移動(dòng)端架構(gòu) 踐行和設(shè)計(jì)經(jīng)驗(yàn)，領(lǐng)導(dǎo)或參與團(tuán)隊(duì)重構(gòu)的中大型項(xiàng)目多達(dá)十?dāng)?shù)個(gè)，對(duì) Jetpack MVVM 架構(gòu)在確立規(guī)范化、標(biāo)準(zhǔn)化 開發(fā)模式 以減少不可預(yù)期的錯(cuò)誤 所作的努力，有著深入的理解。
因而本文的目標(biāo)，就是結(jié)合前幾期我們分別 深入淺出 介紹過(guò)的 Lifecycle、LiveData、ViewModel、DataBinding，來(lái)融匯貫通地演繹一下：
作為 應(yīng)用開發(fā)骨架 的 標(biāo)準(zhǔn)化狀態(tài)管理框架，究竟為 快速開發(fā)過(guò)程中 減少不可預(yù)期的錯(cuò)誤 做了哪些努力。
不同于 東拼西湊、人云亦云、徒添困擾 的網(wǎng)文，愿意將 標(biāo)準(zhǔn)化開發(fā)模式的 深度思考知識(shí) 和 實(shí)戰(zhàn)反思經(jīng)驗(yàn) 無(wú)保留地分享，全網(wǎng)僅此一家。這樣的文章可以說(shuō)是 看一篇、少一篇，因此，就算不去 hold 住面試官，也請(qǐng)務(wù)必跟隨本文的腳步，無(wú)障礙地將 Jetpack MVVM 過(guò)一遍！
文章目錄一覽
- 前言
- 面向標(biāo)準(zhǔn)化開發(fā)已成現(xiàn)實(shí)
- 本文的目標(biāo)
- Jetpack Lifecycle
- Lifecycle 存在前的混沌世界
- Lifecycle 為什么能解決上述這些問(wèn)題？
- Jetpack LiveData
- LiveData 存在前的混沌世界
- LiveData 為什么能解決上述這些問(wèn)題？
- LiveData 有個(gè)坑需要注意
- Note 2020.07.09 加餐
- Jetpack ViewModel
- ViewModel 存在前的混沌世界
- ViewModel 為什么能做到這幾點(diǎn)？
- Jetpack DataBinding
- DataBinding 存在前的混沌世界
- DataBinding 就是來(lái)解決這些問(wèn)題
- 綜上
Jetpack Lifecycle
Lifecycle 的存在，主要是為了解決 生命周期管理 的一致性問(wèn)題
Lifecycle 存在前的混沌世界
在 Lifecycle 面市前，生命周期管理 純靠手工維持，這樣就容易滋生大量的一致性問(wèn)題。
例如跨頁(yè)面共享的 GpsManager 組件，在每個(gè)依賴它的 Activity 的 onResume 和 onPause 中都需要 手工 激活、解綁 和 叫停。
那么 隨著 Activity 的增多，這種手工操作 埋下的一致性隱患 就會(huì)指數(shù)級(jí)增長(zhǎng)：
一方面，凡是手工維持的，開發(fā)者容易疏忽，特別是工作交接給其他同事時(shí)，同事并不能及時(shí)注意到這些細(xì)節(jié)。
另一方面，分散的代碼不利于修改，日后除了激活、叫停，若有其他操作需要補(bǔ)充（例如狀態(tài)監(jiān)聽），那么每個(gè) Activity 都需要額外書寫一遍。
Lifecycle 為什么能解決上述這些問(wèn)題？
Lifecycle 通過(guò) 模板方法模式 和 觀察者模式，將生命周期管理的復(fù)雜操作，全部在作為 LifecycleOwner 的基類中（例如視圖控制器的基類）封裝好，默默地在背后為開發(fā)者運(yùn)籌帷幄，
開發(fā)者因而得以在視圖控制器（子類）中只需一句 getLifecycle().addObserver(GpsManager.getInstance) ，優(yōu)雅地完成 第三方組件在自己內(nèi)部 對(duì) LifecycleOwner 生命周期的感知。
除了解決一致性問(wèn)題，這樣做還 順帶地提供了其他 2 個(gè)好處：
1.規(guī)避 為監(jiān)聽狀態(tài) 而 注入視圖控制器 的做法
當(dāng)需要監(jiān)聽狀態(tài)時(shí)，以往我們的做法是 通過(guò)方法手工注入 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ī)避 為追溯事故來(lái)源 而 注入視圖控制器 的做法
當(dāng)發(fā)生事故時(shí)，以往我們?nèi)粝朐诮M件中 追溯事故來(lái)源，同樣不得不從方法中直接注入 Activity 等，這同樣埋下了內(nèi)存泄漏的隱患。現(xiàn)如今組件因?qū)崿F(xiàn)了 DefaultLifecycleObserver，而得以通過(guò)生命周期回調(diào)方法中的 LifecycleOwner 參數(shù)，在方法作用域中 即可得知事故來(lái)源，無(wú)需更多帶有隱患的操作。
如果這么說(shuō)還不理解的話，可具體參考我在 《為你還原一個(gè)真實(shí)的 Jetpack Lifecycle》 中提供的 GpsManager 案例，本文不再累述。
Jetpack LiveData
LiveData 的存在，主要是為了幫助 新手老手 都能不假思索地遵循 通過(guò)唯一可信源分發(fā)狀態(tài) 的標(biāo)準(zhǔn)化開發(fā)理念，從而使在快速開發(fā)過(guò)程中 難以追溯、難以排查、不可預(yù)期 的問(wèn)題所發(fā)生的概率降低到最小。
LiveData 存在前的混沌世界
在 LiveData 面市前，我們分發(fā)狀態(tài)，多是通過(guò) EventBus 或 Java Interface 來(lái)完成的。不管你是用于網(wǎng)絡(luò)請(qǐng)求回調(diào)的情況，還是跨頁(yè)面通信的情況。
那這造成了什么問(wèn)題呢？首先，EventBus 只是純粹的 Bus，它 缺乏上述提到的 標(biāo)準(zhǔn)化開發(fā)理念 的約束，那么人們?cè)谑褂眠@個(gè)框架時(shí)，容易因 去中心化 地濫用，而造成 諸如 毫無(wú)防備地收到 預(yù)期外的 不明來(lái)源的推送、拿到過(guò)時(shí)的數(shù)據(jù) 及 事件源追溯復(fù)雜度 為 n2 的局面。
并且，EventBus 本身缺乏 Lifecycle 的加持，存在生命周期管理的一致性問(wèn)題。這是 EventBus 的硬傷，也是我拒絕使用 EventBus 的最主要因素。
對(duì)上述狀況不理解的，可具體參考我在 《LiveData 鮮為人知的 身世背景 和 獨(dú)特使命》 中提供的 播放器狀態(tài)全局通知 的案例
LiveData 為什么能解決上述這些問(wèn)題？
首先，LiveData 是在 Google 希望確立 標(biāo)準(zhǔn)化、規(guī)范化 的開發(fā)模式 —— 這樣一種背景下誕生的，因而為了達(dá)成這個(gè)艱巨的 使命，LiveData 被十分克制地設(shè)計(jì)為，僅支持狀態(tài)的輸入和監(jiān)聽，并且可基于 “訪問(wèn)權(quán)限控制” 來(lái)實(shí)現(xiàn) “讀寫分離”。
這使得任何一次數(shù)據(jù)推送，都可被限制為 “只能單方面地從唯一可信源推送而來(lái)”，從而避免了消息同步不一致、不可靠、或是在事件追溯復(fù)雜度為 n2 的迷宮中白費(fèi)時(shí)間。（也即，無(wú)論是從哪個(gè)視圖控制器發(fā)起的 對(duì)某個(gè)共享狀態(tài)改變的請(qǐng)求，狀態(tài)最終的改變 都由 作為唯一可信源的 單例或 SharedViewModel 在其內(nèi)部統(tǒng)一決策，并一對(duì)多地通知改變）
并且，這種承上啟下的方式，使得單向依賴成為可能：?jiǎn)卫裏o(wú)需通過(guò) Java Interface 回調(diào)通知視圖控制器，從而規(guī)避了視圖控制器 被生命周期更長(zhǎng)的單例 依賴 所埋下的內(nèi)存泄漏的隱患。
LiveData 有個(gè)坑需要注意
不過(guò)，LiveData 的設(shè)計(jì)有個(gè)坑，這里我順帶提一下。
為了在視圖控制器發(fā)生重建后，能夠 自動(dòng)倒灌 所觀察的 LiveData 的最后一次數(shù)據(jù)，LiveData 被設(shè)計(jì)為粘性事件。
—— 我姑且認(rèn)為這是個(gè)拓展性不佳的設(shè)計(jì)，甚至可以說(shuō)是一個(gè) bug，
因?yàn)?Jetpack MVVM 是一個(gè)整體，既然 ViewModel 支持共享作用域，并且官方文檔都承認(rèn)了通過(guò) 共享 ViewModel 來(lái)實(shí)現(xiàn)跨頁(yè)面通信的需求，
那么基于 “開閉原則”，LiveData 理應(yīng)提供一個(gè)與 MutableLiveData 平級(jí)的底層支持，專門用于非粘性的事件通信的情況，否則直接在跨頁(yè)面通信中使用 MutableLiveData 必造成 事件回調(diào)的一致性問(wèn)題 及 難以預(yù)期的錯(cuò)誤。
無(wú)論是使用哪一種實(shí)現(xiàn)，我都建議 遵循傳統(tǒng) LiveData 所遵循的開發(fā)理念，通過(guò)唯一可信源分發(fā)狀態(tài)，來(lái)確保消息同步的可預(yù)期和可追溯。對(duì)于 “去中心化” 的 Bus 方式，我拒絕在項(xiàng)目中這樣使用。
Note 2020.07.09 加餐：
| Event 包裝器 | 非入侵重寫 | UnPeekLiveData |
|---|---|---|
 |
 |
 |
考慮到手寫 Event 事件包裝器，在 Java 中存在 null 安全的一致性問(wèn)題；而反射干預(yù) Version 的方式又存在延遲（無(wú)法用于對(duì)實(shí)時(shí)性有要求的場(chǎng)景）、并且數(shù)據(jù)會(huì)隨著 SharedViewModel 長(zhǎng)久滯留在內(nèi)存中得不到釋放。
于是重寫并封裝了 專用于 “一次性事件” 場(chǎng)景需求 的
UnPeek-LiveData。
UnPeek-LiveData 經(jīng)過(guò)小伙伴們的熱心嘗試和反饋，現(xiàn)已演化成熟并滿足：
一條消息能被多個(gè)觀察者消費(fèi)
消息被所有觀察者消費(fèi)完畢后才開始阻止倒灌
可以通過(guò) clear 方法手動(dòng)將消息從內(nèi)存中移除
讓非入侵設(shè)計(jì)成為可能，遵循開閉原則
基于 “訪問(wèn)權(quán)限控制” 支持 "讀寫分離”，遵循唯一可信源的消息分發(fā)理念
具體可詳見(jiàn)《LiveData 數(shù)據(jù)倒灌 背景緣由全貌 獨(dú)家解析》篇 及參考 《UnPeek-LiveData》 最新源碼。
Jetpack ViewModel
ViewModel 的存在，主要是為了解決 狀態(tài)管理 和 頁(yè)面通信 的問(wèn)題。
ViewModel 存在前的混沌世界
ViewModel 的本職工作是 狀態(tài)托管 和 狀態(tài)管理的分治，也即當(dāng)視圖控制器重建時(shí)，
對(duì)于輕量的狀態(tài)，可以通過(guò)視圖控制器基類的 saveInstanceState 機(jī)制，以序列化的方式完成存儲(chǔ)和恢復(fù)。
對(duì)于重量級(jí)的狀態(tài)，例如通過(guò)網(wǎng)絡(luò)請(qǐng)求得到的 List，可以通過(guò)生命周期長(zhǎng)于視圖控制器的 ViewModel 持有，從而得以直接從 ViewModel 恢復(fù)，而不是以效率較低的序列化方式。
在 Jetpack ViewModel 面市之前，MVP 的 Presenter 和 MVVM - Clean 的 ViewModel 都不具備狀態(tài)管理分治的能力。
Presenter 和 Clean ViewModel 的生命周期都與視圖控制器同生共死，因而它們頂多是為 DataBinding 提供狀態(tài)的托管，而無(wú)法實(shí)現(xiàn)狀態(tài)的分治。
到了 Jetpack 這一版，ViewModel 以精妙的設(shè)計(jì)，達(dá)成了狀態(tài)管理，以及可共享的作用域。
ViewModel 為什么能做到這幾點(diǎn)？
其實(shí)這版主要是基于 工廠模式，使得 ViewModel 被 LifecycleOwner 所持有、通過(guò) ViewModelProvider 來(lái)引用，
所以 它既類似于單例：
—— 當(dāng)被作為 LifecycleOwner 的 Activity 持有時(shí)，能夠脫離 Activity 旗下 Fragment 的生命周期，從而實(shí)現(xiàn)作用域共享，
實(shí)際上又不是單例：
—— 生命周期跟隨 作為 LifecycleOwner 的視圖控制器，當(dāng) Owner（Activity 或 Fragment）被銷毀時(shí)，它也被 clear。
此外，出于對(duì)視圖控制器重建的考慮，Google 在視圖控制器基類中通過(guò) retain 機(jī)制對(duì) ViewModel 進(jìn)行了保留。
因此，對(duì)于 作用域共享 和 視圖重建 的情況，狀態(tài)因完好地被保留，而得以被視圖控制器在恢復(fù)時(shí)直接使用。
再者，由于存在 共享作用域的考慮，所以 ViewModel 本身也承擔(dān)了跨頁(yè)面通信（例如事件回調(diào)）的職責(zé)。前面在介紹 LiveData 時(shí)，對(duì)于 LiveData 在事件通信時(shí)粘性設(shè)計(jì)的問(wèn)題已經(jīng)介紹過(guò)了，這里不再累述。
截至 2020.2.1，ViewModel 在 Fragment 中的 retain 設(shè)計(jì)已發(fā)生劇變，具體緣由可參考我在 《有了 Jetpack ViewModel . . . 真的可以為所欲為！》 文末及評(píng)論區(qū)的最新補(bǔ)充。
Jetpack DataBinding
DataBinding 的存在，主要是為了解決 視圖調(diào)用 的一致性問(wèn)題。
DataBinding 存在前的混沌世界
在 DataBinding 面市前，我們?nèi)粢淖円晥D的狀態(tài)，首先就要引用該視圖，例如 textView.setText()，
這造成什么問(wèn)題呢？
當(dāng)頁(yè)面存在橫、豎布局，且兩種布局的控件存在差異，例如橫屏存在 textView 控件，而豎屏沒(méi)有，那么我們就不得不在視圖控制器中為 textView 做判空處理，這就造成了一致性問(wèn)題 —— 容易疏忽而忘記判空，畢竟頁(yè)面多達(dá)數(shù)十個(gè)、每個(gè)頁(yè)面的控件也無(wú)數(shù)。
那怎么辦呢？
DataBinding 就是來(lái)解決這些問(wèn)題
通過(guò)讓 “布局中存在的控件” 與 “可觀察的數(shù)據(jù)” 發(fā)生綁定，那么當(dāng)該數(shù)據(jù)被 set 新的內(nèi)容時(shí)，被綁定了該數(shù)據(jù)的控件即可獲得通知和刷新。
Note 2020.4.18：這一切都是 “編譯時(shí)自動(dòng)生成的中間代碼” 在背后完成的邏輯銜接，也即控件如存在于布局中（例如豎屏布局中）且綁定了可觀察數(shù)據(jù)，就會(huì)被調(diào)用和通知，如不存在（例如橫屏布局中），就沒(méi)被調(diào)用，無(wú)論哪一種情況都不至于發(fā)生 null 安全一致性問(wèn)題。
換言之，在使用 DataBinding 后，唯一的改變是，你無(wú)需手工調(diào)用視圖來(lái) 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è)不可再分的原子操作，本來(lái)就不需要調(diào)試），原本在視圖控制器中 UI 邏輯怎么寫，現(xiàn)在還是怎么寫，只不過(guò)不再需要 textView.setText(xxx)，而是直接 xxx.set()。
所以在 DataBinding 的幫助下，好處總共有多少個(gè)呢？
1.規(guī)避了視圖狀態(tài)的 一致性問(wèn)題 —— 無(wú)需手工判空。
2.規(guī)避了視圖狀態(tài)的 一致性問(wèn)題，乃至無(wú)需視圖調(diào)用，從而完全不用編寫 findViewById。
3.就算要調(diào)用視圖，也不用 findViewById，而是直接通過(guò) binding 來(lái)引用。
4.先前的 UI 邏輯基本不用改動(dòng)，改的只是作為末端的狀態(tài)改變的方式。
……
此外，DataBinding 有個(gè)大殺器就是，能為控件提供自定義屬性的 BindingAdapter，它不僅可以解決 圓角 Drawable 復(fù)用的問(wèn)題（你懂得），還可以實(shí)現(xiàn) imageView 直接綁定 url 等需求，總之，沒(méi)有它辦不到的，只有你想不到的，DataBinding 的好處等著你挖掘。
關(guān)于 DataBinding 的注意事項(xiàng)，以及屢試不爽的排坑技巧，可具體參考 《從 被誤解 到 真香 的 Jetpack DataBinding！》，這里不做累述。
綜上
Lifecycle 的存在，主要是為了解決 生命周期管理 的一致性問(wèn)題。
LiveData 的存在，主要是為了幫助 新手老手 都能不假思索地 遵循 通過(guò)唯一可信源分發(fā)狀態(tài) 的標(biāo)準(zhǔn)化開發(fā)理念，從而在快速開發(fā)過(guò)程中 規(guī)避一系列 難以追溯、難以排查、不可預(yù)期 的問(wèn)題。
ViewModel 的存在，主要是為了解決 狀態(tài)管理 和 頁(yè)面通信 的問(wèn)題。
DataBinding 的存在，主要是為了解決 視圖調(diào)用 的一致性問(wèn)題。
它們的存在 大都是為了 在軟件工程的背景下 解決一致性的問(wèn)題、將容易出錯(cuò)的操作在后臺(tái)封裝好，方便使用者快速、穩(wěn)定、不產(chǎn)生預(yù)期外錯(cuò)誤地編碼。
這樣說(shuō)，你理解了嗎？
GitHub : Jetpack-MVVM-Best-Practice
版權(quán)聲明
本文以 CC 署名-非商業(yè)性使用-禁止演繹 4.0 國(guó)際協(xié)議 發(fā)行。
Copyright ? 2019-present KunMinX
文中提到的 “xxx 架構(gòu)組件的存在，主要是為了在 多人協(xié)作的軟件工程背景下 解決 xxx 的一致性問(wèn)題”，以及 “LiveData 在頁(yè)面通信、事件回調(diào)的場(chǎng)景下發(fā)生 數(shù)據(jù)倒灌” 等多處 對(duì)特定現(xiàn)象及其本質(zhì)的匹配和概括，均屬于本人獨(dú)立原創(chuàng)的成果，本人對(duì)此享有所有權(quán)和最終解釋權(quán)。
當(dāng)您借鑒或引用本文的引言、思路、結(jié)論進(jìn)行二次創(chuàng)作，或全文轉(zhuǎn)載時(shí)，須注明鏈接出處，否則我們保留追責(zé)的權(quán)利。
未經(jīng)與作者本人當(dāng)面溝通許可，不得將文章內(nèi)容用于洗稿、廣告包裝等商業(yè)用途。
