金三銀四，相信有不少讀者在抓緊機(jī)會(huì)面試。
Android 市場(chǎng)已今非昔比。在過(guò)去，迫于招人的壓力，應(yīng)試者只需了解四大組件、視圖、網(wǎng)絡(luò)請(qǐng)求，即可謀得一份滿意的工作。
現(xiàn)如今，Jetpack 架構(gòu)組件 及 標(biāo)準(zhǔn)化開(kāi)發(fā)模式 的確立，意味著 Android 開(kāi)發(fā)已步入成熟階段：
許多 樣板代碼 不再需要開(kāi)發(fā)者手寫(xiě)，而是可以通過(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 有著正確、深入的理解，能夠自然而然地寫(xiě)出標(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)化 開(kāi)發(fā)模式 以減少不可預(yù)期的錯(cuò)誤 所作的努力，有著深入的理解。
因而本文的目標(biāo)，就是結(jié)合前幾期我們分別 深入淺出 介紹過(guò)的 Lifecycle、LiveData、ViewModel、DataBinding，來(lái)融匯貫通地演繹一下：
作為 應(yīng)用開(kāi)發(fā)骨架 的 標(biāo)準(zhǔn)化狀態(tài)管理框架，究竟為 快速開(kāi)發(fā)過(guò)程中 減少不可預(yù)期的錯(cuò)誤 做了哪些努力。
不同于 東拼西湊、人云亦云、徒添困擾 的網(wǎng)文，愿意將 標(biāo)準(zhǔn)化開(kāi)發(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)化開(kāi)發(fā)已成現(xiàn)實(shí)
- 本文的目標(biāo)
- Jetpack Lifecycle
- Lifecycle 存在前的混沌世界
- Lifecycle 為什么能解決上述這些問(wèn)題？
- Jetpack LiveData
- LiveData 存在前的混沌世界
- LiveData 為什么能解決上述這些問(wèn)題？
- LiveData 有個(gè)坑需要注意
- 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è)依賴(lài)它的 Activity 的 onResume 和 onPause 中都需要 手工 激活、解綁 和 叫停。
那么 隨著 Activity 的增多，這種手工操作 埋下的一致性隱患 就會(huì)指數(shù)級(jí)增長(zhǎng)：
一方面，凡是手工維持的，開(kāi)發(fā)者容易疏忽，特別是工作交接給其他同事時(shí)，同事并不能及時(shí)注意到這些細(xì)節(jié)。
另一方面，分散的代碼不利于修改，日后除了激活、叫停，若有其他操作需要補(bǔ)充（例如狀態(tài)監(jiān)聽(tīng)），那么每個(gè) Activity 都需要額外書(shū)寫(xiě)一遍。
Lifecycle 為什么能解決上述這些問(wèn)題？
Lifecycle 通過(guò) 模板方法模式 和 觀察者模式，將生命周期管理的復(fù)雜操作，全部在作為 LifecycleOwner 的基類(lèi)中（例如視圖控制器的基類(lèi)）封裝好，默默地在背后為開(kāi)發(fā)者運(yùn)籌帷幄，
開(kāi)發(fā)者因而得以在視圖控制器（子類(lèi)）中只需一句 getLifecycle().addObserver(GpsManager.getInstance) ，優(yōu)雅地完成 第三方組件在自己內(nèi)部 對(duì) LifecycleOwner 生命周期的感知。
除了解決一致性問(wèn)題，這樣做還 順帶地提供了其他 2 個(gè)好處：
1.規(guī)避 為監(jiān)聽(tīng)狀態(tài) 而 注入視圖控制器 的做法
當(dāng)需要監(jiān)聽(tīng)狀態(tài)時(shí)，以往我們的做法是 通過(guò)方法手工注入 Activity 等參數(shù)，這埋下了內(nèi)存泄漏的隱患 —— 因?yàn)閳F(tuán)隊(duì)中的新手容易因這是個(gè) Activity，而在日后誤將其依賴(lài)給組件中的其他成員。
現(xiàn)如今，我們可以直接在組件內(nèi)部 點(diǎn)到為止 地監(jiān)聽(tīng) 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)化開(kāi)發(fā)理念，從而使在快速開(kāi)發(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)化開(kāi)發(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ī)范化 的開(kāi)發(fā)模式 —— 這樣一種背景下誕生的，因而為了達(dá)成這個(gè)艱巨的 使命，Google 十分克制地將其設(shè)計(jì)為，僅支持狀態(tài)的輸入和監(jiān)聽(tīng)，從而，它不得不 在單例的配合下，承上啟下地完成 狀態(tài) 從 唯一可信源 到 視圖控制器 的輸送。
（ViewModel 姑且也算是一種單例，一種工廠模式實(shí)現(xiàn)的偽單例。唯一可信源是指 生命周期獨(dú)立于 視圖控制器的 數(shù)據(jù)組件，通常是 單例 或共享 ViewModel）
這使得任何一次狀態(tài)推送，都可預(yù)期、都能方便地追溯來(lái)源，而不至于在 事件追溯復(fù)雜度為 n2 的迷宮中白費(fèi)時(shí)間。（即，無(wú)論是從哪個(gè)視圖控制器發(fā)起的 對(duì)某個(gè)共享狀態(tài)改變的請(qǐng)求，狀態(tài)最終的改變 都由 作為唯一可信源的 單例或 SharedViewModel 來(lái)一對(duì)多地通知改變）
并且，這種承上啟下的方式，使得單向依賴(lài)成為可能：?jiǎn)卫裏o(wú)需通過(guò) Java Interface 回調(diào)通知視圖控制器，從而規(guī)避了視圖控制器 被生命周期更長(zhǎng)的單例 依賴(lài) 所埋下的內(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)?MVVM 是一個(gè)整體，既然 ViewModel 支持共享作用域，并且官方文檔都承認(rèn)了通過(guò) 共享 ViewModel 來(lái)實(shí)現(xiàn)跨頁(yè)面通信的需求，
那么基于 “開(kāi)閉原則”，LiveData 理應(yīng)提供一個(gè)與 MutableLiveData 平級(jí)的底層支持，專(zhuān)門(mén)用于非粘性的事件通信的情況，否則直接在跨頁(yè)面通信中使用 MutableLiveData 必造成 事件回調(diào)的一致性問(wèn)題 及 難以預(yù)期的錯(cuò)誤。
關(guān)于非粘性 LiveData 的實(shí)現(xiàn)，網(wǎng)上存在通過(guò) “事件包裝類(lèi)”（只適合 kotlin 的情況） 和 “反射干預(yù) LastVersion” （適用于 Java 的情況）兩種方式來(lái)解決：
無(wú)論是使用哪一種實(shí)現(xiàn)，我都建議 遵循傳統(tǒng) LiveData 所遵循的開(kāi)發(fā)理念，通過(guò)唯一可信源分發(fā)狀態(tài)，來(lái)方便事件源頭的追溯。對(duì)于 “去中心化” 的 Bus 方式，我拒絕在項(xiàng)目中這樣使用。
（具體我會(huì)在未來(lái)開(kāi)源的最佳實(shí)踐項(xiàng)目中 展示 UnPeekLiveData 的使用）
Jetpack ViewModel
ViewModel 的存在，主要是為了解決 狀態(tài)管理 和 頁(yè)面通信 的問(wèn)題。
ViewModel 存在前的混沌世界
ViewModel 的本職工作是 狀態(tài)托管 和 狀態(tài)管理的分治，也即當(dāng)視圖控制器重建時(shí)，
對(duì)于輕量的狀態(tài)，可以通過(guò)視圖控制器基類(lèi)的 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)引用，
所以 它既類(lèi)似于單例： —— 當(dāng)被作為 LifecycleOwner 的 Activity 持有時(shí)，能夠脫離 Activity 旗下 Fragment 的生命周期，從而實(shí)現(xiàn)作用域共享，
實(shí)際上又不是單例： —— 生命周期跟隨 作為 LifecycleOwner 的視圖控制器，當(dāng) Owner（Activity 或 Fragment）被銷(xiāo)毀時(shí)，它也被 clear。
此外，出于對(duì)視圖控制器重建的考慮，Google 在視圖控制器基類(lèi)中通過(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í)，控件也將得到通知和刷新。
換言之，在使用 DataBinding 后，唯一的改變是，你無(wú)需手工調(diào)用視圖來(lái) set 新?tīng)顟B(tài)，你只需 set 數(shù)據(jù)本身。
因而，DataBinding 并非許多人不假思索認(rèn)為的，將 UI 邏輯搬到 XML 中寫(xiě) 從而難以調(diào)試 —— 事實(shí)根本不是這樣的：
DataBinding 只負(fù)責(zé)綁定數(shù)據(jù)、負(fù)責(zé)作為 UI 邏輯末端的狀態(tài)的改變（也即它是一個(gè)不可再分的原子操作，本來(lái)就不需要調(diào)試），原本在視圖控制器中 UI 邏輯怎么寫(xiě)，現(xiàn)在還是怎么寫(xiě)，只不過(guò)不再需要 textView.setText(xxx)，而是直接 xxx.set()。
所以在 DataBinding 的幫助下，好處總共有多少個(gè)呢？
1.規(guī)避了視圖狀態(tài)的 一致性問(wèn)題 —— 無(wú)需手工判空。
2.規(guī)避了視圖狀態(tài)的 一致性問(wèn)題，乃至無(wú)需視圖調(diào)用，從而完全不用編寫(xiě) 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)化開(kāi)發(fā)理念，從而在快速開(kāi)發(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ò)誤地編碼。
