Android 各類架構橫向比對
版權宣告：本文為博主原創文章，轉載請註明作者和連結。更多請繼續關注 KunMinX
ofollow,noindex">https://www.jianshu.com/p/9ef813d5c1af大話專案中用到的常見架構
以下，對常見的 MVC、MVP、Clean、AAC 架構做個比較。
首先，用一張圖表來展示各架構的類冗餘情況：
需求是，寫三個頁面，ListFragment、DetailFragment、PreviewFragment，每個頁面至少用到 3個 Note 業務、3個 User 業務。問：上述架構分別需編寫多少類？
| 架構 | 涉及類 | 類總數 |
|---|---|---|
| MVC | Fragment:3個，Model:2個 | 5個 |
| MVP | Fragment:3個，Presenter:3個，Model:3個 | 9個 |
| Clean | Fragment:3個，ViewModel:3個，Usecase:18個，Model:3個 | 27個 |
| AAC | Fragment:3個，ViewModel:3個，Model:3個 | 9個 |
MVC 架構的 ... 缺陷 :flushed:
- View、Control、Model 相互依賴，造成程式碼耦合。
- 難以分工，難以將 View、Control、Model 分給不同的人寫。
- 難以維護，沒有中介軟體介面做緩衝，難以替換底層的實現。
MVP 架構的特點與缺陷
- MVP 架構的特點是 面向介面程式設計。在 View、Presenter、Model 之間分別用 中介軟體介面 做銜接，當有新的底層實現時，能夠無縫替換。
- 此外，MVP 的 View 和 Model 並不產生依賴，因此可以說是對 View 和 Model 做了程式碼解耦。
但 MVP 架構也是有缺陷的。按我的理解，MVP 設計的初衷是， “讓天下沒有難替換的 View 和 Model” 。該初衷背後所基於的假設是，“上層邏輯穩定，但底層實現更替頻繁” 。在這個假設的引導下，使得三者中， 只有 Presenter 具備獨立意志和決定權，掌管著 UI 邏輯和業務邏輯，而 View 和 Model 只是外接的工具 。
然而，這樣的假設多數時候並不實際。視覺化需求是變化多端的，在牽涉到視覺互動時，必然涉及 UI 邏輯的修改，也就是說，View 和 Presenter 的相互牽連，使得 UI 的改動需要 View 和 Presenter 編寫者配合著完成，增加溝通協作成本。
長久以往，二者都難以成長，Presenter 編寫者容易被各種非本職工作拖累，View 的編寫者不會嘗試獨立自主，例如通過多型等模式將 UI 封裝成可適應性的元件，反正 ... 有 Presenter 來各種 if else 嘛。
Clean 架構的特點與缺陷
mvp_flow.png
為解決 Presenter 職能邊界不明確 的問題，在 Clean 架構中，業務邏輯的職能被轉移到領域層，由 Usecase 專職管理。Presenter 則弱化為 ViewModel ，作為代理資料請求，和銜接資料回撥的緩衝區。
Clean 架構的特點是 單向依賴、資料驅動程式設計 。 View -> ViewModel -> Usecase -> Model 。
View 對 ViewModel 的單向依賴，是通過 databinding 特性實現的。ViewModel 只負責代理資料請求，在 Usecase 處理完業務返回結果資料時，結果資料被賦值給可觀察的 databinding 資料，而 View 則依據資料的變化而變化。
但 Clean 架構也是有缺陷的。 粒度太細 。一個 Usecase 只能處理一類請求。View 請求的資料包含幾種型別，就至少需要準備幾個 Usecase。Usecase 是依據當前 View 對資料的需求量身定製的，因此 Usecase 的複用率極低，專案會因而急劇的增加類和重複程式碼 。
AAC 架構的特點 :neutral_face:
AAC 也是資料驅動程式設計。只不過它不依賴於 MVVM 特性，而是直接在 View 中寫個觀察者回調，以接收結果資料並處理 UI 邏輯。
你完全可以將其理解為 B/S 架構：從 Web 前端向 Web 後端傳送了資料請求，後端在處理完畢後響應結果資料給前端，前端再依據需求處理 UI 邏輯。等於說， AAC 將業務完全壓到了 Model 層 。
ViaBus 架構的由來及特點 :smiley:
東家目前在用 Clean 架構，為此我決定跳過 AAC，基於對移動端資料互動的理解，編寫“訊息驅動程式設計”架構。
由於藉助匯流排來代理資料的請求和響應，因此取名 ViaBus。
viabus_flow.png
不同於以往的架構，ViaBus 明確界定了什麼是 UI，什麼是業務。
UI 的作用是視覺互動，為此 UI 的職責範圍是請求資料和處理 UI 邏輯 。業務的作用是供應資料，因此 業務的職責範圍是接收請求、處理資料、返回結果資料 。
UI 不需要知道資料是怎麼來的、通過誰來的，它只需向 bus 傳送一個請求，如果有業務註冊了該類 “請求處理者”，那麼自然有人來處理。業務也無需知道 UI 在拿到資料後會怎麼用，它只需向 bus 回傳結果，如果有 UI 註冊了“觀察響應者”，那麼自然有人接收，並依據響應碼行事。
這樣，在靜態 bus 的加持下，UI 和業務是完全解耦的，從根本上解決了相互牽連的問題。此外，不同於上述架構的每個 View 都要對應一個 Presenter 或 ViewModel，在 ViaBus 中，一個模組中的 UI 可以共享多個“業務處理者”例項，使 程式碼的複用率提升到100% 。
ViaBus 現已在 Github 開源，歡迎 Star & Fork ~