MVP是一種使用廣泛的基礎(chǔ)架構(gòu)模式，使用基于事件驅(qū)動(dòng)的應(yīng)用框架。中培偉業(yè)《Android APP開(kāi)發(fā)架構(gòu)應(yīng)用實(shí)戰(zhàn)培訓(xùn)》專(zhuān)家劉老師詳細(xì)介紹了Android系統(tǒng)中的MVP架構(gòu)。

MVP框架思路的由來(lái)

在App開(kāi)發(fā)過(guò)程中，經(jīng)常出現(xiàn)的問(wèn)題就是某一部分的代碼量過(guò)大，雖然做了模塊劃分和接口隔離，但也很難完全避免。從實(shí)踐中看到，這更多的出現(xiàn)在UI部分，也就是Activity里。我曾見(jiàn)過(guò)2000+行以上基本不帶注釋的Activity，那時(shí)我的第一反應(yīng)就是想吐。Activity內(nèi)容過(guò)多的原因其實(shí)很好解釋?zhuān)驗(yàn)锳ctivity本身需要擔(dān)負(fù)與用戶之間的操作交互，再加上現(xiàn)在大部分的Activity還對(duì)整個(gè)App起到控制器的作用，這又帶入了大量的邏輯代碼，造成Activity的臃腫。為了解決這個(gè)問(wèn)題，我們引入了MVP框架思路。

MVP架構(gòu)的概念

MVP是一種使用廣泛的基礎(chǔ)架構(gòu)模式，使用基于事件驅(qū)動(dòng)的應(yīng)用框架。MVP從更早的MVC框架演變過(guò)來(lái)的一種框架，與MVC有一定的相似性。MVP框架由3部分組成：View負(fù)責(zé)顯示，Presenter負(fù)責(zé)邏輯處理，Model提供數(shù)據(jù)。MVP與MVC之間最主要的區(qū)別在控制層上，在MVP框架中，View與Model并不直接交互，所有的交互放在Presenter中；而在MVC里，View與Model會(huì)直接產(chǎn)生一定的交互。MVP的Presenter是框架的控制者，承擔(dān)了大量的邏輯操作，而MVC的Controller更多時(shí)候承擔(dān)一種轉(zhuǎn)發(fā)的作用。因此在App中引入MVP的原因，是為了將此前在Activty中包含的大量邏輯操作放到控制層中，避免Activity的臃腫。MVP的變種有很多，其中使用最廣泛的是Passive View模式，即被動(dòng)視圖。在這種模式下，整個(gè)框架內(nèi)部模塊之間的邏輯操作均由Presenter控制，View僅僅是整個(gè)操作的匯報(bào)者和結(jié)果接收者，Model根據(jù)Presenter的單向調(diào)用返回?cái)?shù)據(jù)(圖片來(lái)自網(wǎng)絡(luò))。并且MVP模式使得View與Model的耦合性更低，降低了Presenter對(duì)View的依賴(lài)，實(shí)現(xiàn)了關(guān)注點(diǎn)分離的初衷，方便開(kāi)發(fā)人員的編碼和測(cè)試工作。

具體到Android App中，我一般將App根據(jù)程序的結(jié)構(gòu)進(jìn)行縱向劃分，對(duì)應(yīng)MVP分別為模型層，UI層和邏輯層。UI層一般包括Activity，F(xiàn)ragment，Adapter等直接和UI相關(guān)的類(lèi)，UI層的Activity在啟動(dòng)之后實(shí)例化相應(yīng)的Presenter，App的控制權(quán)后移，由UI轉(zhuǎn)移到Presenter，兩者之間的通信通過(guò)BroadCast、Handler或者接口完成，只傳遞事件和結(jié)果。舉個(gè)簡(jiǎn)單的例子，UI層通知邏輯層（Presenter）用戶點(diǎn)擊了一個(gè)Button，邏輯層（Presenter）自己決定應(yīng)該用什么行為進(jìn)行響應(yīng)，該找哪個(gè)模型（Model）去做這件事，最后邏輯層（Presenter）將完成的結(jié)果更新到UI層。

MVP架構(gòu)本身存在的問(wèn)題

轉(zhuǎn)移邏輯操作之后可能部分較為復(fù)雜的Activity內(nèi)代碼量還是不少，于是在分層的基礎(chǔ)上再加入模板方法（Template Method）。具體做法是在Activity內(nèi)部分層。其中最頂層為BaseActivity，不做具體顯示，而是提供一些基礎(chǔ)樣式，Dialog，ActionBar在內(nèi)的內(nèi)容，展現(xiàn)給用戶的Activity繼承BaseActivity，重寫(xiě)B(tài)aseActivity預(yù)留的方法。如有必要再進(jìn)行二次繼承，App中Activity之間的繼承次數(shù)最多不超過(guò)3次。

模型層（Model）中的整體代碼量是最大的，一般由大量的Package組成，針對(duì)這部分需要做的就是在程序設(shè)計(jì)的過(guò)程中，做好模塊的劃分，進(jìn)行接口隔離，在內(nèi)部進(jìn)行分層。

強(qiáng)化Presenter的作用，將所有邏輯操作都放在Presenter內(nèi)也容易造成Presenter內(nèi)的代碼量過(guò)大，對(duì)于這點(diǎn)，我的方法是在UI層和Presenter之間設(shè)置中介者M(jìn)ediator，將例如數(shù)據(jù)校驗(yàn)、組裝在內(nèi)的輕量級(jí)邏輯操作放在Mediator中；在Presenter和Model之間使用代理Proxy；通過(guò)上述兩者分擔(dān)一部分Presenter的邏輯操作，但整體框架的控制權(quán)還是在Presenter手中。Mediator和Proxy不是必須的，只在Presenter負(fù)擔(dān)過(guò)大時(shí)才建議使用。