按照MVC的分層，Activity和Fragment（後面只說Activity）應該屬於View層，用於展示UI界面，以及接收用戶的輸入，此外還要承擔一些生命週期的工作。Activity是在Android開發中充當非常重要的角色，特別是TA的生命週期的功能，所以開發的時候我們經常把一些業務邏輯直接寫在Activity裏面，這非常直觀方便，代價就是Activity會越來越臃腫，超過1000行代碼是常有的事，而且如果是一些可以通用的業務邏輯（比如用戶登錄），寫在具體的Activity裏就意味着這個邏輯不能複用了。如果有進行代碼重構經驗的人，看到1000+行的類肯定會有所顧慮。因此，Activity不僅承擔了View的角色，還承擔了一部分的Controller角色，這樣一來V和C就耦合在一起了，雖然這樣寫方便，但是如果業務調整的話，要維護起來就難了，而且在一個臃腫的Activity類查找業務邏輯的代碼也會非常蛋疼，所以看起來有必要在Activity中，把View和Controller抽離開來，而這就是MVP模式的工作了。
1、mvp 核心思想
MVP把Activity中的UI邏輯抽象成View接口，把業務邏輯抽象成Presenter接口，Model類還是原來的Model。這就是MVP模式，現在這樣的話，Activity的工作的簡單了，只用來響應生命週期，其他工作都丟到Presenter中去完成。從上圖可以看出，Presenter是Model和View之間的橋樑，爲了讓結構變得更加簡單，View並不能直接對Model進行操作，這也是MVP與MVC最大的不同之處。
2、mvp 簡單說明
MVP 之 Model
模型這一層之中做的工作是具體業務邏輯處理的實現，都伴隨着程序中各種數據的處理，複雜一些的就明顯需要實現一個Interface來松耦合了。
MVP 之 View
視圖這一層體現的很輕薄，負責顯示數據、提供友好界面跟用戶交互就行。MVP下Activity和Fragment體現在了這一 層，Activity一般也就做加載UI視圖、設置監聽再交由Presenter處理的一些工作，所以也就需要持有相應Presenter的引用。例 如，Activity上滾動列表時隱藏或者顯示Acionbar（Toolbar），這樣的UI邏輯時也應該在這一層。另外在View上輸入的數據做一些 判斷時，例如，EditText的輸入數據，假如是簡單的非空判斷則可以作爲View層的邏輯，而當需要對EditText的數據進行更復雜的比較時，如 從數據庫獲取本地數據進行判斷時明顯需要經過Model層才能返回了，所以這些細節需要自己掂量。
MVP 之 Presenter
Presenter這一層處理着程序各種邏輯的分發，收到View層UI上的反饋命令、定時命令、系統命令等指令後分發處理邏輯交由Model層做具體的業務操作。
3、mvp 的作用
MVC、MVP、MVVM 初探（一）— 基本概念上有具體的說明，這裏再增加比較重要的一點。
把業務邏輯抽到Presenter中去，避免後臺線程引用着Activity導致Activity的資源無法被系統回收從而引起內存泄露和OOM
Android APP 發生OOM的最大原因就是出現內存泄露造成APP的內存不夠用，而造成內存泄露的兩大原因之一就是Activity泄露（Activity Leak）（另一個原因是Bitmap泄露（Bitmap Leak））。
Java一個強大的功能就是其虛擬機的內存回收機制，這個功能使得Java用戶在設計代碼的時候，不用像C++用戶那樣考慮對象的回收問題。然而，Java用戶總是喜歡隨便寫一大堆對象，然後幻想着虛擬機能幫他們處理好內存的回收工作。可是虛擬機在回收內存的時候，只會回收那些沒有被引用的對象，被引用着的對象因爲還可能會被調用，所以不能回收。
Activity是有生命週期的，用戶隨時可能切換Activity，當APP的內存不夠用的時候，系統會回收處於後臺的Activity的資源以避免OOM。
採用傳統的MV模式，一大堆異步任務和對UI的操作都放在Activity裏面，比如你可能從網絡下載一張圖片，在下載成功的回調裏把圖片加載到 Activity 的 ImageView 裏面，所以異步任務保留着對Activity的引用。這樣一來，即使Activity已經被切換到後臺（onDestroy已經執行），這些異步任務仍然保留着對Activity實例的引用，所以系統就無法回收這個Activity實例了，結果就是Activity Leak。Android的組件中，Activity對象往往是在堆（Java Heap）裏佔最多內存的，所以系統會優先回收Activity對象，如果有Activity Leak，APP很容易因爲內存不夠而OOM。
採用MVP模式，只要在當前的Activity的onDestroy裏，分離異步任務對Activity的引用，就能避免 Activity Leak。
4、mvp 代碼實例
4.1 分層結構
4.2 代碼實例
view 層的實現，要實現P 層對應的回調接口和控制器（mLoginHelper）
P 層的實現，自定義業務邏輯相關的接口，以及helper 具體的業務邏輯的實現
model 層的實現，定義bean
view 層的調用，以及注意事項
5、總結
mvp 比較麻煩的就是需要定義各種view 的接口和對於的presenter。但是這也有一個好處就是代碼看起來比較清晰，至少activity 裏面基本就是相關的ui 的實現，業務邏輯的處理都被放到presenter 裏面了。耦合度降低。後期再改進的時候確實很方便！
這只是我練手的一個項目，我還在改進中，涉及到網絡層的調用可能還需要另外的寫presenter 調用對於的方法實現。還有model 我沒有用到，直接是sharepreference 進行處理，下面會繼續改進和優化。