談談Android項目框架的前世今生

嗨募谎，大家好扶关，今天出了大太陽，真是美好的開始数冬。
這篇文章和大家說說Android屆流行的三大框架节槐，了解下架構(gòu)的前世今生，以及我對于這些框架的一些認識和看法拐纱。

三大框架區(qū)別

MVC

架構(gòu)介紹

Model：數(shù)據(jù)模型铜异，比如我們從數(shù)據(jù)庫或者網(wǎng)絡(luò)獲取數(shù)據(jù)
View：視圖，也就是我們的xml布局文件
Controller：控制器秸架，也就是我們的Activity

模型聯(lián)系

View --> Controller熙掺，也就是反應View的一些用戶事件（點擊觸摸事件）到Activity上。
Controller --> Model, 也就是Activity去讀寫一些我們需要的數(shù)據(jù)咕宿。
Controller --> View, 也就是Activity在獲取數(shù)據(jù)之后，將更新內(nèi)容反映到View上蜡秽。

這樣一個完整的項目架構(gòu)就出來了府阀，也是我們早期進行開發(fā)比較常用的項目架構(gòu)。

優(yōu)缺點

這種缺點還是比較明顯的芽突，主要表現(xiàn)就是我們的Activity太重了试浙，經(jīng)常一寫就是幾百上千行了。
造成這種問題的原因就是Controller層和View層的關(guān)系太過緊密寞蚌，也就是Activity中有太多操作View的代碼了田巴。

但是钠糊！但是！我覺得Android這種默認的開發(fā)結(jié)構(gòu)稱不上傳統(tǒng)的MVC結(jié)構(gòu)壹哺，因為Activity又可以叫View層又可以叫Controller層抄伍，所以細說的話根本就分不出來層級，只是做了一些封裝管宵，然后Activity承載了所有截珍。
當然這是我個人看法，可以都來討論下箩朴。

MVP

架構(gòu)介紹

之前不就是因為Activity中有操作view岗喉，又做Controller工作嗎。
所以其實MVP架構(gòu)就是從原來的Activity層把view和Controller區(qū)分開炸庞，單獨抽出來一層Presenter作為原來Controller的職位钱床。
然后最后演化成，將View層寫成接口的形式埠居，然后Activity去實現(xiàn)View接口查牌，最后在Presenter類中去實現(xiàn)方法。

Model：數(shù)據(jù)模型拐格，比如我們從數(shù)據(jù)庫或者網(wǎng)絡(luò)獲取數(shù)據(jù)僧免。
View：視圖，也就是我們的xml布局文件和Activity捏浊。
Presenter：主持人懂衩，單獨的類，只做調(diào)度工作金踪。

模型聯(lián)系

View --> Presenter浊洞，反應View的一些用戶事件到Presenter上。
Presenter --> Model, Presenter去讀寫操作一些我們需要的數(shù)據(jù)胡岔。
Controller --> View, Presenter在獲取數(shù)據(jù)之后法希，將更新內(nèi)容反饋給Activity，進行view更新靶瘸。

優(yōu)缺點

這種的優(yōu)點就是確實大大減少了Activity的負擔苫亦，讓Activity主要承擔一個更新View的工作，然后把跟Model交互的工作轉(zhuǎn)移給了Presenter怨咪，從而由Presenter方來控制和交互Model方以及View方屋剑。所以讓項目更加明確簡單，順序性思維開發(fā)诗眨。

缺點也很明顯：
首先就是代碼量大大增加了唉匾，每個頁面或者說功能點，都要專門寫一個Presenter類匠楚，并且由于是面向接口編程巍膘，需要增加大量接口厂财，會有大量繁瑣的回調(diào)。
其次峡懈，由于Presenter里持有了Activity對象璃饱，所以可能會導致內(nèi)存泄漏或者view空指針，這也是需要注意的地方逮诲。

MVVM

架構(gòu)介紹

MVVM的特點就是雙向綁定帜平，并且有Google官方加持，更新了Jetpack中很多架構(gòu)組件梅鹦，比如ViewModel裆甩，Livedata，DataBinding等等齐唆，所以這個是現(xiàn)在的主流框架和官方推崇的框架嗤栓。

Model：數(shù)據(jù)模型，比如我們從數(shù)據(jù)庫或者網(wǎng)絡(luò)獲取數(shù)據(jù)箍邮。
View：視圖茉帅，也就是我們的xml布局文件和Activity。
ViewModel：關(guān)聯(lián)層锭弊，將Model和View綁定堪澎，使他們之間可以相互綁定實時更新

模型聯(lián)系

View --> ViewModel -->View，雙向綁定味滞，數(shù)據(jù)改動可以反映到界面樱蛤，界面的修改可以反映到數(shù)據(jù)。
ViewModel --> Model, 操作一些我們需要的數(shù)據(jù)剑鞍。

優(yōu)缺點

優(yōu)點就是官方大力支持昨凡，所以也更新了很多相關(guān)庫，讓MVVM架構(gòu)更強更好用蚁署，而且雙向綁定的特點可以讓我們省去很多View和Model的交互便脊。也基本解決了上面兩個架構(gòu)的問題。

說說我理解的MVVM

先說說MVVM是怎么解決了其他兩個架構(gòu)所在的缺陷和問題：

解決了各個層級之間耦合度太高的問題光戈，也就是更好的完成了解耦哪痰。MVP層中，Presenter還是會持有View的引用久妆，但是在MVVM中妒御，View和Model進行雙向綁定，從而使viewModel基本只需要處理業(yè)務邏輯镇饺，無需關(guān)系界面相關(guān)的元素了。
解決了代碼量太多送讲，或者模式化代碼太多的問題奸笤。由于雙向綁定惋啃，所以UI相關(guān)的代碼就少了很多，這也是代碼量少的關(guān)鍵监右。而這其中起到比較關(guān)鍵的組件就是DataBinding边灭，使所有的UI變動都交給了被觀察的數(shù)據(jù)模型。
解決了可能會有的內(nèi)存泄漏問題健盒。MVVM架構(gòu)組件中有一個組件是LiveData绒瘦，它具有生命周期感知能力，可以感知到Activity等的生命周期扣癣，所以就可以在其關(guān)聯(lián)的生命周期遭到銷毀后自行清理惰帽，就大大減少了內(nèi)存泄漏問題。
解決了因為Activity停止而導致的View空指針問題父虑。在MVVM中使用了LiveData该酗，那么在需要更新View的時候，如果觀察者的生命周期處于非活躍狀態(tài)（如返回棧中的 Activity）士嚎，則它不會接收任何 LiveData 事件呜魄。也就是他會保證在界面可見的時候才會進行響應，這樣就解決了空指針問題莱衩。
解決了生命周期管理問題爵嗅。這主要得益于Lifecycle組件，它使得一些控件可以對生命周期進行觀察笨蚁，就能隨時隨地進行生命周期事件睹晒。

再說說響應式編程

響應式編程，說白了就是我先構(gòu)建好事物之間的關(guān)系赚窃，然后就可以不用管了册招。他們之間會因為這層關(guān)系而互相驅(qū)動。
其實也就是我們常說的觀察者模式勒极，或者說訂閱發(fā)布模式是掰。

為什么說這個呢，因為MVVM的本質(zhì)思想就是類似這種辱匿。不管是雙向綁定键痛，還是生命周期感知，其實都是一種觀察者模式匾七，使所有事物變得可觀察絮短，那么我們只需要把這種觀察關(guān)系給穩(wěn)定住，那么項目也就穩(wěn)健了昨忆。

最后再說說MVVM為什么這么強大丁频？

我個人覺得，MVVM強大不是因為這個架構(gòu)本身，而是因為這種響應式編程的優(yōu)勢比較大席里，再加上Google官方的大力支持叔磷，出了這么多支持的組件，來維系MVVM架構(gòu)奖磁，其實也是官方想進行項目架構(gòu)的統(tǒng)一改基。

優(yōu)秀的架構(gòu)思想+官方支持=強大

拜拜

有一起學習的小伙伴可以關(guān)注下?? 我的公.眾.號——碼上積木，每天三問面試真題咖为，詳細剖析秕狰，助你成為offer收割機。