前言

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

MVP模式

先上一張圖，然后根據(jù)實(shí)際的代碼我們來(lái)講講Google是怎么看待MVP架構(gòu)的

基類

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

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

契約類

官方事例中加如契約類來(lái)統(tǒng)一管理View和Presenter。這樣整個(gè)功能可以在契約類一目了然。老大就是老大，這一點(diǎn)還是很厲害的。事例如下：

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);
    }
}

對(duì)了，其中BaseView中含方法setPresenter，該方法作用是在將presenter實(shí)例傳入view中，其調(diào)用時(shí)機(jī)是presenter實(shí)現(xiàn)類的構(gòu)造函數(shù)中。如下

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

Activity的作用

在講這個(gè)之前，不知道大家有沒有注意到上沒圖中，F(xiàn)ragment是作為View層而Activity是作為Presenter的，有沒有想過(guò)Google為什么要推薦這樣做呢？

MVC中Activity的作用

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

MVP中View層的實(shí)現(xiàn)

至于為什么要選擇Fragment作為View層的實(shí)現(xiàn)類。我看到網(wǎng)上有這兩種說(shuō)法，第一個(gè)原因是我們把a(bǔ)ctivity作為一個(gè)全局控制類來(lái)創(chuàng)建對(duì)象，把fragment作為view，這樣兩者就能各司其職。第二個(gè)原因是因?yàn)閒ragment比較靈活，能夠方便的處理界面適配的問題

MVP 把 Activity 中的 UI 邏輯抽象成 View 接口，把業(yè)務(wù)邏輯抽象成 Presenter 接口，Model 類還是原來(lái)的 Model。

來(lái)看一段代碼就能知道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的作用是什么了。主要是作為全局的控制，負(fù)責(zé)創(chuàng)建View以及Presenter實(shí)例，并將二者聯(lián)系起來(lái)。

View層的實(shí)現(xiàn)

   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);
            }
        });
    }
}

可以看到通過(guò)setPresenter方法獲取到Presenter的實(shí)例。然后在Fragment的生命周期中調(diào)用presenter.start()方法。這樣View層只負(fù)責(zé)數(shù)據(jù)給用戶呈現(xiàn)他們看到的東西，而不去管具體是怎樣實(shí)現(xiàn)的（ps：我覺得在onResume()方法之前調(diào)用應(yīng)該都行吧，不知道是不是對(duì)的。如果有錯(cuò)，還請(qǐng)指教）

Presenter層的實(shí)現(xiàn)

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) {
        //具體實(shí)現(xiàn)就不貼了，有點(diǎn)長(zhǎng)
｝
@Override
    public void start() {
        loatPosts(CurrentPagerNum,true);
    }

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

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

在構(gòu)造方法中，Presenter將自身的事例傳遞給了View,這樣View就能調(diào)用Presenter層的方法來(lái)處理業(yè)務(wù)邏輯了。在start()方法中，處理了數(shù)據(jù)加載。

Model層的實(shí)現(xiàn)

項(xiàng)目中model層最大的特點(diǎn)是被賦予了數(shù)據(jù)獲取的職責(zé)，與我們平常model層只定義實(shí)體對(duì)象截然不同，實(shí)例中，數(shù)據(jù)的獲取、存儲(chǔ)、數(shù)據(jù)狀態(tài)變化都是model層的任務(wù)，Presenter會(huì)根據(jù)需要調(diào)用該層的數(shù)據(jù)處理邏輯并在需要時(shí)將回調(diào)傳入。這樣model、presenter、view都只處理各自的任務(wù)，此種實(shí)現(xiàn)確實(shí)是單一職責(zé)最好的詮釋。

總結(jié)

MVP的好處

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

以上就是我這段時(shí)間來(lái)對(duì)MVP的理解了。如果有錯(cuò)誤的地方，歡迎指教哦。