#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交互的中間紐帶，處理與用戶交互的負責邏輯。