分層思想
分層是一種思想，同時(shí)也是一種架構(gòu)模式摧玫。它的特點(diǎn)是專職，即某一層的職責(zé)是相同的绑青、確定的诬像；比如我們平時(shí)所謂的Dao屋群、Controller層…他們都有明確的職責(zé)。
分層架構(gòu)雖說不能完完全全的解決項(xiàng)目程序復(fù)雜度高的問題坏挠，但是通過分層芍躏，將大的問題抽象分解成了小的功能面，局部化在每一層中降狠，這樣就有效的降低了單個(gè)問題的規(guī)模和復(fù)雜度对竣；另外層與層之間也可以通過簡單的調(diào)整插入新的層面，用以滿足不斷變化的需求喊熟，同一層面來說也可近乎0成本的水平擴(kuò)展柏肪；并且易于Debug、測試芥牌。
什么是MVC/MVP ？
MVC實(shí)際上是一種分層思想的踐行者和改進(jìn)者聂使，在GUI編程中壁拉，MVC已經(jīng)有幾十年的歷史了。
顧名思義M(Model)即數(shù)據(jù)模型層柏靶，Model層很有意思弃理，對于服務(wù)端編程來說我們把MVC中的M極有可能是包括了業(yè)務(wù)處理(Service)和實(shí)體類的，對于客戶端編程來說MVC中的M可能就僅僅是數(shù)據(jù)模型屎蜓，當(dāng)然以上的說法只是于我個(gè)人而言的體會(huì)痘昌，不代表廣義立場。
V(View)即視圖層/表現(xiàn)層炬转，主要負(fù)責(zé)數(shù)據(jù)的展示和用戶的交互辆苔，C(Controller)即控制層，主要負(fù)責(zé)一些數(shù)據(jù)傳遞扼劈、請求轉(zhuǎn)發(fā)驻啤、業(yè)務(wù)處理的委派。
以上是標(biāo)準(zhǔn)意義上的MVC荐吵，對于Android來說：
Model：數(shù)據(jù)模型(實(shí)體類骑冗、持久化、IO)
View：布局文件
Controller：對應(yīng)于Activity先煎、Fragment贼涩，包含一些業(yè)務(wù)邏輯的處理
這里我們會(huì)發(fā)現(xiàn)，Android的MVC事實(shí)上V層的職責(zé)一部分被C層承擔(dān)了薯蝎，比如一些交互我們必須寫到Activity/Fragment中遥倦，這樣就會(huì)導(dǎo)致C層既包含UI操作，又有網(wǎng)絡(luò)請求良风、業(yè)務(wù)處理等谊迄；導(dǎo)致C層過于臃腫闷供，不利于項(xiàng)目后期的維護(hù)和擴(kuò)展。
所以统诺，MVP就應(yīng)運(yùn)而生了歪脏，MVP實(shí)際上是由MVC進(jìn)化而來，它比較好的解決了MVC時(shí)代遺留的問題粮呢，MVP中的各層含義：
Model：數(shù)據(jù)模型(實(shí)體類婿失、持久化、IO)
View：Activity/Fragment和布局文件
Presenter：負(fù)責(zé)完成View和Model之間的交互和業(yè)務(wù)邏輯
其核心是：設(shè)計(jì)一個(gè)抽象的V層接口啄寡，并由具體的View實(shí)現(xiàn)該接口溜嗜，P層內(nèi)部維護(hù)一個(gè)該接口的實(shí)例引用澳盐，一般在構(gòu)造函數(shù)中傳遞進(jìn)來復(fù)制(即View層初始化P層實(shí)例時(shí))，彼時(shí)P層即可通過調(diào)用該接口來完成對View層的操作,V層也因持有P層實(shí)例，可以進(jìn)行業(yè)務(wù)邏輯處理委派瑞凑。
MVVM是什么，與MVC/MVP有何區(qū)別 搭盾？
MVVM是對MVP/MVC的一種改進(jìn)祷蝌，既解決了MVC時(shí)代的職責(zé)不明的問題，也很好的解決了MVP模式中需要編寫過多繁瑣的接口痴昧，以及V層和P層互相依賴所產(chǎn)生的一些隱式問題稽穆。
在MVVM中，各層含義如下
Model：數(shù)據(jù)模型(實(shí)體類赶撰、持久化舌镶、IO)
View：Activity/Fragment和布局文件
ViewModel：業(yè)務(wù)邏輯的處理、數(shù)據(jù)的轉(zhuǎn)換豪娜、連接M層和V層的橋梁
看上去似乎和MVP中各層的職責(zé)是類似的餐胀，并沒有顯著的不同和改進(jìn)；那么我們?yōu)楹我褂肕VVM架構(gòu)呢侵歇？
- 雙向綁定骂澄、數(shù)據(jù)驅(qū)動(dòng)
在常規(guī)的開發(fā)模式中，數(shù)據(jù)變化需要更新UI的時(shí)候惕虑，需要先獲取UI控件的引用坟冲，然后再更新UI。獲取用戶的輸入和操作也需要通過UI控件的引用溃蔫。在MVVM中健提，這些都是通過數(shù)據(jù)驅(qū)動(dòng)來自動(dòng)完成的，數(shù)據(jù)變化后會(huì)自動(dòng)更新UI伟叛，UI的改變也能自動(dòng)反饋到數(shù)據(jù)層私痹，數(shù)據(jù)成為主導(dǎo)因素。這樣MVVM層在業(yè)務(wù)邏輯處理中只要關(guān)心數(shù)據(jù)，不需要直接和UI打交道紊遵，在業(yè)務(wù)處理過程中簡單方便很多账千。
- 高度解耦
MVVM模式中，數(shù)據(jù)是獨(dú)立于UI的暗膜。
數(shù)據(jù)和業(yè)務(wù)邏輯處于一個(gè)獨(dú)立的ViewModel中匀奏，ViewModel只需要關(guān)注數(shù)據(jù)和業(yè)務(wù)邏輯，不需要和UI或者控件打交道学搜。UI想怎么處理數(shù)據(jù)都由UI自己決定娃善，ViewModel不涉及任何和UI相關(guān)的事，也不持有UI控件的引用瑞佩。即便是控件改變了（比如：TextView換成EditText）聚磺，ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel炬丸，解決了上面我們所說的MVP的痛點(diǎn)瘫寝。
- 可復(fù)用、易測試稠炬、方便協(xié)同開發(fā)
一個(gè)ViewModel可以復(fù)用到多個(gè)View中矢沿。同樣的一份數(shù)據(jù)，可以提供給不同的UI去做展示酸纲。對于版本迭代中頻繁的UI改動(dòng)，更新或新增一套View即可瑟匆。如果想在UI上做A/B Testing闽坡，那MVVM是你不二選擇。
MVVM的分工是非常明顯的愁溜，由于View和ViewModel之間是松散耦合的：一個(gè)是處理業(yè)務(wù)和數(shù)據(jù)疾嗅、一個(gè)是專門的UI處理。所以冕象，完全由兩個(gè)人分工來做代承，一個(gè)做UI（XML和Activity）一個(gè)寫ViewModel，效率更高
ViewModel層做的事是數(shù)據(jù)處理和業(yè)務(wù)邏輯渐扮，View層中關(guān)注的是UI论悴，兩者完全沒有依賴。不管是UI的單元測試還是業(yè)務(wù)邏輯的單元測試墓律，都是低耦合的膀估。在MVVM中數(shù)據(jù)是直接綁定到UI控件上的（部分?jǐn)?shù)據(jù)是可以直接反映出UI上的內(nèi)容），那么我們就可以直接通過修改綁定的數(shù)據(jù)源來間接做一些Android UI上的測試耻讽。
Android Architecture Components(架構(gòu)組件)
實(shí)現(xiàn)MVVM的方式和工具有很多察纯，既可以使用Google在2015年推出的DataBinding庫，亦或是其他。也可以選擇Google IO 2017 推出的Android Architecture Components即架構(gòu)組件饼记，這也是本文所采用的解決方案香伴。
包含以下組件：
- 生命周期管理庫 - Lifecycle
- Lifecycle組件，為下面兩個(gè)組件提供了生命周期感知的基礎(chǔ)
- LiveData組件具则，可觀測的即纲、可感知生命周期的數(shù)據(jù)
- ViewModel組件，不依賴于View乡洼、提供UI數(shù)據(jù)崇裁、橋接持久層、業(yè)務(wù)邏輯
- 數(shù)據(jù)持久化庫 - Room束昵，Sqlite的ORM
事實(shí)上拔稳，Architecture Components實(shí)現(xiàn)了一個(gè)比較理想化的依賴方式，自上而下锹雏，單項(xiàng)依賴巴比；VM層并不持有View層的任何引用，但卻是生命周期感知的礁遵，在新版的AS中View也不用去實(shí)現(xiàn)某些接口或繼承特定的類轻绞，AppCompatActivity已經(jīng)幫你整合了這一切。另外佣耐，關(guān)于Repository的解釋政勃，它并不是架構(gòu)組件的成員，但是Google推薦引用Repository層兼砖，來作為我們唯一的數(shù)據(jù)來源接口奸远，我們從圖中也很好理解，他的職責(zé)就是使VM層對數(shù)據(jù)來源是無感知的讽挟，包裝了數(shù)據(jù)來源懒叛，提供統(tǒng)一的API，供上層透明化的調(diào)用耽梅。
demo下期提供 到此為止薛窥。告辭
