EF A舞蹈服
去年10月底來到了新公司，剛開始接手 Android 專案時，發現該專案真的是一團遭，專案開發上沒有任何架構可言，開發人員連簡單的 MVC、MVP 都不瞭解，Activity 及其臃腫，業務邊界也不明確，因此我決定重新分析一下當前主流的幾種開發架構，選出適合當前專案的架構形式。
這是“我的Android重構之旅”的開篇之章，在這一篇中，我將依次的和大家介紹一下 MVVM、MVP、MVC、AndroidFlux 這幾種主流的架構設計，本文中不會很深入的分析這些架構的程式碼上有何區別，只是將它們的設計思路帶給大家，讓大家更方便的選擇在專案適用的架構。
MVC
MVC 簡單來說就是將整個應用分為 Model、View 和 Controller 三個部分
- 檢視（View）：管理作為點陣圖展示到螢幕上的圖形和文字輸出。
- 控制器（Controller）：翻譯使用者的輸入並依照使用者的輸入操作模型和檢視。
- 模型（Model）：管理應用的行為和資料，響應資料請求（經常來自檢視）和更新狀態的指令（經常來自控制器）。
從上圖可以看出來 View 層需要由 Controller 發起事件通知 View 然後 View 從 Model 獲取資料，這在 APP 中是較難實現的，我們的事件往往是由 Activity 或 View 發起並主導的，如果將事件的發起與控制權交由 Controller 處理的話經常會出現一些意想不到的問題，如記憶體洩漏等，這就導致了 MVC 的變種 MVP 的出現，Android 本身的設計還是符合 MVC 架構的，但是 Android 中純粹作為 View 的 XML 檢視功能太弱，我們大量處理 View 的邏輯只能寫在 Activity 中，這樣 Activity 就充當了 View 和 Controller 兩個角色，直接導致 Activity 中的程式碼大爆炸。相信大多數 Android 開發者都遇到過一個 Acitivty 數以千行的程式碼情況吧！所以，更貼切的說法是，這個 MVC 結構最終其實只是一個 Model-View（Activity:View&Controller）的結構。
MVP
MVP 架構模式是 MVC 的一個變種，很多框架都自稱遵循 MVC 架構模式，但是它們實際上卻實現了 MVP 模式。MVC 與 MVP 之間的區別其實並不明顯，我認為倆者之間的最大區別就是 View 層可以發起事件。
在 MVP 中，Presenter 可以理解為鬆散的控制器，其中包含了檢視的 UI 業務邏輯，所有從檢視發出的事件，都會通過代理給 Presenter 進行處理，同時，Presenter 也通過檢視暴露的介面與其進行通訊。
在 MVC 中，控制器負責以不同的檢視響應客戶端請求的不同動作，然而，不同於 MVC 模式，MVP 中檢視將所有的動作交給 Presenter 進行處理，MVC 中的所有的動作都對應著一個控制器的方法呼叫，Web 應用中的每一個動作都是對某一個 URL 進行的操作，控制器根據訪問的路由和方法（GET 等）對資料進行操作，最終選擇正確的檢視進行返回。
MVC 中控制器返回的檢視沒有直接繫結到模型上，它僅僅被控制器渲染並且是完全無狀態的，其中不包含任何的邏輯，但是 MVP 中的檢視必須要將對應的事件代理給 Presenter 執行，否則事件就無法被響應。
上述內容取自 What are MVP and MVC and what is the difference? · Stack Overflow 中的 Model-View-Controller 部分。
從這裡可以看出，Presenter 層的出現幫助我們減輕了 Activity 的壓力，結構上也較為清晰，但是 View 層將存在較多與 Presenter 溝通的程式碼這是我們較為不希望看到的結果，MVVM 架構在這種情況下被提了出來。
MVVM
MVVM 架構模式是微軟在 2005 年誕生的，第一次進入 Android 人員視野是從 Google 2015 推出 DataBinding 組建開始，後續 Google 不斷的推出了 ViewModels、LiveData、Android Loader、Lifecycles 等適用於 MVVM 架構的元件，由此可見 Google 已經“欽定” MVVM 是 Android 開發未來的第一架構了。
從 Model-View-ViewModel 這個名字來看，它由三個部分組成，也就是 Model、View 和 ViewModel，其中檢視模型（ViewModel）其實就是 PM 模式中的展示模型，在 MVVM 中叫做檢視模型。 除了我們非常熟悉的 Model、View 和 ViewModel 這三個部分，在 MVVM 的實現中，還引入了隱式的一個 Binder 層，而宣告式的資料和命令的繫結在 MVVM 模式中就是通過它完成的。
MVVM 架構將 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一致，唯一的區別是，它採用雙向繫結（data-binding）View的變動，自動反映在 ViewModel，反之亦然，這就導致了我們如果要完整的採用 MVVM 必須熟練的掌握 DataBinding 等基礎組建，這就給我們將 MVVM 引入專案帶了困難。
AndroidFlux
AndroidFlux 是 Facebook 的 Flux 架構的 Android 實現。 Flux 是 Facebook 在14年提出的一種 Web 前端架構，主要用來處理複雜的 UI 邏輯的一致性問題（當時是為了解決 Web 頁面的訊息通知問題）。經過實踐之後發現，這種架構可以很好的應用於 Android 平臺，相對於其他的 MVC/MVP/MVVM 等模式，擁有良好的文件和更具體的設計，比較適合於快速開發實現。 Flux 模式最大的特點是單向的資料流，它的 UI 狀態更新模式繼承了 MVC 模式的設計思想。 Flux 並不是具體的框架，而是一套處理 UI 問題的模式， AndroidFlux 同樣不是具體的框架，你不需要匯入或者整合任何新的程式碼就可以使用，而你需要做的事情是瞭解這套思想、遵循這種開發模式。
上述內容取自 AndroidFlux QUICK START。
AndroidFlux 的結構設計很容易讓我們想到函式式響應程式設計（functional-reactive-programming），而且 AndroidFlux 一直在強調它自己本身並非某種具體的框架而是一種 UI 或者說資料流的走向，這個很像我們熟知的 RxJava 設計思路，所有事件、UI 都可以當作為一個資料流並加以處理。
只有一個Dispatcher
在 AndroidFlux 應用中 Dispatcher 是中心樞紐，管理所有的資料流。它實際上管理的是 Store 註冊的一系列回撥介面，本身沒有其他邏輯 —— 它僅僅是用來把 Action 傳送到各個 Store 的一套簡單的機制。每個 Store 都會把自己註冊到這裡，並提供自己的回撥方法。當 ActionCreato 給 Dispatcher 傳遞一個 Action 的時候，應用中所有的 Store 都會通過回撥介面收到通知。
隨著 App 的增長，Dispatcher 會變得更加重要，它可以通過調整回撥方法的觸發次序來管理 Store 之間的依賴關係。Store 可以宣告等待其他 Store 更新完畢再更新自己。
Stores
Store 包含應用的狀態（State）和邏輯（Logic）。它扮演的角色和 MVC 模式中的 Model 類似，但是它會管理多個物件的狀態 —— 它不是像 ORM-Model 一樣的單獨的資料集。Store 負責管理App中一片**區域（Domain）**的狀態，而不是簡單的ORM資料集。
由於 AndroidFlux 是一串的語法、結構規範，他並沒有什麼元件來協助我們開發，所以使用 AndroidFlux 的難度較高，暫時不考慮在中、小型團隊中的應用，僅僅作為一個知識擴充。
總結
在架構模式的選用時，我們往往沒有太多的發言權，主要因為平臺本身往往對應用層有著自己的設計，我們在開發客戶端或者前端應用時，只需要遵循平臺固有的設計就可以完成應用的開發，不過，在有些時候，由於工程變得龐大、業務邏輯變得異常複雜，我們也可以考慮在原有的架構之上實現一個新的架構以滿足工程上的需要。
最終由於專案上人手不足，我們的專案很遺憾只能選擇 MVP 進行重構，但是其他的架構也給我們提供了不錯的思路如 MVVM 架構中 Google 官方提供的繫結元件，AndroidFlux 將 UI 作為響應式程式設計的一部分，這些好的地方都值得我們去反覆揣摩深入學習，後續的文章將會陸續的和大家一起討論一下我們在專案重構中經歷過的一些問題，以及我們是如何設計出一個相對簡單易用的通用開發架構。
作者：殺魚能手小耗子 連結：https://www.jianshu.com/p/71ce61be9d90
閱讀更多
如果有什麼 問題，歡迎隨時撩我