本文由業(yè)松所寫秀存，轉(zhuǎn)載請(qǐng)注明作者羔杨。
先上個(gè)鏈接吧性誉，谷歌官方github的Android架構(gòu)demo窿吩，里面有各種各樣的MVP、MVVM架構(gòu)错览，可以clone下來自己新建項(xiàng)目的時(shí)候作參考纫雁。clone后需要切換branch才能看到其他架構(gòu)的代碼。
今年MVC倾哺、MVP轧邪、MVVM都有寫，其中MVVM以前沒接觸過羞海，現(xiàn)在終于可以談?wù)勥@三種架構(gòu)的使用感受了忌愚。由于今年寫的Android項(xiàng)目都是商業(yè)的，沒寫個(gè)人項(xiàng)目却邓，代碼貼不了（可以說純干聊硕糊，無干貨- -）。
子虛烏有的MVC（Model-View-Controller）
為什么說Android MVC架構(gòu)子虛烏有？MVC分層概念是在Java后臺(tái)Spring框架里拿過來的简十。人家的Controller和View層代碼確實(shí)是分離的衙耕。Android里面哪里分了，對(duì)此我斗膽做個(gè)猜測(cè)：在發(fā)明Android-MVP架構(gòu)的時(shí)候勺远，大家不知道怎么稱呼原始的Android架構(gòu)橙喘，于是強(qiáng)行從Spring那里拿了個(gè)MVC的名字把它和MVP區(qū)分開來。
Controller層的本意是處理事件的分發(fā)和響應(yīng)胶逢，把Activity看作Controller層也不是不可以厅瞎，但是既然View和Controller并沒有分層，沒必要牽強(qiáng)附會(huì)到MVC上去初坠。
所以所謂的MVC在Android里就是沒有分層架構(gòu)的意思和簸。沒有分層的架構(gòu)是不是就一定不好呢？當(dāng)然不是碟刺，別說小型應(yīng)用锁保，就是谷歌自己寫的應(yīng)用也有好幾千行代碼一個(gè)Activity好幾千行代碼擼到底的呢（想找個(gè)例子來著，發(fā)現(xiàn)最新版本的aosp里Activity和Fragment代碼都精簡(jiǎn)了不少）半沽。
在代碼領(lǐng)域很多事情不是非此即彼爽柒，我見過不少商業(yè)項(xiàng)目有著各種架構(gòu)、設(shè)計(jì)模式還有封裝好的基類者填，最后Presenter里就幾行代碼甚至一行代碼都沒有浩村。因此對(duì)于小項(xiàng)目，Activity里的代碼不重的話占哟，沒必要各種分層心墅。對(duì)于可能會(huì)寫成大項(xiàng)目的項(xiàng)目，也可以先不分層榨乎，后續(xù)該重構(gòu)的時(shí)候再重構(gòu)怎燥。真的要一個(gè)Activity幾千行的話肯定是不建議的，閱讀性太差蜜暑，定位铐姚、修改起來也十分困難。
商業(yè)項(xiàng)目廣泛使用的MVP（Model-View-Presenter）
MVP架構(gòu)在Android領(lǐng)域可謂十分成熟史煎，我見過的商業(yè)項(xiàng)目很多都喜歡用MVP架構(gòu)谦屑。好處自然不用多說，把與UI無關(guān)的邏輯代碼全部抽出來放到Presenter層里篇梭，用接口明確定義好View層和Presenter層的功能氢橙。這樣的話架構(gòu)層次清晰，閱讀和修改起來要容易得多恬偷。
不過使用MVP架構(gòu)的項(xiàng)目往往會(huì)有過度封裝的傾向悍手。基本上都會(huì)封裝有BaseActivity、BaseFragment坦康、BasePresenter竣付，BaseView、BaseModel等等滞欠。封裝可以讓我們更多地復(fù)用代碼古胆，少寫重復(fù)代碼。但是封裝是不是百利而無一害呢筛璧？當(dāng)然不是逸绎，封裝有時(shí)候會(huì)犧牲代碼的靈活性。比如在基類里定義了太多類的行為夭谤，子類想要修改就只能復(fù)寫棺牧。但是可能一個(gè)地方例外，所以地方都變得不一樣朗儒，封裝的太死的話很多地方都要重寫颊乘。因此基類的東西應(yīng)該只有確定所有子類都一致的東西，不要試圖把所有的東西都塞到基類里醉锄。我當(dāng)時(shí)所在的一個(gè)項(xiàng)目用的mvp?dagger架構(gòu)乏悄，新建一個(gè)Fragment大概要添加/修改七八個(gè)類，不得不說真的挺費(fèi)勁的榆鼠。
毫無疑問纲爸，MVP給Android帶來了代碼分層的概念亥鸠，確實(shí)是一個(gè)很好的實(shí)踐妆够。但是在使用MVP之前先考慮一下自己能不能接受一個(gè)頁面至少要寫四五個(gè)類- -
最“流行”的MVVM（Model-View-ViewModel）
為啥流行加了雙引號(hào)呢，因?yàn)樵贏ndroid領(lǐng)域還是MVP最流行负蚊，而在Javascript前端領(lǐng)域神妹，Angular、Vue家妆、React都是MVVM架構(gòu)鸵荠。所以MVVM是真的火到爆炸。至于為什么Android MVVM還不是很流行呢（起碼我身邊很多同行都沒用過伤极，我也是今年才真正用過）蛹找？之前和微信群里的一個(gè)網(wǎng)友討論過，我覺得他說的很有道理：前幾年Android開發(fā)火熱的時(shí)候MVP架構(gòu)應(yīng)運(yùn)而生哨坪，人人面試都要談MVP庸疾。而今更新一代的MVVM架構(gòu)出來后，Android開發(fā)市場(chǎng)早已冷卻当编，大家沒有動(dòng)力去切換新的設(shè)計(jì)模式届慈，畢竟哪怕啥架構(gòu)模式也沒有不也一樣能開發(fā)大型項(xiàng)目么？
MVP和MVVM有啥區(qū)別呢？我也看過很多文章金顿，不過talk is cheap臊泌，看再多還是要真正去實(shí)踐才能感受MVVM架構(gòu)的好用之處，也明白了為什么三大JS前端框架都用這種架構(gòu)揍拆。
MVP和MVVM區(qū)別就是P和VM區(qū)別渠概。Presenter層是把UI無關(guān)的邏輯自己處理掉，最后把處理完的數(shù)據(jù)傳輸給View層展示嫂拴；ViewModel是把Model和View層關(guān)聯(lián)起來的一個(gè)中間層高氮，讓View層可以響應(yīng)式地展示數(shù)據(jù)。在我看來顷牌，VM的核心思想就是UI回調(diào)剪芍。View層通過ViewModel可以直接動(dòng)態(tài)地展示數(shù)據(jù)，我們不需要在數(shù)據(jù)改變時(shí)去回調(diào)UI窟蓝，這樣可以省去非常非常多的UI代碼罪裹，怪不得前端都喜歡MVVM。
Android MVVM的實(shí)現(xiàn)方式主要有兩種运挫，一種是給數(shù)據(jù)加監(jiān)聽状共，比如使用LiveData，在數(shù)據(jù)變化時(shí)執(zhí)行監(jiān)聽的回調(diào)谁帕，這樣就不需要每次改變數(shù)據(jù)后再手動(dòng)地修改UI峡继。第二種就是[DataBinding]{https://developer.android.com/topic/libraries/data-binding/}框架了。在layout xml里面定義Observable數(shù)據(jù)匈挖，然后直接把數(shù)據(jù)塞給控件碾牌。通常我們會(huì)把要展示的最終數(shù)據(jù)封裝到ViewModel層代碼里。而且在xml里也能對(duì)數(shù)據(jù)進(jìn)行簡(jiǎn)單的操作儡循，具體數(shù)據(jù)操作大家在這里查到舶吗。
MVP并沒有真正減少代碼，只是把代碼做了分層择膝。而MVVM不但讓代碼分層的更加干凈誓琼，還減少了大量的UI回調(diào)代碼。因此用過MVVM之后我就愛上了它肴捉，相信你也一樣腹侣！
關(guān)于Model層
從寫MVP代碼開始我就在想，Model層到底是個(gè)啥齿穗？很多人把Model層翻譯為數(shù)據(jù)層傲隶，可是Model是模型的意思啊。Model是不是只包括Model類缤灵，還是包含數(shù)據(jù)增刪改查所有代碼伦籍，我一直在想這個(gè)問題蓝晒。而且我問過不少人看過不少文章，各種看法都有帖鸦。
在上面的googlesamples芝薇，很多架構(gòu)的M層是包含數(shù)據(jù)的獲取的，并且會(huì)封裝到XXXRepository類里作儿。這樣做的好處就是保證數(shù)據(jù)來源的唯一性(前端數(shù)據(jù)層框架Redux三大原則第一條就是Single source of truth)洛二。而在SpringMVC里面，pojo數(shù)據(jù)的增刪改查被封裝到dao層攻锰，業(yè)務(wù)處理會(huì)封裝到service層晾嘶。因此大型架構(gòu)的數(shù)據(jù)的操作基本上都會(huì)進(jìn)行封裝，這點(diǎn)沒有疑問娶吞。至于這些repository垒迂、dao、service層屬于Model層還是Presenter層還是另外一個(gè)層面妒蛇，可以看看Wiki上關(guān)于MVC的定義：
The model is the central component of the pattern. It is the application's dynamic data structure, independent of the user interface.It directly manages the data, logic and rules of the application.
從這段話可以看出來dao層机断，repository層確實(shí)屬于Model層，至于更進(jìn)一步的業(yè)務(wù)處理绣夺，則不屬于Model層（比如在MVP里就是P層）吏奸。
最后歡迎大家多多交流，不吝指點(diǎn)陶耍。
