前言

談起MVC，MVP和MVVM這三個最耳熟能詳的Android框架，相信大家對它們都不陌生，但在實際的情況下，我們很難去界定和定義MVC、MVP和MVVM，從本質上來講他們的目的都是分層解耦，結構上也都是分為三部分，而且三者都有著一些相似的特性，對于一些新手來說，可能理解和區分它們三個都有困難，更別說在實際的項目中應用了，現在我們來分別理解它們，并看看它們之間有什么相同點和不同點！

1. MVC 框架模式

MVC的全名是Model View Controller，即－模型(model)－視圖(view)－控制器(controller)，它是一種軟件的設計典范，它通過“業務邏輯、數據、界面顯示”的分離手段來組織代碼。

早期的MVC 框架模式

MVC框架模式最早由Trygve Reenskaug 于1978年在Smalltalk-80系統上首次提出，我們來看下當時Reenskaug為解析MVC模式所繪制的一個例圖：

Reenskaug 繪制的MVC關系圖

于此同時，Reenskaug也給出了自己對MVC的介紹：

Model： Model可以是一個獨立的對象，也可以是一系列對象的集合體；

View： View是Model中一些重要數據在視覺上的體現；

Controller： Controller用于連接User和System，比如當Controller接受到用戶的輸出時，會將其轉換成合適的事件消息，并將該事件消息傳遞給一個或多個View；

比較經典的 MVC 框架模式

MVC后來的發展比較多元化，也演化出很多的小分支，不過不管其怎么改變，Model、View、Controller的結構都沒有改變.

MVC作為最出名并且應用最廣泛的架構模式，其并沒有一個明確的定義，網上流傳的 MVC 架構圖也是形態各異，個人認為比較經典的MVC結構如下圖：

MVC經典結構.png

下圖展示了MVC程序框架在Android應用程序中的使用，以及各個層次使用哪些組件擔當：

MVC層次圖

使用MVC的目的就是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式，而Controller存在的目的則是確保M改變，V應該同步更新。

Android應用程序中，MVC框架是如何實現的？都充當什么角色？

1. View接受用戶的交互請求；
2. View將請求轉交給Controller；
3. Controller（用戶做的動作比如：update數據，刪除指定名字的學生等等）操作Model進行數據更新（根據用戶指示，執行底層的數據動作等等）；
4. 數據更新之后，Model通知View數據變化；
5. View顯示更新之后的數據；

MVC流程圖

M層適合做一些業務邏輯處理，比如數據庫存取操作、網絡操作、復雜的算法等耗時操作；

V層顯示數據部分，XML布局可以視為是V層，顯示Model層的數據結果；

C層適合使用Activity擔當，Android中Activity用于處理用戶交互問題（發起業務請求），讀取用戶輸入（等待業務處理結果），響應用戶點擊等等事件。

MVC 的優缺點及適用場景

優點：

1. 耦合性低，MVC本質是分層解耦，將表現層與表現邏輯很好的分離，減少模塊代碼之間的相互影響.
2. 可擴展性好。由于耦合性低，添加需求，擴展代碼就可以減少修改之前的代碼，降低bug的出現率.
3. 模塊職責劃分明確。主要劃分層M,V,C三個模塊，利于代碼的維護.

缺點：

1. View層和Model層是相互可知的，這意味著兩層之間存在耦合；
2. 在Android開發中，xml作為View層，控制能力實在太弱了，只能把代碼寫在Activity中，造成了Activity既是Controller層，又是view層這樣一個窘境，而且Activity并不是一個標準的MVC模式中的Controller，它的首要職責是加載應用的布局和初始化用戶界面，并接受和處理來自用戶的操作請求，進而作出響應。隨著應用內界面及其邏輯的復雜度不斷提升，Activity類的職責不斷增加，以致變得龐大而臃腫。

適用場景：適用于功能較少、業務邏輯簡單、界面不復雜的小型項目。

上面我們花了不少的時間來談論MVC，我個人覺得是很有必要的，能很好的理解MVC，才能更快的理解MVP和MVVM，他們都是MVC的演化版本。

2. MVP 框架模式

MVP全稱Model View Presenter，它是MVC的一個演化版本，常用MVP結構如下圖：

常用MVP模式.png

數據的存取（Model）：
Model角色主要是提供數據的存取功能，Presenter需要通過Model層存取、獲取數據，Model就像一個數據倉庫，更直白說Model是封裝了數據DAO、網絡獲取數據的角色，或者是兩種數據獲取方式的集合。


用戶界面（View）：
View通常指Activity、Fragment或者某個View控件，它含有一個Presenter成員變量。通常View需要實現一個邏輯接口，將View上的操作轉交給Presenter進行實現，最后，Presenter將調用View邏輯接口將結果返回給View元素。


交互中間人（Presenter）：
Presenter主要作為View和Model的橋梁，它從Model層檢索數據后，返回給View，使得View和Model之間沒有耦合，也將業務邏輯從View層上抽離出來。

MVP并沒有一個標準的模式，它有很多的實現方式，但無論如何，我們只要保證：通過Presenter將View和Model解耦合、降低類型復雜度、各個模塊可以獨立測試、獨立變化，這就是正確的方向；

我個人覺得MVP模式最重要的實現方式是：分離顯示層和邏輯層，使它們通過接口進行通信,降低耦合；理想的MVP模式可以實現一份邏輯代碼搭配不同的顯示界面，因為它們之間不依賴具體實現，而是依賴于抽象。

Android應用程序中，MVP框架是如何實現的？都充當什么角色？

1. View接受用戶的交互請求；
2. View通過Presenter暴露接口將請求轉交給Presenter來進行處理；
3. Presenter 通過Model暴露接口對Model進行操作和更新；
4. Model改變后，可以將改變的信息發送至Presenter；
5. Presenter通過View暴露接口對View進行視圖更新；

M層提供數據上的存取，比如數據庫存取操作、網絡操作、復雜的算法等操作；

V層負責顯示數據部分，顯示Model層的數據結果，Activity、Fragment或者某個View控件可以視為是V層，；

P層更多的是作為V層和M層的橋梁，主要負責相關的業務邏輯。

MVP還有很多演化版本和分支版本，它不存在標準和固定的模式，只要是符合上面提到的實現方式，它就是合理的。

MVP的優缺點及適用場景

為什么說MVP是MVC的演化版本，因為MVP很好的解決了MVC的一些弊端。

優點：

1. 通過P層的轉接能避免業務邏輯被塞進View中，有效的降低View的復雜性；
2. View層和Model層完全解耦，他們之間互不干擾，帶來了良好的可拓展性、可測試性，保證了系統的靈活性和整潔性；
3. Activity、Fragment等僅僅為View層，不會再出現MVC那種Activity、Fragment即做View層又做Controller層的窘境，View層及Model層大大提高復用性；
4. 我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個也是我上面提到的理想的MVP模式；
5. 由于各層分工明確，極便于單元測試；

缺點：

1. MVP是以UI為驅動的模型，更新UI時需要保證能獲取到控件的引用，同時更新UI時也要考慮當前是否是UI線程；
2. 復雜的業務同時也可能會導致P層太大，代碼臃腫的問題依然不能解決；
3. MVP通過接口進行交互的，接口粒度不好設計和控制。粒度太小，就會存在大量接口；粒度太大，解耦效果不好；
4. MVP數據都是被動地通過UI控件做展示，但是由于數據的時變性，我們更希望數據能轉被動為主動，使數據能更有活性，由數據來驅動UI；

適用場景：適用于界面復雜、復用性高、功能中等、業務邏輯中等或是簡單的項目。實際上MVP的思想很適合用于復雜的界面上，我們完全可以在項目中某一部分上使用MVP的思想去靈活實現（當然你總監或是領導看到你這樣實現打你請不要出賣我，那是你沒溝通好）

例子：Android源碼NavigationView、官方MVP例子：todo?mvp

Android中MVP實現需要注意的點

綜上所述，MVP有很多的優點，但在Android中Activity、Fragment作為View層時，它不僅僅只是View那么簡單，它還存在自身的生命周期；以下是我總結的幾個需要注意的點，非常歡迎補充：

1. 更新UI時要考慮當前執行的線程是否是UI線程，也要考慮Activity的生命周期，做好Activity已被摧毀的處理；
2. P層需要執行耗時操作，而P層持有Activity、Fragment的強引用，在耗時操作結束前Activity、Fragment已被摧毀了，但由于P層一直持有Activity、Fragment對象，導致Activity、Fragment無法被回收引起內存泄露；這里建議使用弱引用和Activity、Fragment的聲明周期來處理；

3. MVVM 框架模式

說到Android MVVM，相信大家都會想到Google 2015年推出的DataBinding框架。然而兩者的概念是不一樣的，不能混為一談。MVVM是一種架構模式，而DataBinding是一個實現數據和UI綁定的框架，是構建MVVM模式的一個工具。


MVVM全稱Model View ViewModel，你可以把MVP看做是MVVM的一個改進版本，常用的MVVM結構如下圖：

MVVM結構圖

Model：
Model主要是封裝數據存儲或操作的一些邏輯，還會提供一系列的實體類用于UI綁定，ViewModel 則會在修改這些數據后將數據改變告訴View層并使UI更新。


View：
View用于處理界面的邏輯且不參與業務邏輯相關的操作，只負責顯示由ViewModel提供的數據，View層不做任何業務邏輯、不涉及操作數據、不處理數據，UI和數據嚴格的分開,對應于Activity和XML。


ViewModel：
ViewModel層做的事情剛好和View層相反，ViewModel只做和業務邏輯和業務數據相關的事，不做任何和UI相關的事情，ViewModel層不會持有任何控件的引用，更不會在ViewModel中通過UI控件的引用去做更新UI的事情。ViewModel就是專注于業務的邏輯處理，做的事情也都只是對數據的操作（這些數據綁定在相應的控件上會自動去更改UI）。同時DataBinding框架已經支持雙向綁定，讓我們可以通過雙向綁定獲取View層反饋給ViewModel層的數據，并對這些數據進行操作。

MVVM的目標和思想與MVP類似，利用數據綁定(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一個更加靈活高效的架構，
在常規的開發模式中，數據變化需要更新UI的時候，需要先獲取UI控件的引用，然后再更新UI，獲取用戶的輸入和操作也需要通過UI控件的引用，但在MVVM中，這些都是通過數據驅動來自動完成的，數據變化后會自動更新UI，UI的改變也能自動反饋到數據層，數據成為主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不需要直接和UI打交道，在業務處理過程中簡單方便很多。

MVVM模式中，數據是獨立于UI的，數據和業務邏輯處于一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和UI或者控件打交道。UI想怎么顯示數據都由UI自己決定，ViewModel不涉及任何和UI相關的事，也不持有UI控件的引用。即便是控件改變了（比如：TextView換成EditText），ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點。

MVVM的優缺點及適用場景

優點：

1. 低耦合，數據和業務邏輯處于一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和View層打交道。
2. 可重用性，你可以把一些視圖邏輯放在一個ViewModel里面，讓很多view重用這段視圖邏輯。
3. 可分開獨立開發，MVVM的分工是非常明顯的，由于View和ViewModel之間是松散耦合的：一個是處理業務和數據、一個是專門的UI處理。所以，完全可以由兩個人分工來做，一個做UI（XML和Activity）一個寫ViewModel，效率更高。
4. 由于各層分工明確，極便于單元測試；
5. 相對于MVP而言，MVVM不需要我們手動的處理大量的View和Model相關操作，也非常完美的解耦了View層和ViewModel；

缺點：

1. 數據綁定使得 Bug 很難被調試，你看到界面異常了，有可能是你 View 的代碼有 Bug，也可能是 Model 的代碼有問題。數據綁定使得一個位置的 Bug 被快速傳遞到別的位置，要定位原始出問題的地方就變得不那么容易了。
2. 對于過大的項目，數據綁定需要花費更多的內存，而對與過于簡單的界面，使用MVVM無異是殺雞用牛刀，某種意義上來說，我認為就是數據綁定使得 MVVM 變得復雜和難用了。

適用場景：我自身沒有在實際項目中應用過MVVM，這里不好定義使用場景，希望在實際項目中使用過的朋友可以告知，但MVVM是不適用于簡單的界面和極度復雜的界面，在界面簡單的情況下，MVVM反而將我們的邏輯復雜化了，而界面元素過多，相對應的ViewModel的構建和維護成本就會變的很高，不利于項目的發展。

4. MVC MVP MVVM的異同

在實際的情況下，我們很難去界定MVC、MVP和MVVM，他們三者有著一些相似的特性，從本質上來講他們的目的都是分層解耦，結構上也都是分為3部分，其中都有View層和Model層，但是其職責又有一定的不同：

注：這里的Binder不是Android的Binder機制，這里是指負責View和Model之間的數據邏輯操作的處理；

從上面的架構結構圖，我們可以看到，MVC、MVP和MVVM三者中Model和View在演化的過程中遵循這么一個理念：耦合 -> 解耦 -> 實用，在MVC中View和Model還存在一定的耦合，而在MVP中則徹底拋開這個耦合并依賴于接口進一步解耦，到了MVVM，MVP該做的都做的差不多了，唯一不好的就是很多時候View和Model之間有大量重復的數據交互操作，MVVM則提出將這些操作進一步提取由框架來承擔。

除了Model和View外，MVC、MVP和MVVM都將業務邏輯的處理單獨放置在Controller、Presenter和ViewModel中，雖然名稱不同但它們的本質都是一樣的，只是在具體的業務處理以及職責劃分上會有一定的差異：

從MVC到MVP再到MVVM，我們可以看到整個框架模式的演進，因為MVC的不足到MVP的出現，對MVP的缺陷彌補到MVVM的誕生，三者是一個循序漸進的過程，在以后必定會有更多更好的框架模式的出現。

5. 總結

對于MVC MVP MVVM框架模式的學習，一定要實踐，一定要實踐，一定要實踐，重要的事情說三遍，無論你看了多少文章，構思了多少遍，如果沒有實踐，都很難體會到這些框架里的思想及具體的實現方式；我個人覺得比較好的學習方式是：先了解和理解各個框架模式的發展歷程和特點，然后有意識的寫幾個例子（如登錄功能、注冊功能），好好的對比自己平時的代碼與用了相關框架模式的代碼之間的區別，加深對不同框架模式的理解，最后也是最好能結合相關的實際項目去實踐，當你使用該框架模式時請記得問問自己為什么使用這個模式？而不是其他模式？它能解決什么問題？是否是最優解？

通過設計使程序模塊化，做到模塊內部的高聚合和模塊之間的低耦合，提高程序開發的效率，并且更容易進行后續的測試以及定位問題，對于不同量級及類型的應用，具體架構的實現方式必然是不同的，我個人覺得最重要的還是能靈活的運用各個框架模式的思想，而不是一定要使用特定的某個框架模式，或者我們可以變通下混合使用，但在實際開發中，特別是團隊開發中，還要要遵守大家約定好的規則執行。

查考文獻：

• Android 源碼設計模式解析與實戰第2版
• jamesK4W：Android應用程序MVC框架實例分析
• 魅力程序員：Android面試題7–Android項目常用框架MVC、MVP、MVVM
• 凱林：如何構建Android MVVM 應用框架