作為Android最常用的架構(gòu)，MVC、MVP與MVVM這三個(gè)架構(gòu)已經(jīng)是很成熟了，即使現(xiàn)在還有模塊化與插件化等方式的架構(gòu)，MVP與MVVM依然是開(kāi)發(fā)者常采納的方案。所以無(wú)論你是想進(jìn)階成為一名高級(jí)工程師，還是跳槽大廠進(jìn)行面試的時(shí)候，那么MVC/MVP/MVVM三個(gè)架構(gòu)的熟練掌握與使用一定是必備條件之一。
那么接下來(lái)接給大家來(lái)分享一下MVC/MVP/MVVM之間的相互聯(lián)系與優(yōu)劣勢(shì)分析，以及還有一些大廠常問(wèn)的關(guān)于MVC/MVP/MVVM面試題。希望在大家架構(gòu)學(xué)習(xí)之路上給予一些幫助。另外的文末的話我也會(huì)給大家分享一套MVC/MVP/MVVM具體學(xué)習(xí)使用手冊(cè)，其中還包含MVC
MVC全名是Model--View--Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫(xiě)，一種軟件設(shè)計(jì)典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，在改進(jìn)和個(gè)性化定制界面及用戶(hù)交互的同時(shí)，不需要重新編寫(xiě)業(yè)務(wù)邏輯。其中Model層處理數(shù)據(jù)，業(yè)務(wù)邏輯等；View層處理界面的顯示結(jié)果；Controller層起到橋梁的作用，來(lái)控制View層和Model層通信以此來(lái)達(dá)到分離視圖顯示和業(yè)務(wù)邏輯層。
我們往往把Android中界面部分的實(shí)現(xiàn)也理解為采用了MVC框架，常常把Activity理解為MVC模式中的Controller。
看似沒(méi)有什么特別的地方，但是由幾個(gè)需要特別View是把控制權(quán)交移給Controller，自己不執(zhí)行業(yè)務(wù)邏輯。Controller執(zhí)行業(yè)務(wù)邏輯并且操作Model，但不會(huì)直接操作View，可以說(shuō)它是對(duì)View無(wú)知的。View和Model的同步消息是通過(guò)觀察者模式進(jìn)行，而同步操作是由View自己請(qǐng)求Model的數(shù)據(jù)然后對(duì)視圖進(jìn)行更新。MVC的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：
1. 把業(yè)務(wù)邏輯全部分離到Controller中，模塊化程度高。 當(dāng)業(yè)務(wù)邏輯變更的時(shí)候，不需要變更View和Model，只需要Controller 換成另外一個(gè)Controller就行了（Swappable Controller）。
2. 觀察者模式可以做到多視圖同時(shí)更新。
缺點(diǎn)：Controller測(cè)試?yán)щy。因?yàn)橐晥D同步操作是由View自己執(zhí)行，而View只能在有UI的環(huán)境下運(yùn)行。在沒(méi)有UI環(huán)境下對(duì)Controller進(jìn)行單元測(cè)試的時(shí)候， Controller業(yè)務(wù)邏輯的正確性是無(wú)法驗(yàn)證的：Controller更新Model的時(shí)候，無(wú)法對(duì)View的更新操作進(jìn)行斷言。View無(wú)法組件化。View是強(qiáng)依賴(lài)特定的Model的，如果需要把這個(gè)View抽出來(lái)作為一個(gè)另外一個(gè)應(yīng)用程序可復(fù)用的組件就困難了。因?yàn)椴煌绦虻牡腄omain Model是不一樣的MVPMVP其實(shí)是MVC的一種演進(jìn)版本，它更簡(jiǎn)單，將MVC中的Controller改為了Presenter，View通過(guò)接口與Presenter進(jìn)行交互，降低耦合，方便進(jìn)行單元測(cè)試。
View：負(fù)責(zé)繪制UI元素、與用戶(hù)進(jìn)行交互(Activity、View、Fragment都可以做為View層)；Model：對(duì)數(shù)據(jù)的操作、對(duì)網(wǎng)絡(luò)等的操作，和業(yè)務(wù)相關(guān)的邏輯處理；Presenter：作為View與Model交互的中間紐帶，處理與用戶(hù)交互的邏輯?？梢园裀resenter理解為一個(gè)中間層的角色，它接受Model層的數(shù)據(jù)，并且處理之后傳遞給View層，還需要處理View層的用戶(hù)交互等操作。關(guān)鍵點(diǎn)：
View不再負(fù)責(zé)同步的邏輯，而是由Presenter負(fù)責(zé)。Presenter中既有業(yè)務(wù)邏輯也有同步邏輯。View需要提供操作界面的接口給Presenter進(jìn)行調(diào)用。（關(guān)鍵）對(duì)比在MVC中，Controller是不能操作View的，View也沒(méi)有提供相應(yīng)的接口；而在MVP當(dāng)中，Presenter可以操作View，View需要提供一組對(duì)界面操作的接口給Presenter進(jìn)行調(diào)用；Model仍然通過(guò)事件廣播自己的變更，但由Presenter監(jiān)聽(tīng)而不是View。
MVP（Passive View）的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：1. 便于測(cè)試。 Presenter對(duì)View是通過(guò)接口進(jìn)行，在對(duì)Presenter進(jìn)行不依賴(lài)UI環(huán)境的單元測(cè)試的時(shí)候?？梢酝ㄟ^(guò)Mock一個(gè)View對(duì)象，這個(gè)對(duì)象只需要實(shí)現(xiàn)了View的接口即可。然后依賴(lài)注入到Presenter中，單元測(cè)試的時(shí)候就可以完整的測(cè)試Presenter業(yè)務(wù)邏輯的正確性。
2. View可以進(jìn)行組件化。 在MVP當(dāng)中，View不依賴(lài)Model。這樣就可以讓View從特定的業(yè)務(wù)場(chǎng)景中脫離出來(lái)，可以說(shuō)View可以做到對(duì)業(yè)務(wù)邏輯完全無(wú)知。它只需要提供一系列接口提供給上層操作。這樣就可以做高度可復(fù)用的View組件。
缺點(diǎn)：Presenter中除了業(yè)務(wù)邏輯以外，還有大量的View->Model，Model->View的手動(dòng)同步邏輯，造成Presenter比較笨重，維護(hù)起來(lái)會(huì)比較困難。MVVMMVVM模式（Model--View--ViewModel模式），和MVP模式相比，MVVM 模式用ViewModel替換了Presenter ，其他層基本上與 MVP 模式一致，ViewModel可以理解成是View的數(shù)據(jù)模型和Presenter的合體。
MVVM采用雙向綁定（data-binding）：View的變動(dòng)，自動(dòng)反映在ViewModel，反之亦然，這種模式實(shí)際上是框架替應(yīng)用開(kāi)發(fā)者做了一些工作（相當(dāng)于ViewModel類(lèi)是由庫(kù)幫我們生成的），開(kāi)發(fā)者只需要較少的代碼就能實(shí)現(xiàn)比較復(fù)雜的交互。
MVVM的調(diào)用關(guān)系和MVP一樣。但是，在ViewModel當(dāng)中會(huì)有一個(gè)叫Binder，或者是Data-binding engine的東西。以前全部由Presenter負(fù)責(zé)的View和Model之間數(shù)據(jù)同步操作交由給Binder處理。你只需要在View的模版語(yǔ)法當(dāng)中，指令式地聲明View上的顯示的內(nèi)容是和Model的哪一塊數(shù)據(jù)綁定的。當(dāng)ViewModel對(duì)進(jìn)行Model更新的時(shí)候，Binder會(huì)自動(dòng)把數(shù)據(jù)更新到View上去，當(dāng)用戶(hù)對(duì)View進(jìn)行操作（例如表單輸入），Binder也會(huì)自動(dòng)把數(shù)據(jù)更新到Model上去。這種方式稱(chēng)為：Two-way data-binding，雙向數(shù)據(jù)綁定?？梢院?jiǎn)單而不恰當(dāng)?shù)乩斫鉃橐粋€(gè)模版引擎，但是會(huì)根據(jù)數(shù)據(jù)變更實(shí)時(shí)渲染。
關(guān)鍵點(diǎn)：
MVVM把View和Model的同步邏輯自動(dòng)化了。以前Presenter負(fù)責(zé)的View和Model同步不再手動(dòng)地進(jìn)行操作，而是交由框架所提供的Binder進(jìn)行負(fù)責(zé)。
只需要告訴Binder，View顯示的數(shù)據(jù)對(duì)應(yīng)的是Model哪一部分即可。
MVVM的優(yōu)缺點(diǎn)優(yōu)點(diǎn)：1. 提高可維護(hù)性。 解決了MVP大量的手動(dòng)View和Model同步的問(wèn)題，提供雙向綁定機(jī)制。提高了代碼的可維護(hù)性。
2. 簡(jiǎn)化測(cè)試。 因?yàn)橥竭壿嬍墙挥葿inder做的，View跟著Model同時(shí)變更，所以只需要保證Model的正確性，View就正確。大大減少了對(duì)View同步更新的測(cè)試。
缺點(diǎn)：過(guò)于簡(jiǎn)單的圖形界面不適用，或說(shuō)牛刀殺雞。對(duì)于大型的圖形應(yīng)用程序，視圖狀態(tài)較多，ViewModel的構(gòu)建和維護(hù)的成本都會(huì)比較高。數(shù)據(jù)綁定的聲明是指令式地寫(xiě)在View的模版當(dāng)中的，這些內(nèi)容是沒(méi)辦法去打斷點(diǎn)debug的。常見(jiàn)面試筆試真題Android中的MVC是什么？有什么特點(diǎn)？參考回答：
M：Model，數(shù)據(jù)模塊，提供數(shù)據(jù)；
V：View，UI模塊，視圖層；
C：Controller，控制模塊，相當(dāng)于Activity。
Controller操作Model層的數(shù)據(jù)，并且將數(shù)據(jù)返回給View層展示。Activity既要處理Controller的邏輯也要處理View的邏輯，導(dǎo)致Activity的代碼過(guò)于臃腫。View層和Model層之間耦合性大，導(dǎo)致不易于維護(hù)和擴(kuò)展。
用過(guò)MVP構(gòu)建過(guò)項(xiàng)目嗎？談?wù)勀銓?duì)它的認(rèn)識(shí)。參考回答：
MVP就是在MVC上增加了一個(gè)接口，因此也降低一層耦合度，這樣View就不會(huì)直接訪問(wèn)Model。
Presenter完全將Model和View解耦，主要邏輯都集中在Presenter中。和View沒(méi)有直接關(guān)聯(lián)，因?yàn)樗芡ㄟ^(guò)View中定義好的接口進(jìn)行交互。這樣當(dāng)View需要修改的時(shí)候，就不用去Presenter里改動(dòng)。View層就只需處理跟UI有關(guān)的邏輯即可。
MVP低耦合、重用方便，而且測(cè)試也方便，但使用了接口去設(shè)計(jì)邏輯復(fù)雜的頁(yè)面時(shí)也會(huì)導(dǎo)致代碼中接口過(guò)多或龐大。
簡(jiǎn)單說(shuō)一下你是如何使用MVP去構(gòu)建一個(gè)項(xiàng)目的。參考回答：
我們可以按照MVP的各個(gè)模塊去設(shè)計(jì)代碼。
1）首先定義Model，創(chuàng)建好Model接口和回調(diào)接口，接著就是創(chuàng)建一個(gè)實(shí)現(xiàn)類(lèi)，重寫(xiě)Model接口里的方法；2）接著就是設(shè)計(jì)View模塊，負(fù)責(zé)UI展示與操作；?3）用Activity去實(shí)現(xiàn)這個(gè)View接口；?4）創(chuàng)建Presenter，互相持有對(duì)象，讓View和Model能交互；?5）最后用Activity創(chuàng)建Presenter對(duì)象并且調(diào)用它的方法來(lái)處理業(yè)務(wù)邏輯
以上便是整個(gè)MVP構(gòu)建項(xiàng)目的思路，并不是一定要該思路，要結(jié)合實(shí)際情況去考慮。
Model-View-ViewModel，對(duì)比MVP，就是將Presenter替換為ViewModel。ViewModel和Model/View進(jìn)行了雙向綁定。當(dāng)View發(fā)生改變時(shí)，ViewModel會(huì)通知Model進(jìn)行更新數(shù)據(jù)。而Model數(shù)據(jù)更新后，ViewModel會(huì)通知View更新顯示。因?yàn)镈ata Binding能將數(shù)據(jù)綁定到xml中， 而且還有ViewModel和LiveData等，使得MVVM用起來(lái)更加方便。
要說(shuō)MVVM就真的完美嗎？也不是，因?yàn)樗沟脭?shù)據(jù)與視圖雙向綁定了，所以當(dāng)出現(xiàn)問(wèn)題的時(shí)候不好找到出錯(cuò)源頭，是數(shù)據(jù)問(wèn)題還是視圖屬性修改導(dǎo)致的，可能需要時(shí)間去尋找。所以使用的時(shí)候要注意。
模塊化是什么？它與組件化又有什么區(qū)別？參考回答：
通常一個(gè)項(xiàng)目會(huì)采用下面的架構(gòu)，如圖所示：
產(chǎn)品層：即應(yīng)用層，如果有三個(gè)項(xiàng)目，則該層有三個(gè)塊；
通用業(yè)務(wù)層：放置公司多個(gè)項(xiàng)目的通用業(yè)務(wù)模塊，這些模塊是跟業(yè)務(wù)有關(guān)，比如文件等資源下載和上傳；
基礎(chǔ)層：基礎(chǔ)庫(kù)，比如網(wǎng)絡(luò)請(qǐng)求，圖片壓縮等邏輯模塊、通用UI模塊和第三方庫(kù)。
而通常新建一個(gè)app項(xiàng)目時(shí)是按照類(lèi)型劃分的（activity、fragment、view、和utils等等），或者按照業(yè)務(wù)劃分，每個(gè)業(yè)務(wù)模塊就是一個(gè)包，每個(gè)包再按照不同類(lèi)型細(xì)分下去。
模塊化是一種軟件設(shè)計(jì)技術(shù)，它能將項(xiàng)目的功能拆分為獨(dú)立、可交換的模塊。每個(gè)模塊都包含執(zhí)行單獨(dú)功能的必要內(nèi)容。而組件化也是設(shè)計(jì)技術(shù)，它強(qiáng)調(diào)將一個(gè)軟件系統(tǒng)拆分為獨(dú)立的組件，而這些組件可以是模塊也可以是web資源等。
兩者目的都是重用和解耦，主要區(qū)別在于模塊化側(cè)重于重用，組件化更側(cè)重于業(yè)務(wù)解耦。
如果要構(gòu)建一個(gè)項(xiàng)目，該選擇MVC還是MVP，亦或是MVVM？參考回答：
如果要構(gòu)建的項(xiàng)目簡(jiǎn)單不是很復(fù)雜的時(shí)候，其實(shí)不需要使用構(gòu)建模式來(lái)構(gòu)建項(xiàng)目的，因?yàn)檫@樣的項(xiàng)目不需要太大改動(dòng)，只需封裝好每個(gè)模塊，然后要使用的時(shí)候直接調(diào)用即可。
如果要構(gòu)建的項(xiàng)目主要是展示UI和數(shù)據(jù)，為了更友好地與用戶(hù)交互，比較適合使用MVVM來(lái)構(gòu)建，因?yàn)樵擃?lèi)項(xiàng)目的大多數(shù)業(yè)務(wù)邏輯都集中在后端，而勢(shì)必要經(jīng)常對(duì)視圖進(jìn)行改動(dòng)，所以使用MVVM能非常好地進(jìn)行視圖屬性修改。
如果要構(gòu)建的項(xiàng)目要處理較多業(yè)務(wù)邏輯或者是屬于工具類(lèi)app的，那就使用MVP比較合適，使用MVVM也是可以的。
當(dāng)然，MVC也不是說(shuō)就用不上，平時(shí)也可以使用MVC來(lái)構(gòu)建一些學(xué)習(xí)項(xiàng)目來(lái)一層一層地進(jìn)行封裝。
總結(jié)以上，可以看到。從MVC->MVP->MVVM，就像一個(gè)打怪升級(jí)的過(guò)程。后者解決了前者遺留的問(wèn)題，把前者的缺點(diǎn)優(yōu)化成了優(yōu)點(diǎn)。同樣的Demo功能，代碼從最開(kāi)始的一堆文件，優(yōu)化成了最后只需要20幾行代碼就完成。當(dāng)然，以上也只是對(duì)MVX三種架構(gòu)模式之間的區(qū)分和優(yōu)缺點(diǎn)做了簡(jiǎn)單闡述，好讓大家對(duì)MVX三種架構(gòu)模式能有一個(gè)清晰的認(rèn)識(shí)，同時(shí)也希望可以給對(duì)這些模式理解比較模糊的同學(xué)帶來(lái)一些參考和思路。
另外如果想要對(duì)MVX三種架構(gòu)模式進(jìn)行進(jìn)階深入學(xué)習(xí)的同學(xué)，我這邊整理了一份《Android架構(gòu)開(kāi)發(fā)手冊(cè)》，也就是我在開(kāi)頭說(shuō)的包含MVX進(jìn)階學(xué)習(xí)+大廠架構(gòu)實(shí)戰(zhàn)演化+Jetapck全套組件學(xué)習(xí)的218頁(yè)的PDF學(xué)習(xí)筆記。整理不易，有需要的同學(xué)，可以點(diǎn)贊本文支持下，然后私信來(lái)找我獲?。?/strong>
Android架構(gòu)開(kāi)發(fā)手冊(cè)目錄
Android架構(gòu)開(kāi)發(fā)手冊(cè)內(nèi)容
