《Android源碼設計模式解析與實戰》讀書筆記（二十六）

第二十六章、MVP應用構架模式

1.MVP介紹

MVP模式是MVC模式的一個演化版本，MVP全稱Model-View-Presenter。目前MVP在Android應用開發中越來越重要了。

在Android中，業務邏輯和數據存取是緊緊耦合的，很多缺乏經驗的開發者很可能會將各種各樣的業務邏輯塞進某個Activity、Fragment或者自定義View中，這樣會使得這些組件的單個類型臃腫不堪。如果不將具體的業務邏輯抽離出來，當UI變化時，你就需要去原來的View中抽離具體業務邏輯，這必然會很麻煩並且易出錯。

2.使用MVP的好處

（1）MVP模式會解除View與Model的耦合，有效的降低View的復雜性。同時又帶來了良好的可擴展性、可測試性，保證系統的整潔性和靈活性。

（2）MVP模式可以分離顯示層與邏輯層，它們之間通過接口進行通信，降低耦合。理想化的MVP模式可以實現同一份邏輯代碼搭配不同的顯示界面，因為它們之間並不依賴與具體，而是依賴於抽象。這使得Presenter可以運用於任何實現了View邏輯接口的UI，使之具有更廣泛的適用性，保證了靈活度。

3.MVP模式的三個角色

（1）Presenter – 交互中間人：Presenter主要作為溝通View與Model的橋梁，它從Model層檢索數據後，返回給View層，使得View與Model之間沒有耦合，也將業務邏輯從View角色上抽離出來。

（2）View – 用戶界面：View通常是指Activity、Fragment或者某個View控件，它含有一個Presenter成員變量。通常View需要實現一個邏輯接口，將View上的操作轉交給Presenter進行實現，最後，Presenter 調用View邏輯接口將結果返回給View元素。

（3）Model – 數據的存取：Model 角色主要是提供數據的存取功能。Presenter 需要通過Model層存儲、獲取數據，Model就像一個數據倉庫。更直白的說，Model是封裝了數據庫DAO或者網絡獲取數據的角色，或者兩種數據方式獲取的集合。

4.與MVC、MVVM的區別

1.與MVC的區別

從上圖可以看出：MVC的耦合性還是較高的，View可以直接訪問Model，導致3者之間構成了回路。所以兩者的主要區別是，MVP中View不能直接訪問Model，需要通過Presenter發出請求，View與Model不能直接通信。

2.與MVVM（Model-View-ViewModel）的區別

MVVM與MVP非常相似，唯一區別是View和Model進行雙向綁定，兩者之間有一方發生變化則會反應到另一方上。MVVM模式有點像ListView與Adapter、數據集的關系，當數據集發生變化時，調用Adapter的notifyDataSetChanged之後View就直接更新，同時它們之間又沒有耦合，使得ListView變得更加靈活。

5.MVP簡單實現

可以參考：

1. androidmvp

2. archi

6.MVP 與Activity、Fragment的生命周期

由於Presenter 經常性的持有Activity 的強引用，如果在一些請求結束之前Activity 被銷毀了，那麼Presenter 一直持有Activity 對象，使得Activity 對象無法回收，此時就會發生內存洩露。

那麼解決方法就是采用弱引用和Activity、Fragment的生命周期來解決這個問題。首先建立一個Presenter 抽象：

public abstract class BasePresenter {
    protected Reference mViewRef; //View接口類型的弱引用

    public void attachView(T view){
        mViewRef = new WeakReference(view); //建立關聯
    }

    protected T getView(){
        return mViewRef.get(); //獲取View
    }

    public boolean isViewAttached(){
        return mViewRef != null && mViewRef.get() != null; //判斷是否與View建立關聯
    }

    public void detachView(){
        if(mViewRef != null){
            mViewRef.clear(); //解除關聯
            mViewRef = null;
        }
    }
}

通常這個View類型應該就是實現了某個特定接口的Activity或者Fragment等類型。

創建一個MVPBaseActivity基類，通過這個基類聲明周期函數來控制它與Presenter 的關系。代碼如下：

public abstract class MVPBaseActivity> extends Activity {
     protected T mPresenter; //Presenter對象

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mPresenter = createPresenter();
        mPresenter.attachView((V)this);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mPresenter.detachView();
    }

    protected abstract T createPresenter();
}

MVPBaseActivity含有兩個泛型，一個是View的接口類型，一個是Presenter的具體類型。

7.參考

PS：到這裡《Android源碼設計模式解析與實戰》讀書筆記系列到此就結束了，這本書算算看了也有近2個月了，收獲真是非常大，以後也會抽時間再看幾遍，溫故而知新嘛！在寫這個讀書筆記的過程中，很感謝大家的支持，評論中都是鼓勵的聲音真是給我了很多的信心。最讓我激動的是這本書的作者之一何紅輝也給了我鼓勵，在這裡也是再次感謝。

前一陣看到許多的博友都有寫年度總結，看了之後我也是很有感觸。那我也簡單總結一下：其實做Android開發到現在也有一年半了，雖然稱不上是什麼高手、大神。但是工作上的問題基本也可以獨立解決（畢竟有Google~，畢竟就我一人）同時我對我的工作和學習態度是肯定的。

談談寫博客的初衷：寫博客的時間是我做開發基本1年的時候，說來寫博客也是一個機緣巧合，因為寫博客之前我會經常看一些開源的項目，就比如Github的android-open-project，那麼我每次都是先進Github在搜索android-open-project（我竟然連書簽都懶得保存！），類似的還有很多。。。終於有一天我覺得真麻煩（你是有多遲鈍），所以就把我經常用到的這些網址寫了我的第一篇博客：Android開源與干貨網站匯總，之後存一個書簽。嘗到了這種便捷的好處，就正式開始了CSDN博客之旅。

前幾天碰巧看到一位大神的博客，看了下這位大神堅持寫了近10年的博客，並且每月都有高質量的文章，涉及的知識也是方方面面的。真是震撼了我，那麼向榜樣學習，今年繼續努力，既然開始了就堅持下去。