MVC的缺點

在Android開發中，Activity並不是一個標準的MVC模式中的Controller，它的首要職責是加載應用的佈局和初始化用户 界面，並接受並處理來自用户的操作請求，進而作出響應。隨着界面及其邏輯的複雜度不斷提升，Activity類的職責不斷增加，以致變得龐大臃腫。

什麼是MVP?

MVP從更早的MVC框架演變過來，與MVC有一定的相似性：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。

MVP框架由3部分組成：View負責顯示，Presenter負責邏輯處理，Model提供數據。在MVP模式裏通常包含3個要素（加上View interface是4個）：

• View:負責繪製UI元素、與用户進行交互(在Android中體現為Activity)
• Model:負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合)
• Presenter:作為View與Model交互的中間紐帶，處理與用户交互的負責邏輯。
• *View interface:需要View實現的接口，View通過View interface與Presenter進行交互，降低耦合，方便進行單元測試

MVC → MVP

當我們將Activity複雜的邏輯處理移至另外的一個類（Presenter）中時，Activity其實就是MVP模式中的View，它負責UI元素的初始化，建立UI元素與Presenter的關聯（Listener之類），同時自己也會處理一些簡單的邏輯（複雜的邏輯交由 Presenter處理）。

MVP的Presenter是框架的控制者，承擔了大量的邏輯操作，而MVC的Controller更多時候承擔一種轉發的作用。因此在App中引入MVP的原因，是為了將此前在Activty中包含的大量邏輯操作放到控制層中，避免Activity的臃腫。

兩種模式的主要區別：

• （最主要區別）View與Model並不直接交互，而是通過與Presenter交互來與Model間接交互。而在MVC中View可以與Model直接交互
• 通常View與Presenter是一對一的，但複雜的View可能綁定多個Presenter來處理邏輯。而Controller是基於行為的，並且可以被多個View共享，Controller可以負責決定顯示哪個View
• Presenter與View的交互是通過接口來進行的，更有利於添加單元測試。

因此我們可以發現MVP的優點如下：

1、模型與視圖完全分離，我們可以修改視圖而不影響模型；

2、可以更高效地使用模型，因為所有的交互都發生在一個地方——Presenter內部；

3、我們可以將一個Presenter用於多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁；

4、如果我們把邏輯放在Presenter中，那麼我們就可以脱離用户接口來測試這些邏輯（單元測試）。

MVP架構存在的問題與解決辦法

• 加入模板方法（Template Method）

轉移邏輯操作之後可能部分較為複雜的Activity內代碼量還是不少，於是需要在分層的基礎上再加入模板方法（Template Method）。

具體做法是在Activity內部分層。其中最頂層為BaseActivity，不做具體顯示，而是提供一些基礎樣式，Dialog，ActionBar在內的內容，展現給用户的Activity繼承BaseActivity，重寫BaseActivity預留的方法。如有必要再進行二次繼承，App中Activity之間的繼承次數最多不超過3次。

• Model內部分層

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

• 強化Presenter

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

最終的架構如下圖所示：