談談Android專案框架的前世今生

jimuzz發表於2020-10-29

嗨,大家好,今天出了大太陽,真是美好的開始。
這篇文章和大家說說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層把viewController區分開,單獨抽出來一層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收割機。

相關文章