MVP是一種使用廣泛的基礎架構模式，使用基于事件驅動的應用框架。中培偉業《Android APP開發架構應用實戰培訓》專家劉老師詳細介紹了Android系統中的MVP架構。

MVP框架思路的由來

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

MVP架構的概念

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

具體到Android App中，我一般將App根據程序的結構進行縱向劃分，對應MVP分別為模型層，UI層和邏輯層。UI層一般包括Activity，Fragment，Adapter等直接和UI相關的類，UI層的Activity在啟動之后實例化相應的Presenter，App的控制權后移，由UI轉移到Presenter，兩者之間的通信通過BroadCast、Handler或者接口完成，只傳遞事件和結果。舉個簡單的例子，UI層通知邏輯層（Presenter）用戶點擊了一個Button，邏輯層（Presenter）自己決定應該用什么行為進行響應，該找哪個模型（Model）去做這件事，最后邏輯層（Presenter）將完成的結果更新到UI層。

MVP架構本身存在的問題

轉移邏輯操作之后可能部分較為復雜的Activity內代碼量還是不少，于是在分層的基礎上再加入模板方法（Template Method）。具體做法是在Activity內部分層。其中最頂層為BaseActivity，不做具體顯示，而是提供一些基礎樣式，Dialog，ActionBar在內的內容，展現給用戶的Activity繼承BaseActivity，重寫BaseActivity預留的方法。如有必要再進行二次繼承，App中Activity之間的繼承次數最多不超過3次。

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

強化Presenter的作用，將所有邏輯操作都放在Presenter內也容易造成Presenter內的代碼量過大，對于這點，我的方法是在UI層和Presenter之間設置中介者Mediator，將例如數據校驗、組裝在內的輕量級邏輯操作放在Mediator中；在Presenter和Model之間使用代理Proxy；通過上述兩者分擔一部分Presenter的邏輯操作，但整體框架的控制權還是在Presenter手中。Mediator和Proxy不是必須的，只在Presenter負擔過大時才建議使用。