• 去年10月底來到了新公司，剛開始接手 Android 項目時，發(fā)現該項目真的是一團遭，項目開發(fā)上沒有任何架構可言，開發(fā)人員連簡單的 MVC、MVP 都不了解，Activity 及其臃腫，業(yè)務邊界也不明確，因此我決定重新分析一下當前主流的幾種開發(fā)架構，選出適合當前項目的架構形式。

這是“我的Android重構之旅”的開篇之章，在這一篇中，我將依次的和大家介紹一下 MVVM、MVP、MVC、AndroidFlux 這幾種主流的架構設計，本文中不會很深入的分析這些架構的代碼上有何區(qū)別，只是將它們的設計思路帶給大家，讓大家更方便的選擇在項目適用的架構。

MVC

MVC 簡單來說就是將整個應用分為 Model、View 和 Controller 三個部分

• 視圖(View)：管理作為位圖展示到屏幕上的圖形和文字輸出。
• 控制器(Controller)：翻譯用戶的輸入并依照用戶的輸入操作模型和視圖。
• 模型(Model)：管理應用的行為和數據，響應數據請求(經常來自視圖)和更新狀態(tài)的指令(經常來自控制器)。

從上圖可以看出來 View 層需要由 Controller 發(fā)起事件通知 View 然后 View 從 Model 獲取數據，這在 APP 中是較難實現的，我們的事件往往是由 Activity 或 View 發(fā)起并主導的，如果將事件的發(fā)起與控制權交由 Controller 處理的話經常會出現一些意想不到的問題，如內存泄漏等，這就導致了 MVC 的變種 MVP 的出現，Android 本身的設計還是符合 MVC 架構的，但是 Android 中純粹作為 View 的 XML 視圖功能太弱，我們大量處理 View 的邏輯只能寫在 Activity 中，這樣 Activity 就充當了 View 和 Controller 兩個角色，直接導致 Activity 中的代碼大爆炸。相信大多數 Android 開發(fā)者都遇到過一個 Acitivty 數以千行的代碼情況吧!所以，更貼切的說法是，這個 MVC 結構最終其實只是一個 Model-View(Activity:View&Controller)的結構。

MVP

MVP 架構模式是 MVC 的一個變種，很多框架都自稱遵循 MVC 架構模式，但是它們實際上卻實現了 MVP 模式。MVC 與 MVP 之間的區(qū)別其實并不明顯，我認為倆者之間的最大區(qū)別就是 View 層可以發(fā)起事件。

在 MVP 中，Presenter 可以理解為松散的控制器，其中包含了視圖的 UI 業(yè)務邏輯，所有從視圖發(fā)出的事件，都會通過代理給 Presenter 進行處理，同時，Presenter 也通過視圖暴露的接口與其進行通信。

在 MVC 中，控制器負責以不同的視圖響應客戶端請求的不同動作，然而，不同于 MVC 模式，MVP 中視圖將所有的動作交給 Presenter 進行處理，MVC 中的所有的動作都對應著一個控制器的方法調用，Web 應用中的每一個動作都是對某一個 URL 進行的操作，控制器根據訪問的路由和方法(GET 等)對數據進行操作，最終選擇正確的視圖進行返回。

MVC 中控制器返回的視圖沒有直接綁定到模型上，它僅僅被控制器渲染并且是完全無狀態(tài)的，其中不包含任何的邏輯，但是 MVP 中的視圖必須要將對應的事件代理給 Presenter 執(zhí)行，否則事件就無法被響應。

上述內容取自 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 組建開始，后續(xù) Google 不斷的推出了 ViewModels、LiveData、Android Loader、Lifecycles 等適用于 MVVM 架構的組件，由此可見 Google 已經“欽定” MVVM 是 Android 開發(fā)未來的第一架構了。

從 Model-View-ViewModel 這個名字來看，它由三個部分組成，也就是 Model、View 和 ViewModel，其中視圖模型(ViewModel)其實就是 PM 模式中的展示模型，在 MVVM 中叫做視圖模型。

除了我們非常熟悉的 Model、View 和 ViewModel 這三個部分，在 MVVM 的實現中，還引入了隱式的一個 Binder 層，而聲明式的數據和命令的綁定在 MVVM 模式中就是通過它完成的。

MVVM 架構將 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一致，唯一的區(qū)別是，它采用雙向綁定(data-binding)View的變動，自動反映在 ViewModel，反之亦然，這就導致了我們如果要完整的采用 MVVM 必須熟練的掌握 DataBinding 等基礎組建，這就給我們將 MVVM 引入項目帶了困難。

AndroidFlux

AndroidFlux 是 Facebook 的 Flux 架構的 Android 實現。 Flux 是 Facebook 在14年提出的一種 Web 前端架構，主要用來處理復雜的 UI 邏輯的一致性問題(當時是為了解決 Web 頁面的消息通知問題)。經過實踐之后發(fā)現，這種架構可以很好的應用于 Android 平臺，相對于其他的 MVC/MVP/MVVM 等模式，擁有良好的文檔和更具體的設計，比較適合于快速開發(fā)實現。

Flux 模式最大的特點是單向的數據流，它的 UI 狀態(tài)更新模式繼承了 MVC 模式的設計思想。 Flux 并不是具體的框架，而是一套處理 UI 問題的模式， AndroidFlux 同樣不是具體的框架，你不需要導入或者集成任何新的代碼就可以使用，而你需要做的事情是了解這套思想、遵循這種開發(fā)模式。

上述內容取自 AndroidFlux QUICK START。

AndroidFlux 的結構設計很容易讓我們想到函數式響應編程(functional-reactive-programming)，而且 AndroidFlux 一直在強調它自己本身并非某種具體的框架而是一種 UI 或者說數據流的走向，這個很像我們熟知的 RxJava 設計思路，所有事件、UI 都可以當作為一個數據流并加以處理。

只有一個Dispatcher

在 AndroidFlux 應用中 Dispatcher 是中心樞紐，管理所有的數據流。它實際上管理的是 Store 注冊的一系列回調接口，本身沒有其他邏輯 —— 它僅僅是用來把 Action 發(fā)送到各個 Store 的一套簡單的機制。每個 Store 都會把自己注冊到這里，并提供自己的回調方法。當 ActionCreato 給 Dispatcher 傳遞一個 Action 的時候，應用中所有的 Store 都會通過回調接口收到通知。

隨著 App 的增長，Dispatcher 會變得更加重要，它可以通過調整回調方法的觸發(fā)次序來管理 Store 之間的依賴關系。Store 可以聲明等待其他 Store 更新完畢再更新自己。

Stores

Store 包含應用的狀態(tài)(State)和邏輯(Logic)。它扮演的角色和 MVC 模式中的 Model 類似，但是它會管理多個對象的狀態(tài) —— 它不是像 ORM-Model 一樣的單獨的數據集。Store 負責管理App中一片區(qū)域(Domain)的狀態(tài)，而不是簡單的ORM數據集。

由于 AndroidFlux 是一串的語法、結構規(guī)范，他并沒有什么組件來協助我們開發(fā)，所以使用 AndroidFlux 的難度較高，暫時不考慮在中、小型團隊中的應用，僅僅作為一個知識拓展。

總結

在架構模式的選用時，我們往往沒有太多的發(fā)言權，主要因為平臺本身往往對應用層有著自己的設計，我們在開發(fā)客戶端或者前端應用時，只需要遵循平臺固有的設計就可以完成應用的開發(fā)，不過，在有些時候，由于工程變得龐大、業(yè)務邏輯變得異常復雜，我們也可以考慮在原有的架構之上實現一個新的架構以滿足工程上的需要。

最終由于項目上人手不足，我們的項目很遺憾只能選擇 MVP 進行重構，但是其他的架構也給我們提供了不錯的思路如 MVVM 架構中 Google 官方提供的綁定組件，AndroidFlux 將 UI 作為響應式編程的一部分，這些好的地方都值得我們去反復揣摩深入學習，后續(xù)的文章將會陸續(xù)的和大家一起討論一下我們在項目重構中經歷過的一些問題，以及我們是如何設計出一個相對簡單易用的通用開發(fā)架構。