個人Android重構之旅：架構篇

去年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/71c...

閱讀更多

react-native技術的優劣*

學習React Native必看的幾個開源項目

開發了幾個小程序後，說說我對小程序的見解

NDK項目實戰—高仿360手機助手之卸載監聽

（Android）面試題級答案（精選版）

若是有什麼 問題，歡迎隨時撩我