Part 01

架構(gòu)的概念 

在移動(dòng)端開發(fā)中，一般將代碼分為三個(gè)部分：UI邏輯，業(yè)務(wù)邏輯和數(shù)據(jù)操作邏輯。

Android的架構(gòu)就是希望達(dá)到這樣的目的：

1.降低代碼之間的耦合率，使團(tuán)隊(duì)可以清晰的劃分各自的任務(wù)，提高開發(fā)效率；

2.使代碼邏輯清晰，提高代碼的可讀性與可維護(hù)性；

3.減少重復(fù)代碼，提高開發(fā)的效率，避免重復(fù)造輪子。

為了達(dá)到以上的目的，涌現(xiàn)出了許多的架構(gòu)。谷歌官方也推出了自己的架構(gòu)組件，用成熟的框架來減少樣板代碼，提高開發(fā)效率，猶如SpringMVC的風(fēng)范，這就是MVVM的框架實(shí)現(xiàn)。下面我們來簡單認(rèn)識一下這幾種架構(gòu)。

Part 02

MVC 

MVC架構(gòu)應(yīng)該是每個(gè)Android第一次進(jìn)行開發(fā)時(shí)所使用的架構(gòu)。View層負(fù)責(zé)頁面的顯示，與用戶的交互，獲取用戶的操作。Controller負(fù)責(zé)接收用戶的操作并處理業(yè)務(wù)邏輯。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請求及可能涉及到的本地?cái)?shù)據(jù)庫操作等。MVC的本質(zhì)就是按照UI邏輯、業(yè)務(wù)邏輯、數(shù)據(jù)邏輯不同的職責(zé)分三大模塊，彼此分工。

在Android開發(fā)中，View一般由xml文件表現(xiàn)。但是由于xml的能力不足，我們對于ui處理的邏輯被放在了activity中。同時(shí)關(guān)于controller的業(yè)務(wù)邏輯代碼，一部分也放在了activity中，與model層的交互便在此中進(jìn)行。

由此帶來了MVC架構(gòu)的問題與弊端，在activity中會同時(shí)包含我們的ui和業(yè)務(wù)邏輯代碼。隨著項(xiàng)目的變大和頁面的復(fù)雜，在activity中的代碼會變得越來越多，越來越復(fù)雜，難以維護(hù)。同時(shí)view直接持有controller和model實(shí)例，不同職責(zé)的代碼進(jìn)行耦合，導(dǎo)致代碼耦合性高，模塊分工不清晰。各功能模塊之間互相粘連，當(dāng)想更新或者處理一些bug的時(shí)候會非常困難。

同時(shí)MVC架構(gòu)的好處便是我們不需要寫大量的隔離代碼用來解藕。當(dāng)我們面對一些簡單的頁面和需求快速響應(yīng)的需求時(shí)，它可以幫助我們快速完成。

從中我們也能看到MVC下一步需要進(jìn)化改進(jìn)的方向：

1.加強(qiáng)view與model之間的解藕，使它們減少互相持有。

2.減輕controller的冗雜程度，減重以提高可維護(hù)性和可讀性。

由此我們來介紹下一種架構(gòu)。

Part 03

MVP 

MVP全名是Model-View-Presenter。與mvc模式相比，它具有更好的可擴(kuò)展性和可維護(hù)性，代碼間的耦合程度更低。View層負(fù)責(zé)頁面的顯示，與用戶的交互，獲取用戶的操作。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請求及可能涉及到的本地?cái)?shù)據(jù)庫操作等。它們的職責(zé)都沒有變化，不同的地方在于Presenter：它負(fù)責(zé)業(yè)務(wù)邏輯，起著連接View和Model橋梁的作用。

為了解決mvc中代碼耦合程度高的問題，我們將業(yè)務(wù)邏輯都抽離出來放入Presenter中，這樣我們的Model和View實(shí)現(xiàn)了完全的隔離，實(shí)現(xiàn)了單向依賴。在View和Psenter之間使用接口來通信，這樣我們可以按照功能或者需求來劃分各自的模塊，同時(shí)進(jìn)行開發(fā)。同樣在我們有需要時(shí)，我們也可以更換單獨(dú)某個(gè)模塊而不影響同一頁面中其他模塊的運(yùn)行，這是mvc所不具有的。

看上去mvp已經(jīng)實(shí)現(xiàn)了我們的需求，但它也有自己的問題。因?yàn)樵谖覀兊膶?shí)際開發(fā)過程中，每個(gè)頁面或多或少都會有所差異即沒有兩個(gè)完全相同的頁面，這也就導(dǎo)致了我們每個(gè)activity都需要一個(gè)自己的Presenter及配套的接口，這使得我們需要寫大量的代碼對其進(jìn)行解藕，當(dāng)面對小型的項(xiàng)目時(shí)這反而影響了我們的開發(fā)效率，同時(shí)controller臃腫的問題依然存在，解藕的程度還是不夠深。由此我們來介紹下一種架構(gòu)。

Part 04

MVVM 

MVVM，全名為Model-View-ViewModel。View層負(fù)責(zé)頁面的顯示，與用戶的交互，獲取用戶的操作。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請求及可能涉及到的本地?cái)?shù)據(jù)庫操作等。它們的職責(zé)依然沒有變化。ViewModel：負(fù)責(zé)存儲view的數(shù)據(jù)映像以及業(yè)務(wù)邏輯。

MVVM模式中的重點(diǎn)就是viewmodel，它通過綁定的方式將view與model一一對應(yīng)，將數(shù)據(jù)的變化直接顯示在我們的view上，徹底拋棄掉了MVP的Presenter中的ui邏輯操作。我們也不再需要單獨(dú)編寫接口進(jìn)行通信。之前的業(yè)務(wù)邏輯也放在了viewmodel之中。這樣的方式使得我們的視圖與業(yè)務(wù)完全解藕，view專注于ui操作，viewmodel專注于業(yè)務(wù)操作，這就是數(shù)據(jù)驅(qū)動(dòng)的思想。

要想實(shí)現(xiàn)這樣的效果我們還需要一個(gè)簡單容易上手的框架來幫助我們進(jìn)行view與viewmodel之間的綁定和減輕viewmodel中業(yè)務(wù)邏輯操作過于復(fù)雜的部分。由此谷歌官方推出了mvvm框架和與之一起使用的jetpack架構(gòu)組件庫，包括了：DataBinding，LiveData，ViewModel，Navigation，Lifecycle。

MVVM與MVC、MVP最大的差異便是MVVM是由數(shù)據(jù)驅(qū)動(dòng)，專注于頁面開發(fā)的架構(gòu)模式，更像谷歌官方推出的專注于移動(dòng)端開發(fā)的架構(gòu)。不同于其余兩種，MVVM的開發(fā)需要頁面的存在，這也導(dǎo)致了它的使用被限制在了頁面開發(fā)當(dāng)中，我們無法在插板洗衣機(jī)上進(jìn)行開發(fā)。因?yàn)闆]有數(shù)據(jù)對象與頁面可言。

Part 05

總結(jié) 

通過以上介紹我們可以發(fā)現(xiàn)，沒有完美無缺的框架，只有場景中最合適的框架。每一個(gè)框架的誕生都是伴隨著我們對某個(gè)特殊場景或者某些場景下的特殊問題的需求。例如Android中的問題便是ui與業(yè)務(wù)邏輯的解藕。但當(dāng)我們面對一些小型項(xiàng)目，快速需求或者沒有頁面顯示的需要時(shí)，MVVM顯然也不是我們的最優(yōu)解。我們需要學(xué)習(xí)的是對需求的拆分與理解，選擇最合適我們項(xiàng)目的框架。