在過去的幾年里德玫，出現(xiàn)了幾種新的模式，所有這些模式都被譽(yù)為讓開發(fā)人員的生活變得前所未有的輕松椎麦。 通過分離代碼庫的某些部分宰僧，每種模式都試圖使代碼更具可讀性，更易于測(cè)試观挎，并最終更易于維護(hù)琴儿。在這篇文章中，我將討論軟件架構(gòu)設(shè)計(jì)模式：MVC嘁捷、MVP造成、MVVM、MVI 雄嚣。
架構(gòu)無分好壞晒屎，而是是否更適合項(xiàng)目的開發(fā)要求喘蟆。
1. MVC
Model：實(shí)體類(數(shù)據(jù)的獲取、存儲(chǔ)鼓鲁、數(shù)據(jù)狀態(tài)變化)蕴轨。
View：布局文件
Controller：Activity(處理數(shù)據(jù)、業(yè)務(wù)和UI)骇吭。
事件流向：
View接受用戶的交互請(qǐng)求橙弱。
View將請(qǐng)求轉(zhuǎn)交給Controller。
Controller操作Model進(jìn)行數(shù)據(jù)更新燥狰。
數(shù)據(jù)更新之后膘螟，Model通知View數(shù)據(jù)變化。
View顯示更新之后的數(shù)據(jù)碾局。
MVC的缺點(diǎn)
隨著界面及其邏輯的復(fù)雜度不斷提升荆残，Activity類的職責(zé)不斷增加，以致變得龐大臃腫净当。為了解決MVC的缺點(diǎn)内斯，MVP 框架被提出來。
2. MVP
Model：實(shí)體類(數(shù)據(jù)的獲取像啼、存儲(chǔ)俘闯、數(shù)據(jù)狀態(tài)變化)。
View：布局文件+Activity忽冻。
Presenter：中介真朗，負(fù)責(zé)完成View與Model間的交互和業(yè)務(wù)邏輯。
事件流向：
View 接收用戶交互請(qǐng)求
View 將請(qǐng)求轉(zhuǎn)交給 Presenter(V調(diào)用P接口)
Presenter 操作Model進(jìn)行數(shù)據(jù)更新(P調(diào)用M接口)
Model 通知Presenter數(shù)據(jù)發(fā)生變化(M調(diào)用P接口)
Presenter 更新View數(shù)據(jù)(P執(zhí)行接口,V相應(yīng)回調(diào))
MVP的優(yōu)點(diǎn)
復(fù)雜的邏輯處理放在Presenter進(jìn)行處理僧诚，減少了Activity的臃腫遮婶。
解耦。Model層與View層完全分離湖笨，修改V層不會(huì)影響M層旗扑，降低了耦合性。
可以將一個(gè)Presenter用于多個(gè)視圖慈省，而不需要改變Presenter的邏輯臀防。
MVP的缺點(diǎn)
維護(hù)困難。Presenter中除了業(yè)務(wù)邏輯以外边败，還有大量的View->Model袱衷，Model->View的手動(dòng)同步邏輯，造成Presenter比較笨重笑窜，維護(hù)起來會(huì)比較困難致燥。
接口膨脹
Presenter層通過接口與View通信，實(shí)際上持有了View的引用
但是隨著業(yè)務(wù)邏輯的增加怖侦，一個(gè)頁面可能會(huì)非常復(fù)雜篡悟，這樣就會(huì)造成View的接口會(huì)很龐大谜叹。
MVC和MVP的區(qū)別
- MVC是允許Model和View進(jìn)行交互的，而MVP中很明顯搬葬，Model與View之間交互由Presenter完成荷腊；
- MVC中V對(duì)應(yīng)的是布局文件，MVP中V對(duì)應(yīng)的是Activity急凰；
3. MVVM
Model：實(shí)體類(數(shù)據(jù)的獲取女仰、存儲(chǔ)、數(shù)據(jù)狀態(tài)變化)抡锈。
View：布局文件+Activity疾忍。
ViewModel： 關(guān)聯(lián)層，將Model和View進(jìn)行綁定床三，Model或View更改時(shí)一罩，實(shí)時(shí)刷新對(duì)方。
事件流向：
View 接收用戶交互請(qǐng)求
View 將請(qǐng)求轉(zhuǎn)交給ViewModel
ViewModel 操作Model數(shù)據(jù)更新
Model 更新完數(shù)據(jù)撇簿，通知ViewModel數(shù)據(jù)發(fā)生變化
ViewModel 更新View數(shù)據(jù)
即：
View/Model的變動(dòng)聂渊，只要改其中一方，另一方都能夠及時(shí)更新到四瘫。
MVVM的優(yōu)點(diǎn)
1.提高可維護(hù)性汉嗽。Data Binding可以實(shí)現(xiàn)雙向的交互，使得視圖和控制層之間的耦合程度進(jìn)一步降低找蜜，分離更為徹底饼暑，同時(shí)減輕了Activity的壓力。
2.DataBinding更多的是隱藏了Presenter層的回調(diào)細(xì)節(jié)洗做，MVVM其實(shí)有很多細(xì)節(jié)可以挖掘弓叛，如綁定的實(shí)現(xiàn)機(jī)制，是如何避免內(nèi)存泄漏等問題竭望。
MVVM的缺點(diǎn)
1.對(duì)于簡單的項(xiàng)目邪码，使用MVVM有點(diǎn)大材小用。
2.對(duì)于過大的項(xiàng)目咬清，數(shù)據(jù)綁定會(huì)導(dǎo)致內(nèi)存開銷大，影響性能奴潘。
3.ViewModel和View的綁定旧烧，使頁面異常追蹤變得不方便。有可能是View出錯(cuò)画髓，也有可能是ViewModel的業(yè)務(wù)邏輯有問題掘剪，也有可能是Model的數(shù)據(jù)出錯(cuò)。
MVVM與MVP的區(qū)別
- 它采用雙向綁定（data-binding）：View的變動(dòng)奈虾，自動(dòng)反映在 ViewModel夺谁，反之亦然廉赔。這樣開發(fā)者就不用處理接收事件，設(shè)置數(shù)據(jù)和View更新的工作匾鸥，框架已經(jīng)幫你做好了蜡塌，為開發(fā)節(jié)省了一大筆時(shí)間。
4. MVI
MVI 與 MVVM 很相似勿负，其借鑒了前端框架的思想馏艾，更加強(qiáng)調(diào)數(shù)據(jù)的單向流動(dòng)和唯一數(shù)據(jù)源,架構(gòu)圖如下所示
Model: 與MVVM中的Model不同的是，MVI的Model主要指UI狀態(tài)（State）奴愉。例如頁面加載狀態(tài)琅摩、控件位置等都是一種UI狀態(tài)
View: 與其他MVX中的View一致，可能是一個(gè)Activity或者任意UI承載單元锭硼。MVI中的View通過訂閱Model的變化實(shí)現(xiàn)界面刷新
Intent: 此Intent不是Activity的Intent房资，用戶的任何操作都被包裝成Intent后發(fā)送給Model層進(jìn)行數(shù)據(jù)請(qǐng)求
MVI強(qiáng)調(diào)數(shù)據(jù)的單向流動(dòng)，主要分為以下幾步：
用戶操作以Intent的形式通知Model
Model基于Intent更新State
View接收到State變化刷新UI檀头。
數(shù)據(jù)永遠(yuǎn)在一個(gè)環(huán)形結(jié)構(gòu)中單向流動(dòng)志膀，不能反向流動(dòng)：
MVI優(yōu)點(diǎn)：
強(qiáng)調(diào)數(shù)據(jù)單向流動(dòng)，很容易對(duì)狀態(tài)變化進(jìn)行跟蹤和回溯
使用ViewState對(duì)State集中管理鳖擒，只需要訂閱一個(gè) ViewState 便可獲取頁面的所有狀態(tài)溉浙，相對(duì) MVVM 減少了不少Livedata等多數(shù)數(shù)據(jù)的修改和監(jiān)聽。
ViewModel通過ViewState與Action通信蒋荚，通過瀏覽ViewState 和 Aciton 定義就可以理清 ViewModel 的職責(zé)戳稽，可以直接拿來作為接口文檔使用。
MVI缺點(diǎn)：
所有的操作最終都會(huì)轉(zhuǎn)換成State期升，所以當(dāng)復(fù)雜頁面的State容易膨脹
state是不變的惊奇，因此每當(dāng)state需要更新時(shí)都要?jiǎng)?chuàng)建新對(duì)象替代老對(duì)象，這會(huì)帶來一定內(nèi)存開銷
MVI與MVVM區(qū)別
- 強(qiáng)調(diào)數(shù)據(jù)單向流動(dòng)播赁，比雙向數(shù)據(jù)流動(dòng)更容易對(duì)狀態(tài)變化進(jìn)行跟蹤和回溯
- 不用向mvvm那樣監(jiān)聽多個(gè)數(shù)據(jù)變化的更新而那么颂郎，使用ViewState對(duì)State集中管理，只需要訂閱一個(gè) ViewState 便可獲取頁面的所有狀態(tài)容为，更容易管理狀態(tài)
參考：
https://juejin.cn/post/7043716896767606798
https://blog.csdn.net/qjyws/article/details/122769834
