Part 01
● 架構的概念 ●
在移動端開發中，一般將代碼分為三個部分：UI邏輯，業務邏輯和數據操作邏輯。
Android的架構就是希望達到這樣的目的：
1.降低代碼之(zhi)間的耦(ou)合(he)率，使團(tuan)隊(dui)可(ke)以(yi)清晰的劃分各(ge)自的任(ren)務，提(ti)高開發效率;
2.使代碼(ma)邏輯清晰，提高代碼(ma)的可讀性與可維護性;
3.減少重(zhong)復代碼，提高(gao)開發的(de)效率，避免重(zhong)復造輪(lun)子(zi)。
為(wei)了達到以上的目的，涌現(xian)(xian)出了許多的架(jia)(jia)(jia)構。谷歌(ge)官方也推出了自己的架(jia)(jia)(jia)構組件(jian)，用成(cheng)熟的框(kuang)架(jia)(jia)(jia)來(lai)減少樣(yang)板代碼，提高開發效率，猶如SpringMVC的風范，這就是(shi)MVVM的框(kuang)架(jia)(jia)(jia)實現(xian)(xian)。下面我們來(lai)簡單認識一下這幾(ji)種架(jia)(jia)(jia)構。
Part 02
● MVC ●
MVC架(jia)構(gou)應該是每個Android第(di)一次(ci)進行開發時所使用(yong)的(de)架(jia)構(gou)。View層負責頁面的(de)顯示(shi)，與用(yong)戶的(de)交互，獲(huo)取(qu)用(yong)戶的(de)操(cao)作。Controller負責接(jie)收用(yong)戶的(de)操(cao)作并處(chu)理業務邏(luo)(luo)輯。Model層則負責數(shu)(shu)據處(chu)理，網絡請求及可能(neng)涉(she)及到的(de)本(ben)地數(shu)(shu)據庫操(cao)作等。MVC的(de)本(ben)質(zhi)就是按照UI邏(luo)(luo)輯、業務邏(luo)(luo)輯、數(shu)(shu)據邏(luo)(luo)輯不同(tong)的(de)職責分三大模塊，彼此分工(gong)。
在Android開發中，View一般由xml文件表現。但是由于xml的(de)能(neng)力不足(zu)，我們(men)對(dui)于ui處理的(de)邏輯被放(fang)在了(le)activity中。同時關于controller的(de)業務(wu)邏輯代碼，一部分也放(fang)在了(le)activity中，與model層的(de)交互便在此中進行(xing)。
由(you)此帶來了MVC架構的問題與弊(bi)端，在activity中會(hui)(hui)同時包含(han)我們的ui和業務(wu)邏(luo)輯(ji)代碼。隨著項(xiang)目的變大和頁面的復雜(za)，在activity中的代碼會(hui)(hui)變得越(yue)(yue)來越(yue)(yue)多，越(yue)(yue)來越(yue)(yue)復雜(za)，難(nan)以維護(hu)。同時view直接持有(you)controller和model實例，不同職責的代碼進行耦(ou)合，導(dao)致代碼耦(ou)合性高，模塊(kuai)分(fen)工不清晰。各功(gong)能模塊(kuai)之間互相粘(zhan)連，當想更新或者(zhe)處理一些bug的時候會(hui)(hui)非(fei)常困難(nan)。
同時MVC架構的好處便是我們不需(xu)(xu)要寫(xie)大量的隔離代碼用來解藕(ou)。當我們面(mian)對一些簡(jian)單的頁面(mian)和需(xu)(xu)求(qiu)快(kuai)速響應的需(xu)(xu)求(qiu)時，它可以幫(bang)助我們快(kuai)速完成(cheng)。
從中我們也能看到MVC下一步需要進化改進的方向：
1.加強view與model之間的解(jie)藕，使它(ta)們減少(shao)互相持有。
2.減(jian)輕controller的冗雜(za)程(cheng)度，減(jian)重以提(ti)高可維護(hu)性(xing)和可讀性(xing)。
由此(ci)我們(men)來介紹下(xia)一種架構。
Part 03
● MVP ●
MVP全名是Model-View-Presenter。與mvc模式相(xiang)比，它具有(you)更好(hao)的(de)可擴(kuo)展性和(he)(he)可維護性，代碼間的(de)耦(ou)合程度更低。View層負(fu)責(ze)頁(ye)面的(de)顯(xian)示，與用(yong)戶的(de)交互，獲取用(yong)戶的(de)操(cao)作(zuo)。Model層則負(fu)責(ze)數據(ju)處(chu)理，網絡請求及(ji)可能涉(she)及(ji)到的(de)本地數據(ju)庫(ku)操(cao)作(zuo)等(deng)。它們的(de)職責(ze)都沒有(you)變化，不同(tong)的(de)地方在于Presenter：它負(fu)責(ze)業務邏輯，起(qi)著連接(jie)View和(he)(he)Model橋梁(liang)的(de)作(zuo)用(yong)。
為(wei)了解決mvc中(zhong)代碼耦合程(cheng)度高(gao)的(de)(de)問題，我們(men)(men)將(jiang)業務邏輯都抽離出來放入Presenter中(zhong)，這樣(yang)我們(men)(men)的(de)(de)Model和(he)View實現了完全的(de)(de)隔(ge)離，實現了單向依賴。在(zai)View和(he)Psenter之間使用接口來通信，這樣(yang)我們(men)(men)可以按照功能或者需求來劃(hua)分各自(zi)的(de)(de)模(mo)(mo)塊，同(tong)(tong)時進行開發。同(tong)(tong)樣(yang)在(zai)我們(men)(men)有需要(yao)時，我們(men)(men)也可以更換單獨某(mou)個(ge)模(mo)(mo)塊而不影響同(tong)(tong)一頁面中(zhong)其他模(mo)(mo)塊的(de)(de)運行，這是mvc所不具有的(de)(de)。
看上去(qu)mvp已經實現了我(wo)(wo)們(men)的(de)(de)(de)(de)需求，但(dan)它也有自己(ji)(ji)的(de)(de)(de)(de)問題。因(yin)為在我(wo)(wo)們(men)的(de)(de)(de)(de)實際開發過程中，每個(ge)(ge)頁(ye)面或(huo)多或(huo)少都(dou)會有所差異即沒有兩個(ge)(ge)完(wan)全(quan)相同的(de)(de)(de)(de)頁(ye)面，這也就導致了我(wo)(wo)們(men)每個(ge)(ge)activity都(dou)需要(yao)一個(ge)(ge)自己(ji)(ji)的(de)(de)(de)(de)Presenter及配套的(de)(de)(de)(de)接(jie)口，這使得我(wo)(wo)們(men)需要(yao)寫大量的(de)(de)(de)(de)代碼對其(qi)進行解藕，當面對小(xiao)型(xing)的(de)(de)(de)(de)項目時(shi)這反而(er)影(ying)響(xiang)了我(wo)(wo)們(men)的(de)(de)(de)(de)開發效率(lv)，同時(shi)controller臃腫的(de)(de)(de)(de)問題依然存在，解藕的(de)(de)(de)(de)程度還是(shi)不夠深。由此我(wo)(wo)們(men)來介紹下一種架構。
Part 04
● MVVM ●
MVVM，全(quan)名為(wei)Model-View-ViewModel。View層(ceng)負責(ze)頁面的(de)顯示，與用(yong)戶(hu)的(de)交(jiao)互，獲(huo)取用(yong)戶(hu)的(de)操(cao)作。Model層(ceng)則負責(ze)數(shu)據處理(li)，網絡請求及(ji)可(ke)能涉及(ji)到的(de)本(ben)地數(shu)據庫操(cao)作等。它們的(de)職責(ze)依然沒有(you)變化。ViewModel：負責(ze)存儲view的(de)數(shu)據映像以及(ji)業務邏(luo)輯。
MVVM模(mo)式(shi)(shi)中(zhong)的(de)重點就是viewmodel，它(ta)通過綁定的(de)方式(shi)(shi)將view與(yu)model一一對應，將數(shu)據(ju)(ju)的(de)變(bian)化直接(jie)顯示(shi)在我(wo)(wo)們的(de)view上，徹(che)底拋(pao)棄掉了MVP的(de)Presenter中(zhong)的(de)ui邏輯(ji)操作。我(wo)(wo)們也(ye)不(bu)再需要單獨編寫接(jie)口(kou)進行通信。之前的(de)業務邏輯(ji)也(ye)放在了viewmodel之中(zhong)。這(zhe)樣的(de)方式(shi)(shi)使得我(wo)(wo)們的(de)視圖(tu)與(yu)業務完全(quan)解藕，view專注于(yu)ui操作，viewmodel專注于(yu)業務操作，這(zhe)就是數(shu)據(ju)(ju)驅動的(de)思想。
要想實現這樣的效果我們(men)還需要一(yi)個簡單(dan)容易上手的框(kuang)架來幫助(zhu)我們(men)進(jin)行view與(yu)viewmodel之間的綁定和減輕viewmodel中業(ye)務(wu)邏(luo)輯操作過于復雜的部分。由(you)此(ci)谷(gu)歌官方推出(chu)了(le)mvvm框(kuang)架和與(yu)之一(yi)起使(shi)用的jetpack架構組(zu)件(jian)庫，包括了(le)：DataBinding，LiveData，ViewModel，Navigation，Lifecycle。
MVVM與MVC、MVP最大的差異便是MVVM是由數據驅動，專注于頁面開發的架構模式，更像谷歌官方(fang)推出的(de)專注于移動端開(kai)發(fa)的(de)架(jia)構。不(bu)同于其余兩種，MVVM的(de)開(kai)發(fa)需要頁面的(de)存在，這也導致(zhi)了它(ta)的(de)使用(yong)被限制在了頁面開(kai)發(fa)當中(zhong)，我們無法在插板洗衣機上(shang)進行開(kai)發(fa)。因為沒(mei)有數據對象與頁面可言。
Part 05
● 總結 ●
通過以上介紹(shao)我們可以發現，沒有完美無缺的(de)(de)(de)(de)(de)框(kuang)(kuang)(kuang)架(jia)(jia)，只有場景(jing)中最(zui)合適的(de)(de)(de)(de)(de)框(kuang)(kuang)(kuang)架(jia)(jia)。每一個框(kuang)(kuang)(kuang)架(jia)(jia)的(de)(de)(de)(de)(de)誕生都是伴(ban)隨(sui)著我們對(dui)某個特殊場景(jing)或者某些(xie)場景(jing)下的(de)(de)(de)(de)(de)特殊問題的(de)(de)(de)(de)(de)需(xu)(xu)(xu)求(qiu)。例(li)如Android中的(de)(de)(de)(de)(de)問題便是ui與業務邏(luo)輯的(de)(de)(de)(de)(de)解(jie)藕。但當我們面對(dui)一些(xie)小(xiao)型項(xiang)目(mu)，快速需(xu)(xu)(xu)求(qiu)或者沒有頁面顯示的(de)(de)(de)(de)(de)需(xu)(xu)(xu)要時(shi)，MVVM顯然也不是我們的(de)(de)(de)(de)(de)最(zui)優解(jie)。我們需(xu)(xu)(xu)要學習的(de)(de)(de)(de)(de)是對(dui)需(xu)(xu)(xu)求(qiu)的(de)(de)(de)(de)(de)拆分與理(li)解(jie)，選擇(ze)最(zui)合適我們項(xiang)目(mu)的(de)(de)(de)(de)(de)框(kuang)(kuang)(kuang)架(jia)(jia)。
