今天推送一篇關於 Android 架構的最佳實踐項目。
文章目錄一覽
- 前言
- 面向標準化開發已成現實
- 本文的目標
- Jetpack Lifecycle
- Lifecycle 存在前的混沌世界
- Lifecycle 為什麼能解決上述這些問題？
- Jetpack LiveData
- LiveData 存在前的混沌世界
- LiveData 為什麼能解決上述這些問題？
- LiveData 有個坑需要注意
- Jetpack ViewModel
- ViewModel 存在前的混沌世界
- ViewModel 為什麼能做到這幾點？
- Jetpack DataBinding
- DataBinding 存在前的混沌世界
- DataBinding 就是來解決這些問題
- 綜上
Jetpack Lifecycle
Lifecycle 的存在，主要是為了解決 生命週期管理 的一致性問題
Lifecycle 存在前的混沌世界
在 Lifecycle 面市前，生命週期管理 純靠手工維持，這樣就容易滋生大量的一致性問題。
例如跨頁面共享的 GpsManager 組件，在每個依賴它的 Activity 的 onResume 和 onPause 中都需要 手工 激活、解綁 和 叫停。
那麼 隨著 Activity 的增多，這種手工操作 埋下的一致性隱患 就會指數級增長：
一方面，凡是手工維持的，開發者容易疏忽，特別是工作交接給其他同事時，同事並不能及時注意到這些細節。
另一方面，分散的代碼不利於修改，日後除了激活、叫停，若有其他操作需要補充（例如狀態監聽），那麼每個 Activity 都需要額外書寫一遍。
Lifecycle 為什麼能解決上述這些問題？
Lifecycle 通過 模板方法模式 和 觀察者模式，將生命週期管理的複雜操作，全部在作為 LifecycleOwner 的基類中（例如視圖控制器的基類）封裝好，默默地在背後為開發者運籌帷幄，
開發者因而得以在視圖控制器（子類）中只需一句：
getLifecycle().addObserver(GpsManager.getInstance) ，優雅地完成 第三方組件在自己內部 對 LifecycleOwner 生命週期的感知。
除了解決一致性問題，這樣做還 順帶地提供了其他 2 個好處：
1. 規避 為監聽狀態 而 注入視圖控制器 的做法
當需要監聽狀態時，以往我們的做法是 通過方法手工注入 Activity 等參數，這埋下了內存洩漏的隱患 —— 因為團隊中的新手容易因這是個 Activity，而在日後誤將其依賴給組件中的其他成員。
現如今，我們可以直接在組件內部 點到為止 地監聽 LifecycleOwner 的狀態，從而規避這種不恰當的使用。
2. 規避 為追溯事故來源 而 注入視圖控制器 的做法
當發生事故時，以往我們若想在組件中 追溯事故來源，同樣不得不從方法中直接注入 Activity 等，這同樣埋下了內存洩漏的隱患。現如今組件因實現了 DefaultLifecycleObserver，而得以通過生命週期回調方法中的 LifecycleOwner 參數，在方法作用域中 即可得知事故來源，無需更多帶有隱患的操作。
如果這麼說還不理解的話，可具體參考我在 《為你還原一個真實的 Jetpack Lifecycle》 中提供的 GpsManager 案例，本文不再累述。
Jetpack LiveData
LiveData 的存在，主要是為了幫助 新手老手 都能不假思索地遵循 通過唯一可信源分發狀態 的標準化開發理念，從而使在快速開發過程中 難以追溯、難以排查、不可預期 的問題所發生的概率降低到最小。
LiveData 存在前的混沌世界
在 LiveData 面市前，我們分發狀態，多是通過 EventBus 或 Java Interface 來完成的。不管你是用於網絡請求回調的情況，還是跨頁面通信的情況。
那這造成了什麼問題呢？首先，EventBus 只是純粹的 Bus，它 缺乏上述提到的 標準化開發理念 的約束，那麼人們在使用這個框架時，容易因 去中心化 地濫用，而造成 諸如 毫無防備地收到 預期外的 不明來源的推送、拿到過時的數據 及 事件源追溯複雜度 為 n² 的局面。
並且，EventBus 本身缺乏 Lifecycle 的加持，存在生命週期管理的一致性問題。這是 EventBus 的硬傷，也是我拒絕使用 EventBus 的最主要因素。
對上述狀況不理解的，可具體參考我在 《LiveData 鮮為人知的 身世背景 和 獨特使命》 中提供的 播放器狀態全局通知 的案例
LiveData 為什麼能解決上述這些問題？
首先，LiveData 是在 Google 希望確立 標準化、規範化 的開發模式 —— 這樣一種背景下誕生的，因而為了達成這個艱鉅的 使命，Google 十分克制地將其設計為，僅支持狀態的輸入和監聽，從而，它不得不 在單例的配合下，承上啟下地完成 狀態 從 唯一可信源 到 視圖控制器 的輸送。
（ViewModel 姑且也算是一種單例，一種工廠模式實現的偽單例。唯一可信源是指 生命週期獨立於 視圖控制器的 數據組件，通常是 單例 或共享 ViewModel）
這使得任何一次狀態推送，都可預期、都能方便地追溯來源，而不至於在 事件追溯複雜度為 n² 的迷宮中白費時間。（即，無論是從哪個視圖控制器發起的 對某個共享狀態改變的請求，狀態最終的改變 都由 作為唯一可信源的 單例或 SharedViewModel 來一對多地通知改變）
並且，這種承上啟下的方式，使得單向依賴成為可能：單例無需通過 Java Interface 回調通知視圖控制器，從而規避了視圖控制器 被生命週期更長的單例 依賴 所埋下的內存洩漏的隱患。
LiveData 有個坑需要注意
不過，LiveData 的設計有個坑，這裡我順帶提一下。
為了在視圖控制器發生重建後，能夠 自動灌倒 所觀察的 LiveData 的最後一次數據，LiveData 被設計為粘性事件。
—— 我姑且認為這是個拓展性不佳的設計，甚至可以說是一個 bug，
因為 MVVM 是一個整體，既然 ViewModel 支持共享作用域，並且官方文檔都承認了通過 共享 ViewModel 來實現跨頁面通信的需求，
那麼基於 “開閉原則”，LiveData 理應提供一個與 MutableLiveData 平級的底層支持，專門用於非粘性的事件通信的情況，否則直接在跨頁面通信中使用 MutableLiveData 必造成 事件回調的一致性問題 及 難以預期的錯誤。
關於非粘性 LiveData 的實現，網上存在通過 “事件包裝類”（只適合 kotlin 的情況） 和 “反射干預 LastVersion” （適用於 Java 的情況）兩種方式來解決：
juejin.im/post/5b2b1b…
blog.csdn.net/geyuecang/a…
無論是使用哪一種實現，我都建議 遵循傳統 LiveData 所遵循的開發理念，通過唯一可信源分發狀態，來方便事件源頭的追溯。對於 “去中心化” 的 Bus 方式，我拒絕在項目中這樣使用。
（具體我會在未來開源的最佳實踐項目中 展示 UnPeekLiveData 的使用）
Jetpack ViewModel
ViewModel 的存在，主要是為了解決 狀態管理 和 頁面通信 的問題。
ViewModel 存在前的混沌世界
ViewModel 的本職工作是 狀態託管 和 狀態管理的分治，也即當視圖控制器重建時，
對於輕量的狀態，可以通過視圖控制器基類的 saveInstanceState 機制，以序列化的方式完成存儲和恢復。
對於重量級的狀態，例如通過網絡請求得到的 List，可以通過生命週期長於視圖控制器的 ViewModel 持有，從而得以直接從 ViewModel 恢復，而不是以效率較低的序列化方式。
在 Jetpack ViewModel 面市之前，MVP 的 Presenter 和 MVVM - Clean 的 ViewModel 都不具備狀態管理分治的能力。
Presenter 和 Clean ViewModel 的生命週期都與視圖控制器同生共死，因而它們頂多是為 DataBinding 提供狀態的託管，而無法實現狀態的分治。
到了 Jetpack 這一版，ViewModel 以精妙的設計，達成了狀態管理，以及可共享的作用域。
ViewModel 為什麼能做到這幾點？
其實這版主要是基於 工廠模式，使得 ViewModel 被 LifecycleOwner 所持有、通過 ViewModelProvider 來引用，
所以 它既類似於單例：—— 當被作為 LifecycleOwner 的 Activity 持有時，能夠脫離 Activity 旗下 Fragment 的生命週期，從而實現作用域共享，
實際上又不是單例：—— 生命週期跟隨 作為 LifecycleOwner 的視圖控制器，當 Owner（Activity 或 Fragment）被銷燬時，它也被 clear。
此外，出於對視圖控制器重建的考慮，Google 在視圖控制器基類中通過 retain 機制對 ViewModel 進行了保留。
因此，對於 作用域共享 和 視圖重建 的情況，狀態因完好地被保留，而得以被視圖控制器在恢復時直接使用。
再者，由於存在 共享作用域的考慮，所以 ViewModel 本身也承擔了跨頁面通信（例如事件回調）的職責。前面在介紹 LiveData 時，對於 LiveData 在事件通信時粘性設計的問題已經介紹過了，這裡不再累述。
Jetpack DataBinding
DataBinding 的存在，主要是為了解決 視圖調用 的一致性問題。
DataBinding 存在前的混沌世界
在 DataBinding 面市前，我們若要改變視圖的狀態，首先就要引用該視圖，例如 textView.setText()，
這造成什麼問題呢？
當頁面存在橫、豎佈局，且兩種佈局的控件存在差異，例如橫屏存在 textView 控件，而豎屏沒有，那麼我們就不得不在視圖控制器中為 textView 做判空處理，這就造成了一致性問題 —— 容易疏忽而忘記判空，畢竟頁面多達數十個、每個頁面的控件也無數。
那怎麼辦呢？
DataBinding 就是來解決這些問題
通過在佈局中與可觀察的數據發生綁定，那麼當該數據被 set 新的內容時，控件也將得到通知和刷新。
換言之，在使用 DataBinding 後，唯一的改變是，你無需手工調用視圖來 set 新狀態，你只需 set 數據本身。
因而，DataBinding 並非許多人不假思索認為的，將 UI 邏輯搬到 XML 中寫 從而難以調試 —— 事實根本不是這樣的：
DataBinding 只負責綁定數據、負責作為 UI 邏輯末端的狀態的改變（也即它是一個不可再分的原子操作，本來就不需要調試），原本在視圖控制器中 UI 邏輯怎麼寫，現在還是怎麼寫，只不過不再需要 textView.setText(xxx)，而是直接 xxx.set()。
所以在 DataBinding 的幫助下，好處總共有多少個呢？
1.規避了視圖狀態的 一致性問題 —— 無需手工判空。
2.規避了視圖狀態的 一致性問題，乃至無需視圖調用，從而完全不用編寫 findViewById。
3.就算要調用視圖，也不用 findViewById，而是直接通過 binding 來引用。
4.先前的 UI 邏輯基本不用改動，改的只是作為末端的狀態改變的方式。
……
此外，DataBinding 有個大殺器就是，能為控件提供自定義屬性的 BindingAdapter，它不僅可以解決 圓角 Drawable 複用的問題（你懂得），還可以實現 imageView 直接綁定 url 等需求，總之，沒有它辦不到的，只有你想不到的，DataBinding 的好處等著你挖掘。
關於 DataBinding 的注意事項，以及屢試不爽的排坑技巧，可具體參考 《從 被誤解 到 真香 的 Jetpack DataBinding！》，這裡不做累述。
綜上
Lifecycle 的存在，主要是為了解決 生命週期管理 的一致性問題。
LiveData 的存在，主要是為了幫助 新手老手 都能不假思索地 遵循 通過唯一可信源分發狀態 的標準化開發理念，從而在快速開發過程中 規避一系列 難以追溯、難以排查、不可預期 的問題。
ViewModel 的存在，主要是為了解決 狀態管理 和 頁面通信 的問題。
DataBinding 的存在，主要是為了解決 視圖調用 的一致性問題。
它們的存在 大都是為了 在軟件工程的背景下 解決一致性的問題、將容易出錯的操作在後臺封裝好，方便使用者快速、穩定、不產生預期外錯誤地編碼。
這樣說，你理解了嗎？
文章不易，如果大家喜歡這篇文章，或者對你有幫助希望大家多多，點贊，轉發，關注 哦。文章會持續更新的。絕對乾貨！！！
閱讀更多 Android進階小劉 的文章
