為什么我們要使用架構(gòu)模式呢讥裤？
首先我們說(shuō)一下我們知道的Android有哪些呢借尿？
MVC MVP MVVM 三種架構(gòu)模式
我們使用架構(gòu)模式基本上都是為了降低耦合性 使Android工程師在開(kāi)發(fā)的時(shí)候只需要關(guān)注一點(diǎn)就可以,提高了工作的效率。
如果說(shuō)你認(rèn)為使用架構(gòu)模式就會(huì)讓你的代碼量變少的話,那你就大錯(cuò)特錯(cuò)了,使用架構(gòu)模式并不是說(shuō)讓你的代碼量變少,有時(shí)候還會(huì)比之前得代碼要多匀油。架構(gòu)模式是為了幫助我們?cè)谶壿嬌线叺母?jiǎn)單,很好的定義單一原則,下次修改的時(shí)候就可以直接找到某一個(gè)模塊進(jìn)行修改就可以锐极，大大的提高了我們工作的效率盒齿。方便定位問(wèn)題以及后續(xù)需求變更時(shí)不至于需要去改一大堆東西沿猜。
MVC
MVC （Model-View-Controller）我們最常見(jiàn)的架構(gòu) 也是很容易理解的
視圖層(View)
對(duì)應(yīng)于XML布局文件
控制層(Controller)
Android的控制層是由Activity來(lái)承擔(dān)的枚荣，Activity本來(lái)主要是作為初始化頁(yè)面，展示數(shù)據(jù)的操作啼肩，但是因?yàn)閄ML視圖功能太弱橄妆，所以Activity既要負(fù)責(zé)視圖的顯示又要加入控制邏輯，承擔(dān)的功能過(guò)多祈坠。
模型層(Model)
我們針對(duì)業(yè)務(wù)模型呼畸，建立的數(shù)據(jù)結(jié)構(gòu)和相關(guān)的類，它主要負(fù)責(zé)網(wǎng)絡(luò)請(qǐng)求颁虐，數(shù)據(jù)庫(kù)處理，I/O的操作卧须。
在Android 開(kāi)發(fā)當(dāng)中我們都知道Activity并不是控制層(Controller) 但是在這個(gè)模式中Activity卻被我們當(dāng)做控制層使用,本來(lái)它的首要職責(zé)是加載應(yīng)用的布局和初始化用戶界面另绩，接受并處理來(lái)自用戶的操作請(qǐng)求，進(jìn)而作出響應(yīng)花嘶。在MVC模式下隨著界面及其邏輯的復(fù)雜度不斷提升笋籽，Activity類的職責(zé)不斷增加，以致變得龐大臃腫椭员。
MVP
MVP 是 Model-View-Presenter
Model：
業(yè)務(wù)邏輯和實(shí)體模型车海，用來(lái)操作實(shí)際的數(shù)據(jù)，包含 Bean 和 Model 的抽
象接口 來(lái)降低耦合隘击。
View：
就是 Android 中的視圖侍芝，需要建立一個(gè) View 的抽象接口 View Interface。
通過(guò)實(shí) 現(xiàn) View 的接口來(lái)實(shí)現(xiàn) View 與 Presenter 的交互埋同，從而降低耦合州叠。對(duì)應(yīng)于
Activity， 負(fù)責(zé) View 的繪制與用戶交互凶赁；
Presenter：
View 和 Model 的中間樞紐咧栗，處理和用戶交互的邏輯。
Activity/Fragment
只充當(dāng)視圖層虱肄，不做任何的業(yè)務(wù)邏輯致板，將業(yè)務(wù)邏輯全部放在
業(yè)務(wù)層，由 Presenter 和 Model 進(jìn)行交互咏窿，避免 Model 直接操作 View斟或。以達(dá)到
解耦的效果。
MVP的優(yōu)點(diǎn):
1.模型與視圖完全分離翰灾，我們可以修改視圖而不影響模型缕粹；
2.項(xiàng)目代碼結(jié)構(gòu)（文件夾）清晰稚茅，一看就知道什么類干什么事情；
3.我們可以將一個(gè)Presenter用于多個(gè)視圖平斩，而不需要改變Presenter的邏輯亚享，這個(gè)特性非常的有用，因?yàn)橐晥D的變化總是比模型的變化頻繁
4.協(xié)同工作（例如在設(shè)計(jì)師沒(méi)出圖之前可以先寫(xiě)一些業(yè)務(wù)邏輯代碼或者其他人接手代碼改起來(lái)比較容易）;
5.代碼靈活性
MVP的缺點(diǎn)：
Presenter層與View層是通過(guò)接口進(jìn)行交互的绘面，View層可能會(huì)有大量的接口欺税，因?yàn)橛锌赡芎脦讉€(gè)Activity都是去實(shí)現(xiàn)同一個(gè)View接口，那么所有用到的Activity都要去實(shí)現(xiàn)所有的方法(不管你是否用到)揭璃，而且如果后面有些方法要?jiǎng)h改晚凿，Presenter和Activity都要改動(dòng)，比較麻煩瘦馍；
MVP 使用特點(diǎn)是面向接口編程（View/Presenter/Model 都定義一套接口）歼秽。
MVVM
MVP中我們說(shuō)過(guò)隨著業(yè)務(wù)邏輯的增加，UI的改變多的情況下情组，會(huì)有非常多的跟UI相關(guān)的 Case燥筷，這樣就會(huì)造成View的接口會(huì)很龐大。
而MVVM就解決了這個(gè)問(wèn)題院崇，通過(guò)雙向綁定的機(jī)制肆氓，實(shí)現(xiàn)數(shù)據(jù)和UI內(nèi)容，只要想改其中一方底瓣，另一方都能夠及時(shí)更新的一種設(shè)計(jì)理念谢揪，這樣就省去了很多在View層中寫(xiě)很多 Case 的情況，只需要改變數(shù)據(jù)就行捐凭。
Model：
Model層就是職責(zé)數(shù)據(jù)的存儲(chǔ)拨扶、讀取網(wǎng)絡(luò)數(shù)據(jù)、操作數(shù)據(jù)庫(kù)數(shù)據(jù)以及I/O柑营，一般會(huì)有一個(gè)ViewModel對(duì)象來(lái)調(diào)用獲取這一部分的數(shù)據(jù)屈雄。
View：
我感覺(jué)這里的View才是真正的View，為什么這么說(shuō)官套？View層做的僅僅和UI相關(guān)的工作酒奶，我們只在XML、Activity奶赔、Fragment寫(xiě)View層的代碼惋嚎。
View層不做任何業(yè)務(wù)邏輯、不涉及操作數(shù)據(jù)站刑、不處理數(shù)據(jù)另伍、UI和數(shù)據(jù)嚴(yán)格的分開(kāi)。
ViewModel：
ViewModel 只做和業(yè)務(wù)邏輯和業(yè)務(wù)數(shù)據(jù)相關(guān)的事，不做任何和UI摆尝、控件相關(guān)的事温艇，ViewModel 層不會(huì)持有任何控件的引用，更不會(huì)在ViewModel中通過(guò)UI控件的引用去做更新UI的事情堕汞。
ViewModel就是專注于業(yè)務(wù)的邏輯處理勺爱，操作的也都是對(duì)數(shù)據(jù)進(jìn)行操作，這些個(gè)數(shù)據(jù)源綁定在相應(yīng)的控件上會(huì)自動(dòng)去更改UI讯检，開(kāi)發(fā)者不需要關(guān)心更新UI的事情琐鲁。
MVVM 的缺點(diǎn)：
數(shù)據(jù)綁定使得 Bug 很難被調(diào)試。
你看到界面異常了人灼，有可能是你 View 的代碼有 Bug围段，也可能是 Model 的代碼有問(wèn)題。
數(shù)據(jù)綁定使得一個(gè)位置的 Bug 被快速傳遞到別的位置投放，要定位原始出問(wèn)題的地方就變得不那么容易了奈泪。
不管是用哪種設(shè)計(jì)模式，只要運(yùn)用得當(dāng)灸芳，都可以達(dá)到想要的結(jié)果段磨。如果非要說(shuō)怎么選的話，建議如下：
1.如果項(xiàng)目簡(jiǎn)單耗绿，沒(méi)什么復(fù)雜性，未來(lái)改動(dòng)也不大的話砾隅，選擇常用的 MVC 就可以了误阻，注意將每個(gè)模塊封裝好，方便調(diào)用即可晴埂。
2.對(duì)于偏向展示型的 APP究反，絕大多數(shù)業(yè)務(wù)邏輯都在后端，APP 主要功能就是展示數(shù)據(jù)儒洛，交互等精耐，建議使用 MVVM。
3.對(duì)于工具類或者需要寫(xiě)很多業(yè)務(wù)邏輯 APP琅锻，使用MVP或者M(jìn)VVM都可卦停。
