MVP設計模式
在Android項目中，Activity和Fragment占據了大部分的開發工作。如果有一種設計模式（或者說代碼結構）專門是為優化Activity和Fragment的代碼而產生的，你說這種模式重要不？這就是MVP設計模式。
按照MVC的分層，Activity和Fragment（后面只說Activity）應該屬於View層，用於展示UI界面，以及接收用戶的輸入，此外還要承擔一些生命周期的工作。Activity是在Android開發中充當非常重要的角色，特別是TA的生命周期的功能，所以開發的時候我們經常把一些業務邏輯直接寫在Activity里面，這非常直觀方便，代價就是Activity會越來越臃腫，超過1000行代碼是常有的事，而且如果是一些可以通用的業務邏輯（比如用戶登錄），寫在具體的Activity里就意味着這個邏輯不能復用了。如果有進行代碼重構經驗的人，看到1000+行的類肯定會有所顧慮。因此，Activity不僅承擔了View的角色，還承擔了一部分的Controller角色，這樣一來V和C就耦合在一起了，雖然這樣寫方便，但是如果業務調整的話，要維護起來就難了，而且在一個臃腫的Activity類查找業務邏輯的代碼也會非常蛋疼，所以看起來有必要在Activity中，把View和Controller抽離開來，而這就是MVP模式的工作了。
MVP模式的核心思想
MVP把Activity中的UI邏輯抽象成View接口，把業務邏輯抽象成Presenter接口，Model類還是原來的Model。
這就是MVP模式，現在這樣的話，Activity的工作的簡單了，只用來響應生命周期，其他工作都丟到Presenter中去完成。從上圖可以看出，Presenter是Model和View之間的橋梁，為了讓結構變得更加簡單，View並不能直接對Model進行操作，這也是MVP與MVC最大的不同之處。
MVC模式的作用：
- 分離了視圖邏輯和業務邏輯，降低了耦合
- Activity只處理生命周期的任務，代碼變得更加簡潔
- 視圖邏輯和業務邏輯分別抽象到了View和Presenter的接口中去，提高代碼的可閱讀性
- 把業務邏輯抽到Presenter中去，避免后台線程引用着Activity導致Activity的資源無法被系統回收從而引起內存泄露和OOM
- Presenter被抽象成接口，可以有多種具體的實現，所以方便進行單元測試
MVC模式的使用：
上面一張簡單的MVP模式的UML圖，從圖中可以看出，使用MVP，至少需要經歷以下步驟：
- 創建IPresenter接口，把所有業務邏輯的接口都放在這里，並創建它的實現PresenterCompl（在這里可以方便地查看業務功能，由於接口可以有多種實現所以也方便寫單元測試）
- 創建IView接口，把所有視圖邏輯的接口都放在這里，其實現類是當前的Activity/Fragment
- 由UML圖可以看出，Activity里包含了一個IPresenter，而PresenterCompl里又包含了一個IView並且依賴了Model。Activity里只保留對IPresenter的調用，其它工作全部留到PresenterCompl中實現
- Model並不是必須有的，但是一定會有View和Presenter
通過上面的介紹，MVP的主要特點就是把Activity里的許多邏輯都抽離到View和Presenter接口中去，並由具體的實現類來完成。這種寫法多了許多IView和IPresenter的接口，在某種程度上加大了開發的工作量，剛開始使用MVP的小伙伴可能會覺得這種寫法比較別扭，而且難以記住。其實一開始想太多也沒有什么卵用，只要在具體項目中多寫幾次，就能熟悉MVP模式的寫法，理解TA的意圖，以及享♂受其帶來的好處。