摘要：是的架構(gòu)的實(shí)現(xiàn)。是在年提出的一種前端架構(gòu)，主要用來(lái)處理復(fù)雜的邏輯的一致性問(wèn)題當(dāng)時(shí)是為了解決頁(yè)面的消息通知問(wèn)題。

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

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

MVC 簡(jiǎn)單來(lái)說(shuō)就是將整個(gè)應(yīng)用分為 Model、View 和 Controller 三個(gè)部分

視圖（View）：管理作為位圖展示到屏幕上的圖形和文字輸出。

控制器（Controller）：翻譯用戶(hù)的輸入并依照用戶(hù)的輸入操作模型和視圖。

模型（Model）：管理應(yīng)用的行為和數(shù)據(jù)，響應(yīng)數(shù)據(jù)請(qǐng)求（經(jīng)常來(lái)自視圖）和更新?tīng)顟B(tài)的指令（經(jīng)常來(lái)自控制器）。

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

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

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

在 MVC 中，控制器負(fù)責(zé)以不同的視圖響應(yīng)客戶(hù)端請(qǐng)求的不同動(dòng)作，然而，不同于 MVC 模式，MVP 中視圖將所有的動(dòng)作交給 Presenter 進(jìn)行處理，MVC 中的所有的動(dòng)作都對(duì)應(yīng)著一個(gè)控制器的方法調(diào)用，Web 應(yīng)用中的每一個(gè)動(dòng)作都是對(duì)某一個(gè) URL 進(jìn)行的操作，控制器根據(jù)訪(fǎng)問(wèn)的路由和方法（GET 等）對(duì)數(shù)據(jù)進(jìn)行操作，最終選擇正確的視圖進(jìn)行返回。

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

上述內(nèi)容取自 What are MVP and MVC and what is the difference? · Stack Overflow 中的 Model-View-Controller 部分。

從這里可以看出，Presenter 層的出現(xiàn)幫助我們減輕了 Activity 的壓力，結(jié)構(gòu)上也較為清晰，但是 View 層將存在較多與 Presenter 溝通的代碼這是我們較為不希望看到的結(jié)果，MVVM 架構(gòu)在這種情況下被提了出來(lái)。

MVVM 架構(gòu)模式是微軟在 2005 年誕生的，第一次進(jìn)入 Android 人員視野是從 Google 2015 推出 DataBinding 組建開(kāi)始，后續(xù) Google 不斷的推出了 ViewModels、LiveData、Android Loader、Lifecycles 等適用于 MVVM 架構(gòu)的組件，由此可見(jiàn) Google 已經(jīng)“欽定” MVVM 是 Android 開(kāi)發(fā)未來(lái)的第一架構(gòu)了。

從 Model-View-ViewModel 這個(gè)名字來(lái)看，它由三個(gè)部分組成，也就是 Model、View 和 ViewModel，其中視圖模型（ViewModel）其實(shí)就是 PM 模式中的展示模型，在 MVVM 中叫做視圖模型。
除了我們非常熟悉的 Model、View 和 ViewModel 這三個(gè)部分，在 MVVM 的實(shí)現(xiàn)中，還引入了隱式的一個(gè) Binder 層，而聲明式的數(shù)據(jù)和命令的綁定在 MVVM 模式中就是通過(guò)它完成的。

MVVM 架構(gòu)將 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一致，唯一的區(qū)別是，它采用雙向綁定（data-binding）View的變動(dòng)，自動(dòng)反映在 ViewModel，反之亦然，這就導(dǎo)致了我們?nèi)绻暾牟捎?MVVM 必須熟練的掌握 DataBinding 等基礎(chǔ)組建，這就給我們將 MVVM 引入項(xiàng)目帶了困難。

AndroidFlux 是 Facebook 的 Flux 架構(gòu)的 Android 實(shí)現(xiàn)。 Flux 是 Facebook 在14年提出的一種 Web 前端架構(gòu)，主要用來(lái)處理復(fù)雜的 UI 邏輯的一致性問(wèn)題（當(dāng)時(shí)是為了解決 Web 頁(yè)面的消息通知問(wèn)題）。經(jīng)過(guò)實(shí)踐之后發(fā)現(xiàn)，這種架構(gòu)可以很好的應(yīng)用于 Android 平臺(tái)，相對(duì)于其他的 MVC/MVP/MVVM 等模式，擁有良好的文檔和更具體的設(shè)計(jì)，比較適合于快速開(kāi)發(fā)實(shí)現(xiàn)。
Flux 模式最大的特點(diǎn)是單向的數(shù)據(jù)流，它的 UI 狀態(tài)更新模式繼承了 MVC 模式的設(shè)計(jì)思想。 Flux 并不是具體的框架，而是一套處理 UI 問(wèn)題的模式， AndroidFlux 同樣不是具體的框架，你不需要導(dǎo)入或者集成任何新的代碼就可以使用，而你需要做的事情是了解這套思想、遵循這種開(kāi)發(fā)模式。

上述內(nèi)容取自 AndroidFlux QUICK START。

AndroidFlux 的結(jié)構(gòu)設(shè)計(jì)很容易讓我們想到函數(shù)式響應(yīng)編程（functional-reactive-programming），而且 AndroidFlux 一直在強(qiáng)調(diào)它自己本身并非某種具體的框架而是一種 UI 或者說(shuō)數(shù)據(jù)流的走向，這個(gè)很像我們熟知的 RxJava 設(shè)計(jì)思路，所有事件、UI 都可以當(dāng)作為一個(gè)數(shù)據(jù)流并加以處理。

只有一個(gè)Dispatcher

在 AndroidFlux 應(yīng)用中 Dispatcher 是中心樞紐，管理所有的數(shù)據(jù)流。它實(shí)際上管理的是 Store 注冊(cè)的一系列回調(diào)接口，本身沒(méi)有其他邏輯 —— 它僅僅是用來(lái)把 Action 發(fā)送到各個(gè) Store 的一套簡(jiǎn)單的機(jī)制。每個(gè) Store 都會(huì)把自己注冊(cè)到這里，并提供自己的回調(diào)方法。當(dāng) ActionCreato 給 Dispatcher 傳遞一個(gè) Action 的時(shí)候，應(yīng)用中所有的 Store 都會(huì)通過(guò)回調(diào)接口收到通知。

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

Stores

Store 包含應(yīng)用的狀態(tài)（State）和邏輯（Logic）。它扮演的角色和 MVC 模式中的 Model 類(lèi)似，但是它會(huì)管理多個(gè)對(duì)象的狀態(tài) —— 它不是像 ORM-Model 一樣的多帶帶的數(shù)據(jù)集。Store 負(fù)責(zé)管理App中一片區(qū)域（Domain）的狀態(tài)，而不是簡(jiǎn)單的ORM數(shù)據(jù)集。

由于 AndroidFlux 是一串的語(yǔ)法、結(jié)構(gòu)規(guī)范，他并沒(méi)有什么組件來(lái)協(xié)助我們開(kāi)發(fā)，所以使用 AndroidFlux 的難度較高，暫時(shí)不考慮在中、小型團(tuán)隊(duì)中的應(yīng)用，僅僅作為一個(gè)知識(shí)拓展。

在架構(gòu)模式的選用時(shí)，我們往往沒(méi)有太多的發(fā)言權(quán)，主要因?yàn)槠脚_(tái)本身往往對(duì)應(yīng)用層有著自己的設(shè)計(jì)，我們?cè)陂_(kāi)發(fā)客戶(hù)端或者前端應(yīng)用時(shí)，只需要遵循平臺(tái)固有的設(shè)計(jì)就可以完成應(yīng)用的開(kāi)發(fā)，不過(guò)，在有些時(shí)候，由于工程變得龐大、業(yè)務(wù)邏輯變得異常復(fù)雜，我們也可以考慮在原有的架構(gòu)之上實(shí)現(xiàn)一個(gè)新的架構(gòu)以滿(mǎn)足工程上的需要。

最終由于項(xiàng)目上人手不足，我們的項(xiàng)目很遺憾只能選擇 MVP 進(jìn)行重構(gòu)，但是其他的架構(gòu)也給我們提供了不錯(cuò)的思路如 MVVM 架構(gòu)中 Google 官方提供的綁定組件，AndroidFlux 將 UI 作為響應(yīng)式編程的一部分，這些好的地方都值得我們?nèi)シ磸?fù)揣摩深入學(xué)習(xí)，后續(xù)的文章將會(huì)陸續(xù)的和大家一起討論一下我們?cè)陧?xiàng)目重構(gòu)中經(jīng)歷過(guò)的一些問(wèn)題，以及我們是如何設(shè)計(jì)出一個(gè)相對(duì)簡(jiǎn)單易用的通用開(kāi)發(fā)架構(gòu)。

作者：殺魚(yú)能手小耗子
鏈接：https://www.jianshu.com/p/71c...

閱讀更多

react-native技術(shù)的優(yōu)劣*

學(xué)習(xí)React Native必看的幾個(gè)開(kāi)源項(xiàng)目

開(kāi)發(fā)了幾個(gè)小程序后，說(shuō)說(shuō)我對(duì)小程序的看法

NDK項(xiàng)目實(shí)戰(zhàn)—高仿360手機(jī)助手之卸載監(jiān)聽(tīng)

（Android）面試題級(jí)答案（精選版）

如果有什么 問(wèn)題，歡迎隨時(shí)撩我