Android開發為什麼要用MVP？

為什麼需要MVP

1. 儘量簡單 大部分的安卓應用只使用View-Model結構,程式設計師現在更多的是和複雜的View打交道而不是解決業務邏輯。當你在應用中只使用Model-View時，到最後，你會發現“所有的事物都被連線到一起”。複雜的任務被分成細小的任務，並且很容易解決。越小的東西，bug越少，越容易debug，更好測試。在MVP模式下的View層將會變得簡單，所以即便是他請求資料的時候也不需要回撥函式。View邏輯變成十分直接。

2. 後臺任務 當你編寫一個Actviity、Fragment、自定義View的時候，你會把所有的和後臺任務相關的方法寫在一個靜態類或者外部類中。這樣，你的Task不再和Activity聯絡在一起，這既不會導致記憶體洩露，也不依賴於Activity的重建。

優點：

1. 降低耦合度，實現了Model和View真正的完全分離，可以修改View而不影響Modle

2. 模組職責劃分明顯，層次清晰

3. 隱藏資料

4. Presenter可以複用，一個Presenter可以用於多個View，而不需要更改Presenter的邏輯（當然是在View的改動不影響業務邏輯的前提下）

5. 利於測試驅動開發。以前的Android開發是難以進行單元測試的（雖然很多Android開發者都沒有寫過測試用例，但是隨著專案變得越來越複雜，沒有測試是很難保證軟體質量的；而且近幾年來Android上的測試框架已經有了長足的發展——開始寫測試用例吧），在使用MVP的專案中Presenter對View是透過介面進行，在對Presenter進行不依賴UI環境的單元測試的時候。可以透過Mock一個View物件，這個物件只需要實現了View的介面即可。然後依賴注入到Presenter中，單元測試的時候就可以完整的測試Presenter應用邏輯的正確性。

6. View可以進行元件化。在MVP當中，View不依賴Model。這樣就可以讓View從特定的業務場景中脫離出來，可以說View可以做到對業務完全無知。它只需要提供一系列介面提供給上層操作。這樣就可以做到高度可複用的View元件。

7. 程式碼靈活性

缺點：

1. Presenter中除了應用邏輯以外，還有大量的View->Model，Model->View的手動同步邏輯，造成Presenter比較笨重，維護起來會比較困難。

2. 由於對檢視的渲染放在了Presenter中，所以檢視和Presenter的互動會過於頻繁。

3. 如果Presenter過多地渲染了檢視，往往會使得它與特定的檢視的聯絡過於緊密。一旦檢視需要變更，那麼Presenter也需要變更了。

4. 額外的程式碼複雜度及學習成本。

在MVP模式裡通常包含4個要素：

1. View :負責繪製UI元素、與使用者進行互動(在Android中體現為Activity);

2. View interface :需要View實現的介面，View透過View interface與Presenter進行互動，降低耦合，方便進行單元測試;

3. Model :負責儲存、檢索、操縱資料(有時也實現一個Model interface用來降低耦合);

4. Presenter :作為View與Model互動的中間紐帶，處理與使用者互動的負責邏輯。

原文連結：http://www.apkbus.com/blog-705730-61361.html