簡稱：MVP 全稱：Model-View-Presenter ；MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方,Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示
模式特點
1.MVP是根據MVC演變而來
3.在MVC中，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的會包括一些業(yè)務邏輯。 在MVC模型里，更關注的Model的改變，而同時有多個對Model的不同顯示，即View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因為有一些業(yè)務邏輯在View里實現了，導致要更改View也是比較困難的，至少有些業(yè)務邏輯是無法重用的。
2.在MVP中 : View并不直接使用Model，它們之間的通信是通過Presenter (也就是MVC中的Controller)來進行的，所有的交互都發(fā)生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過 Controller。
總結:
雖然 MVC 中的 View可以訪問 Model，但是我們不建議在 View 中依賴 Model，而是要求盡可能把所有業(yè)務邏輯都放在 Controller 中處理，而 View只和 Controller 交互。
解決方式:
在MVP里，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現。而且，Presenter與具體的View是沒有直接關聯(lián)的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，即重用！ 不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實現對Presenter的測試--而不需要使用自動化的測試工具。 我們甚至可以在Model和View都沒有完成時候，就可以通過編寫Mock Object（即實現了Model和View的接口，但沒有具體的內容的）來測試Presenter的邏輯。 在MVP里，應用程序的邏輯主要在Presenter里實現，其中的View是很薄的一層。因此就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發(fā)Presenter。在這個過程中，View是很簡單的，能夠把信息顯示清楚就可以了。在后面，根據需要再隨便更改View，而對Presenter沒有任何的影響了。 如果要實現的UI比較復雜，而且相關的顯示邏輯還跟Model有關系，就可以在View和Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯(lián)。而同時，因為Adapter實現了View的接口，從而可以保證與Presenter之間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。 在MVP模式里，View只應該有簡單的Set/Get的方法，用戶輸入和設置界面顯示的內容，除此就不應該有更多的內容，絕不容許直接訪問Model,這就是與MVC很大的不同之處。
優(yōu)點:
1.分離了視圖邏輯和業(yè)務邏輯，降低了耦合
2.Activity 只處理生命周期的任務，代碼變得更加簡潔
3.視圖邏輯和業(yè)務邏輯分別抽象到了 View 和 Presenter 的接口中去，提高代碼的可閱讀性
4.Presenter 被抽象成接口，可以有多種具體的實現，所以方便進行單元測試
5.把業(yè)務邏輯抽到 Presenter 中去，避免后臺線程引用著 Activity 導致 Activity 的資源無法被系統(tǒng)回收從而引起內存泄露和 OOM
缺點:
由于對視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會過于頻繁。還有一點需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯(lián)系過于緊密。一旦視圖需要變更，那么Presenter也需要變更了。比如說，原本用來呈現Html的Presenter現在也需要用于呈現Pdf了，那么視圖很有可能也需要變更。
下面請看代碼實現:
一、不使用MVP的代碼
下面開始采用最簡單的MVP模式來改造這個代碼:
1.創(chuàng)建一個類,用來封裝網絡請求(M層)
2.先定義一個接口，針對這個界面邏輯View需要作出的動作。
3.再創(chuàng)建一個類，用來處理M層和V層之間的通信，(P層)
4、讓Activity實現這個接口中的方法(V層)
上面這4步是最基本的MVP模式,但是這樣寫會內存泄漏,因為如果在網絡請求的過程中Activity關閉了，Presenter還持有V層的引用.
解決:
在Presenter添加綁定和解綁方法,斷開網絡方法:
修改后的activity:
這樣我們就解決了內存泄露的問題，但是這樣還是不完美，應用中肯定不可能只有一個模塊，每個模塊都對應著一個V層和P層，那這樣的話每個Presenter中都要定義綁定和解綁的方法，而Activity中對應的也要調用這綁定和解綁的兩個方法，代碼冗余。
解決:
1.創(chuàng)建一個基類View，讓所有View接口都必須實現,用來約束類型的
2.創(chuàng)建一個基類Presenter，在類上規(guī)定View泛型，然后定義綁定和解綁的抽象方法，讓子類去實現，對外在提供一個獲取View的方法，
讓子類直接通過方法來獲取View
3.創(chuàng)建一個基類的Activity，聲明一個創(chuàng)建Presenter的抽象方法，因為要幫子類去綁定和解綁那么就需要拿到子類的Presenter才行，但是又不能隨便一個類都能綁定的，因為只有基類的Presenter中才定義了綁定和解綁的方法，所以同樣的在類上可以聲明泛型,在方法上使用泛型來達到目的。
4.修改Presenter和Activity中的代碼，各自繼承自己的基類并去除重復代碼
待續(xù)!
