前言

最進想做了一個新的小項目，總想來點對自己來說新鮮的東西。后面看到Google老大推薦使用MVP架構，頓時覺得不試試看都不好說是羨慕它的小弟了。良心大哥也專門在Github推出了一個項目Android Architecture Blueprints，用來展示Android用各種的MVP框架，也能算了官網教程了。在網絡收集資料看了一下大神們的分析后，自己動手試了試。那么就馬上上手來看一看MVP究竟如何。（本文都是圍繞項目中todo-mvp部分來介紹
）

MVP模式

先上一張圖，然后根據實際的代碼我們來講講Google是怎么看待MVP架構的

基類

首先丁一兩個Base接口，分別是作為Presenter和View的基類

public interface BaseView<T> {
    // 為View設置Presenter
    void setPresenter(T presenter);
    // 初始化界面控件
    void initView(View view);
}
public interface BasePresenter {
    // 獲取數據并改變界面顯示，在todo-mvp的項目中的調用時機為Fragment的OnResume()方法中
    void start();
}

契約類

官方事例中加如契約類來統一管理View和Presenter。這樣整個功能可以在契約類一目了然。老大就是老大，這一點還是很厲害的。事例如下：

public interface YourContract {
    interface View extends BaseView<Presenter>{
        //這里加View功能方法
        void showError();
        void showLoading();
        void Stoploading();

    }
    interface Presenter extends BasePresenter{
        // 同上
        void loatPosts(int PagerNum,boolean cleaing);
        void  reflush();
        void loadMore(int PagerNum);
    }
}

對了，其中BaseView中含方法setPresenter，該方法作用是在將presenter實例傳入view中，其調用時機是presenter實現類的構造函數中。如下

public YourPresenter(Context context, YourContract.View view) {
        this.context=context;
        this.view=view;
        this.view.setPresenter(this);
    }

Activity的作用

在講這個之前，不知道大家有沒有注意到上沒圖中，Fragment是作為View層而Activity是作為Presenter的，有沒有想過Google為什么要推薦這樣做呢？

MVC中Activity的作用

按照我們之前的習慣或者說在MVC模式中，Activity是作為View層和用戶打交道，接收用戶數據的輸入和輸出的。特別是我們會在Activity的聲明周期中寫入一些邏輯來實現我們想要的效果。這樣很方便，但是后果是我們的Activity特別的臃腫，想一想如果我們一些通用的功能每個Activity里都要寫一次不是一件很痛苦的事情。
這個時候，Activity 不僅承擔了 View 的角色，還承擔了一部分的 Controller 角色，這樣一來 V 和 C 就耦合在一起了，雖然這樣寫方便，但是如果業務調整的話，要維護起來就難了，而且在一個臃腫的 Activity 類查找業務邏輯的代碼也會非常蛋疼，所以看起來有必要在 Activity 中，把 View 和 Controller 抽離開來，而這就是 MVP 模式的工作了。

MVP中View層的實現

至于為什么要選擇Fragment作為View層的實現類。我看到網上有這兩種說法，第一個原因是我們把activity作為一個全局控制類來創建對象，把fragment作為view，這樣兩者就能各司其職。第二個原因是因為fragment比較靈活，能夠方便的處理界面適配的問題

MVP 把 Activity 中的 UI 邏輯抽象成 View 接口，把業務邏輯抽象成 Presenter 接口，Model 類還是原來的 Model。

來看一段代碼就能知道Activity的作用了（畢竟代碼能夠一目了然）：

     @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        initView();
        if (savedInstanceState!=null){
            mainFragment= (MainFragment) getSupportFragmentManager().getFragment(savedInstanceState,"MainFragment");
            bookmarksfragment=(BookmarksFragment) getSupportFragmentManager().getFragment(savedInstanceState,"BookmarksFragment");
        }else {
            mainFragment=MainFragment.newInstance();
            bookmarksfragment=BookmarksFragment.newInstance();
        }
        new BookmarksPresenter(MainActivity.this,bookmarksfragment);
}

看了上面的代碼大概就能知道Activity的作用是什么了。主要是作為全局的控制，負責創建View以及Presenter實例，并將二者聯系起來。

View層的實現

   public class YourFragment extends Fragment implements YourContract.View {

    private YourContract.Presenter presenter;
    @Override
    public void onResume() {
        super.onResume();
        presenter.start();
    }
   @Override
       public void setPresenter(YourContract.Presenter presenter) {
           if (presenter!=null){
               this.presenter=presenter;
           }
       }
  @Override
    public void showError() {
        Snackbar.make(fab, R.string.loaded_failed,Snackbar.LENGTH_INDEFINITE)
                .setAction(R.string.retry, new View.OnClickListener() {
                    @Override
                    public void onClick(View v) {
                        presenter.reflush();
                    }
                })
                .show();
    }

  @Override
    public void showLoading() {
        refresh.post(new Runnable() {
            @Override
            public void run() {
                refresh.setRefreshing(true);
            }
        });
    }

    @Override
    public void Stoploading() {
        refresh.post(new Runnable() {
            @Override
            public void run() {
                refresh.setRefreshing(false);
            }
        });
    }
}

可以看到通過setPresenter方法獲取到Presenter的實例。然后在Fragment的生命周期中調用presenter.start()方法。這樣View層只負責數據給用戶呈現他們看到的東西，而不去管具體是怎樣實現的（ps：我覺得在onResume()方法之前調用應該都行吧，不知道是不是對的。如果有錯，還請指教）

Presenter層的實現

public class YourPresenter implements YourContract.Presenter {
public YourPresenter(Context context, YourContract.View view) {
        this.context=context;
        this.view=view;
        this.view.setPresenter(this);
    }

@Override
    public void loatPosts(int PagerNum, final boolean cleaing) {
        //具體實現就不貼了，有點長
｝
@Override
    public void start() {
        loatPosts(CurrentPagerNum,true);
    }

@Override
    public void reflush() {
        loatPosts(CurrentPagerNum,true);
    }

@Override
    public void loadMore(int PagerNum) {
        loatPosts(CurrentPagerNum+PagerNum,false);
    }
｝

在構造方法中，Presenter將自身的事例傳遞給了View,這樣View就能調用Presenter層的方法來處理業務邏輯了。在start()方法中，處理了數據加載。

Model層的實現

項目中model層最大的特點是被賦予了數據獲取的職責，與我們平常model層只定義實體對象截然不同，實例中，數據的獲取、存儲、數據狀態變化都是model層的任務，Presenter會根據需要調用該層的數據處理邏輯并在需要時將回調傳入。這樣model、presenter、view都只處理各自的任務，此種實現確實是單一職責最好的詮釋。

總結

MVP的好處

• 分離了視圖邏輯和業務邏輯，降低耦合度，實現了Model和View真正的完全分離，可以修改View而不影響Modle
• Activity 只處理生命周期的任務，代碼變得更加簡潔
• 視圖邏輯和業務邏輯分別抽象到了 View 和 Presenter 的接口中去，提高代碼的可閱讀性
• View可以進行組件化。在MVP當中，View不依賴Model。這樣就可以讓View從特定的業務場景中脫離出來，可以說View可以做到對業務完全無知。它只需要提供一系列接口提供給上層操作。這樣就可以做到高度可復用的View組件。
• 利于測試驅動開發。Presenter 被抽象成接口，可以有多種具體的實現，所以方便進行單元測試。在使用MVP的項目中Presenter對View是通過接口進行，在對Presenter進行不依賴UI環境的單元測試的時候。可以通過Mock一個View對象，這個對象只需要實現了View的接口即可。然后依賴注入到Presenter中，單元測試的時候就可以完整的測試Presenter應用邏輯的正確性。

以上就是我這段時間來對MVP的理解了。如果有錯誤的地方，歡迎指教哦。