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)組件，用成熟的框架來(lái)減少樣板代碼，提高開發(fā)效率，猶如SpringMVC的風(fēng)范，這就是MVVM的框架實(shí)現(xiàn)。下面我們來(lái)簡(jiǎn)單認(rèn)識(shí)一下這幾種架構(gòu)。
Part 02
● MVC ●
MVC架構(gòu)應(yīng)該是每個(gè)Android第一次進(jìn)行開發(fā)時(shí)所使用的架構(gòu)。View層負(fù)責(zé)頁(yè)面的顯示，與用戶的交互，獲取用戶的操作。Controller負(fù)責(zé)接收用戶的操作并處理業(yè)務(wù)邏輯。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請(qǐng)求及可能涉及到的本地?cái)?shù)據(jù)庫(kù)操作等。MVC的本質(zhì)就是按照UI邏輯、業(yè)務(wù)邏輯、數(shù)據(jù)邏輯不同的職責(zé)分三大模塊，彼此分工。
在Android開發(fā)中，View一般由xml文件表現(xiàn)。但是由于xml的能力不足，我們對(duì)于ui處理的邏輯被放在了activity中。同時(shí)關(guān)于controller的業(yè)務(wù)邏輯代碼，一部分也放在了activity中，與model層的交互便在此中進(jìn)行。
由此帶來(lái)了MVC架構(gòu)的問(wèn)題與弊端，在activity中會(huì)同時(shí)包含我們的ui和業(yè)務(wù)邏輯代碼。隨著項(xiàng)目的變大和頁(yè)面的復(fù)雜，在activity中的代碼會(huì)變得越來(lái)越多，越來(lái)越復(fù)雜，難以維護(hù)。同時(shí)view直接持有controller和model實(shí)例，不同職責(zé)的代碼進(jìn)行耦合，導(dǎo)致代碼耦合性高，模塊分工不清晰。各功能模塊之間互相粘連，當(dāng)想更新或者處理一些bug的時(shí)候會(huì)非常困難。
同時(shí)MVC架構(gòu)的好處便是我們不需要寫大量的隔離代碼用來(lái)解藕。當(dāng)我們面對(duì)一些簡(jiǎn)單的頁(yè)面和需求快速響應(yīng)的需求時(shí)，它可以幫助我們快速完成。
從中我們也能看到MVC下一步需要進(jìn)化改進(jìn)的方向：
1.加強(qiáng)view與model之間的解藕，使它們減少互相持有。
2.減輕controller的冗雜程度，減重以提高可維護(hù)性和可讀性。
由此我們來(lái)介紹下一種架構(gòu)。
Part 03
● MVP ●
MVP全名是Model-View-Presenter。與mvc模式相比，它具有更好的可擴(kuò)展性和可維護(hù)性，代碼間的耦合程度更低。View層負(fù)責(zé)頁(yè)面的顯示，與用戶的交互，獲取用戶的操作。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請(qǐng)求及可能涉及到的本地?cái)?shù)據(jù)庫(kù)操作等。它們的職責(zé)都沒有變化，不同的地方在于Presenter：它負(fù)責(zé)業(yè)務(wù)邏輯，起著連接View和Model橋梁的作用。
為了解決mvc中代碼耦合程度高的問(wèn)題，我們將業(yè)務(wù)邏輯都抽離出來(lái)放入Presenter中，這樣我們的Model和View實(shí)現(xiàn)了完全的隔離，實(shí)現(xiàn)了單向依賴。在View和Psenter之間使用接口來(lái)通信，這樣我們可以按照功能或者需求來(lái)劃分各自的模塊，同時(shí)進(jìn)行開發(fā)。同樣在我們有需要時(shí)，我們也可以更換單獨(dú)某個(gè)模塊而不影響同一頁(yè)面中其他模塊的運(yùn)行，這是mvc所不具有的。
看上去mvp已經(jīng)實(shí)現(xiàn)了我們的需求，但它也有自己的問(wèn)題。因?yàn)樵谖覀兊膶?shí)際開發(fā)過(guò)程中，每個(gè)頁(yè)面或多或少都會(huì)有所差異即沒有兩個(gè)完全相同的頁(yè)面，這也就導(dǎo)致了我們每個(gè)activity都需要一個(gè)自己的Presenter及配套的接口，這使得我們需要寫大量的代碼對(duì)其進(jìn)行解藕，當(dāng)面對(duì)小型的項(xiàng)目時(shí)這反而影響了我們的開發(fā)效率，同時(shí)controller臃腫的問(wèn)題依然存在，解藕的程度還是不夠深。由此我們來(lái)介紹下一種架構(gòu)。
Part 04
● MVVM ●
MVVM，全名為Model-View-ViewModel。View層負(fù)責(zé)頁(yè)面的顯示，與用戶的交互，獲取用戶的操作。Model層則負(fù)責(zé)數(shù)據(jù)處理，網(wǎng)絡(luò)請(qǐng)求及可能涉及到的本地?cái)?shù)據(jù)庫(kù)操作等。它們的職責(zé)依然沒有變化。ViewModel：負(fù)責(zé)存儲(chǔ)view的數(shù)據(jù)映像以及業(yè)務(wù)邏輯。
MVVM模式中的重點(diǎn)就是viewmodel，它通過(guò)綁定的方式將view與model一一對(duì)應(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è)簡(jiǎn)單容易上手的框架來(lái)幫助我們進(jìn)行view與viewmodel之間的綁定和減輕viewmodel中業(yè)務(wù)邏輯操作過(guò)于復(fù)雜的部分。由此谷歌官方推出了mvvm框架和與之一起使用的jetpack架構(gòu)組件庫(kù)，包括了：DataBinding，LiveData，ViewModel，Navigation，Lifecycle。
MVVM與MVC、MVP最大的差異便是MVVM是由數(shù)據(jù)驅(qū)動(dòng)，專注于頁(yè)面開發(fā)的架構(gòu)模式，更像谷歌官方推出的專注于移動(dòng)端開發(fā)的架構(gòu)。不同于其余兩種，MVVM的開發(fā)需要頁(yè)面的存在，這也導(dǎo)致了它的使用被限制在了頁(yè)面開發(fā)當(dāng)中，我們無(wú)法在插板洗衣機(jī)上進(jìn)行開發(fā)。因?yàn)闆]有數(shù)據(jù)對(duì)象與頁(yè)面可言。
Part 05
● 總結(jié) ●
通過(guò)以上介紹我們可以發(fā)現(xiàn)，沒有完美無(wú)缺的框架，只有場(chǎng)景中最合適的框架。每一個(gè)框架的誕生都是伴隨著我們對(duì)某個(gè)特殊場(chǎng)景或者某些場(chǎng)景下的特殊問(wèn)題的需求。例如Android中的問(wèn)題便是ui與業(yè)務(wù)邏輯的解藕。但當(dāng)我們面對(duì)一些小型項(xiàng)目，快速需求或者沒有頁(yè)面顯示的需要時(shí)，MVVM顯然也不是我們的最優(yōu)解。我們需要學(xué)習(xí)的是對(duì)需求的拆分與理解，選擇最合適我們項(xiàng)目的框架。
