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