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