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

嗨，你們好，今天出了大太陽，真是美好的開始。
這篇文章和你們說說Android屆流行的三大框架，瞭解下架構的前世此生，以及我對於這些框架的一些認識和見解。

三大框架區別

MVC

• 架構介紹

Model：數據模型，好比咱們從數據庫或者網絡獲取數據
View：視圖，也就是咱們的xml佈局文件
Controller：控制器，也就是咱們的Activity

• 模型聯繫

View --> Controller，也就是反應View的一些用戶事件（點擊觸摸事件）到Activity上。
Controller --> Model, 也就是Activity去讀寫一些咱們須要的數據。
Controller --> View, 也就是Activity在獲取數據以後，將更新內容反映到View上。

這樣一個完整的項目架構就出來了，也是咱們早期進行開發比較經常使用的項目架構。

• 優缺點

這種缺點仍是比較明顯的，主要表現就是咱們的Activity過重了，常常一寫就是幾百上千行了。
形成這種問題的緣由就是Controller層和View層的關係太過緊密，也就是Activity中有太多操做View的代碼了。

可是！可是！我以爲Android這種默認的開發結構稱不上傳統的MVC結構，由於Activity又能夠叫View層又能夠叫Controller層，因此細說的話根本就分不出來層級，只是作了一些封裝，而後Activity承載了全部。
固然這是我我的見解，能夠都來討論下。

MVP

• 架構介紹

以前不就是由於Activity中有操做view，又作Controller工做嗎。
因此其實MVP架構就是從原來的Activity層把view和Controller區分開，單獨抽出來一層Presenter做爲原來Controller的職位。
而後最後演化成，將View層寫成接口的形式，而後Activity去實現View接口，最後在Presenter類中去實現方法。

Model：數據模型，好比咱們從數據庫或者網絡獲取數據。
View：視圖，也就是咱們的xml佈局文件和Activity。
Presenter：主持人，單獨的類，只作調度工做。

• 模型聯繫

View --> Presenter，反應View的一些用戶事件到Presenter上。
Presenter --> Model, Presenter去讀寫操做一些咱們須要的數據。
Controller --> View, Presenter在獲取數據以後，將更新內容反饋給Activity，進行view更新。

• 優缺點

這種的優勢就是確實大大減小了Activity的負擔，讓Activity主要承擔一個更新View的工做，而後把跟Model交互的工做轉移給了Presenter，從而由Presenter方來控制和交互Model方以及View方。因此讓項目更加明確簡單，順序性思惟開發。

缺點也很明顯：
首先就是代碼量大大增長了，每一個頁面或者說功能點，都要專門寫一個Presenter類，而且因爲是面向接口編程，須要增長大量接口，會有大量繁瑣的回調。
其次，因爲Presenter裏持有了Activity對象，因此可能會致使內存泄漏或者view空指針，這也是須要注意的地方。

MVVM

• 架構介紹

MVVM的特色就是雙向綁定，而且有Google官方加持，更新了Jetpack中不少架構組件，好比ViewModel，Livedata，DataBinding等等，因此這個是如今的主流框架和官方推崇的框架。

Model：數據模型，好比咱們從數據庫或者網絡獲取數據。
View：視圖，也就是咱們的xml佈局文件和Activity。
ViewModel：關聯層，將Model和View綁定，使他們之間能夠相互綁定實時更新

• 模型聯繫

View --> ViewModel -->View，雙向綁定，數據改動能夠反映到界面，界面的修改能夠反映到數據。
ViewModel --> Model, 操做一些咱們須要的數據。

• 優缺點

優勢就是官方大力支持，因此也更新了不少相關庫，讓MVVM架構更強更好用，並且雙向綁定的特色可讓咱們省去不少View和Model的交互。也基本解決了上面兩個架構的問題。

說說我理解的MVVM

先說說MVVM是怎麼解決了其餘兩個架構所在的缺陷和問題：

• 解決了各個層級之間耦合度過高的問題，也就是更好的完成了解耦。MVP層中，Presenter仍是會持有View的引用，可是在MVVM中，View和Model進行雙向綁定，從而使viewModel基本只須要處理業務邏輯，無需關係界面相關的元素了。

• 解決了代碼量太多，或者模式化代碼太多的問題。因爲雙向綁定，因此UI相關的代碼就少了不少，這也是代碼量少的關鍵。而這其中起到比較關鍵的組件就是DataBinding，使全部的UI變更都交給了被觀察的數據模型。

• 解決了可能會有的內存泄漏問題。MVVM架構組件中有一個組件是LiveData，它具備生命週期感知能力，能夠感知到Activity等的生命週期，因此就能夠在其關聯的生命週期遭到銷燬後自行清理，就大大減小了內存泄漏問題。

• 解決了由於Activity中止而致使的View空指針問題。在MVVM中使用了LiveData，那麼在須要更新View的時候，若是觀察者的生命週期處於非活躍狀態（如返回棧中的 Activity），則它不會接收任何 LiveData 事件。也就是他會保證在界面可見的時候纔會進行響應，這樣就解決了空指針問題。

• 解決了生命週期管理問題。這主要得益於Lifecycle組件，它使得一些控件能夠對生命週期進行觀察，就能隨時隨地進行生命週期事件。

再說說響應式編程

響應式編程，說白了就是我先構建好事物之間的關係，而後就能夠不用管了。他們之間會由於這層關係而互相驅動。
其實也就是咱們常說的觀察者模式，或者說訂閱發佈模式。

爲何說這個呢，由於MVVM的本質思想就是相似這種。不論是雙向綁定，仍是生命週期感知，其實都是一種觀察者模式，使全部事物變得可觀察，那麼咱們只須要把這種觀察關係給穩定住，那麼項目也就穩健了。

最後再說說MVVM爲何這麼強大？

我我的以爲，MVVM強大不是由於這個架構自己，而是由於這種響應式編程的優點比較大，再加上Google官方的大力支持，出了這麼多支持的組件，來維繫MVVM架構，其實也是官方想進行項目架構的統一。

優秀的架構思想+官方支持=強大

拜拜

有一塊兒學習的小夥伴能夠關注下❤️個人公衆號——碼上積木，天天三問面試真題，詳細剖析，助你成爲offer收割機。