淺談Android架構之MVP,MVVM

概述

MVP(Model-View-Presenter)是傳統MVC(Model-View-Controller)在Android開發上的一種變種、進化模式。主要用來隔離UI、UI邏輯和業務邏輯、數據,建立鬆散耦合並可重用的對象。

咱們知道View層是容易變化且多種多樣的,業務邏輯也是多種多樣的,與傳統的MVC相比,P充當了C的做用.
Model存儲數據，View表示Model的表現，Presenter協調二者之間的通訊.

然後在MVP基礎上也出現了一些變種,如MVVM,MVPVM等,相比較MVP而言,MVVM使數據綁定變得更加簡單.MVPVM在MVVM中加入引入Presenter層

MVC,MVP,MVVM,MVPVM圖解

這裏感謝源博客和圖片提供者.

MVC:

MVC中View接受事件,並調用Controller來操做Model,同時,當Model實例的數據發生變化後，Controller再更新界面(固然View也能夠直接更新Model)。

在傳統的開發中Activity儼然既充當了Controller又充當了View的做用.既須要接受用戶響應操做Model,又要更新界面.
這樣作有一個好處就是數據的更新變得很簡單,可是缺點也十分明顯,Activity是非臃腫,後期很差維護.

MVP:

MVP中將業務邏輯單獨抽出Presenter,View層變成一個被動的東西,Presenter負責完成View層與Model層的交互.
View 不能夠直接和Model交互(MVC中容許Model和View交互),只有Presenter告知其更新，它纔會去更新.
並且Presenter和View的交互是經過接口來完成.

MVVM:

MVVM在Android上對應data binding,MVVM最早使用在WPF中,經過ViewModel和View的映射,完成了View和Model的雙向綁定.
View的事件直接傳遞到ViewModel，ViewModel去對Model進行操做並接受更新.進而反饋到View上.
由於ViewModel與View的耦合,MVVM有一個缺點就是View的複用問題,
由於去掉了Presenter,View層依然太重.

MVPVM:

MVPVM是MVP和MVVM的演化版本,下降了ViewModel與View的耦合,View只須要實現ViewModel的觀察者接口實現更新.ViewModel再也不對Model直接進行操做,而是交給了Presenter.Presenter操做Model並反饋到ViewModel上
Model,View,ViewModel之間經過Presenter聯繫了起來.

MVP實踐

Google官方android-architecture無疑是學習MVP最佳資料,官方項目展現了經過不一樣方式來實現MVP,其中展現了經過basic,loaders,data binding,clean,dagger,content provider,rxjava等不一樣方式來實現相同的功能,固然咱們只要掌握其精髓,舉一反三就能夠

看官方MVP的體會

• 單獨模塊抽取IContract接口管理IView和 Presenter接口,一目瞭然,並且維護也方便

public interface AddEditTaskContract {

    interface View extends BaseView<Presenter> {
//...
    }

    interface Presenter extends BasePresenter {
//...
    }
}

• 當Fragment做爲View的時候,Activity負責建立IView和Presenter實例,並將兩者關聯起來,官方的這幅圖便可說明

代碼說明:

//todo-mvp$TasksActivity
@Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       setContentView(R.layout.tasks_act);
       // ...
       TasksFragment tasksFragment =
               (TasksFragment) getSupportFragmentManager().findFragmentById(R.id.contentFrame);
       //...
       mTasksPresenter = new TasksPresenter(
               Injection.provideTasksRepository(getApplicationContext()), tasksFragment);
       //...
   }

• IPresenter由具體的Presenter實現,IView由View層(Activity/Fragment)實現,IView實現類中包含了Presenter,他們經過以下方式實現綁定.

public interface BaseView<T> {
      // View中保持對Presenter的引用。
      void setPresenter(T presenter);
}

• 同時在Presenter構造時須要傳入IView對象(用於更新View).

public class TasksPresenter implements TasksContract.Presenter {
    private final TasksRepository mTasksRepository;
    private final TasksContract.View mTasksView;
//...
    public TasksPresenter(@NonNull TasksRepository tasksRepository, @NonNull TasksContract.View tasksView) {
        mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null");
        mTasksView = checkNotNull(tasksView, "tasksView cannot be null!");
//setPresenter
        mTasksView.setPresenter(this);
    }

• Model不只僅是JavaBean,並且擁有操做數據的業務邏輯(獲取、存儲、更新),同時Model也能夠將業務抽成接口,這樣就能夠隨意拓展數據源

MVP變種

MVP架構的好處就很少說了,可是使用Activity/Fragment做爲View層有以下問題,
參考一種在android中實現MVP模式的新思路

• 當內存不足,Activity被回收後,這使得狀態的保存和恢復成爲問題,由於涉及到了Model操做.

• 生命週期的控制問題也很麻煩,須要在Presenter中寫一大堆和生命週期相關的接口規範

• Activity中包含了不少系統服務,邏輯操做方便

使用Activity/Fragment做爲Presenter

Activity/Fragment中的系統服務和業務邏輯緊密相關.理想的狀態是View不涉及到邏輯操做.

Activity/Fragment做爲Presenter,須要將其UI邏輯抽取到一個單獨的類中來管理.

UI邏輯接口

public interface Vu {
    void inflate(LayoutInflater inflater, ViewGroup container, Bundle bundle);
    View getView();
}

做爲Presenter的BaseActivity,覆蓋了全部生命週期方法

public abstract class BasePresenterActivity<V extends Vu> extends Activity {

    protected V vu;

    @Override
    protected final void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        try {
            vu = getVuClass().newInstance();
            vu.inflate(getLayoutInflater(), null,null);
            setContentView(vu.getView());
            onBindVu();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
    }

    @Override
    protected final void onDestroy() {
        onDestroyVu();
        vu = null;
        super.onDestroy();
    }

    protected abstract Class<V> getVuClass();

    protected void onBindVu(){};

    protected void onDestroyVu() {};

}

舉個例子:

具體的UI邏輯,不論Presenter變爲Activity仍是Fragment都不用改變.在週期方法中改變View對外的操做便可.

public class HelloVu implements Vu {

View view;
TextView helloView;

@Override
public void init(LayoutInflater inflater, ViewGroup container) {
    view = inflater.inflate(R.layout.hello, container, false);
    helloView = (TextView) view.findViewById(R.id.hello);
}

@Override
public View getView() {
    return view;
}

public void setHelloMessage(String msg){
    helloView.setText(msg);
}

}

具體的Presenter

public class HelloActivity extends BasePresenterActivity {
@Override
protected void onBindVu() {
    vu.setHelloMessage("Hello World!");
}

@Override
protected Class<MainVu> getVuClass() {
    return HelloVu.class;
}

}

MVVM:數據的動態綁定

官方文檔:
https://developer.android.com/topic/libraries/data-binding/index.html
使用Data Binding後,咱們的xml和以前是不太同樣的.抄襲自官方文檔

<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data>
        <variable name="user" type="com.example.User"/>
    </data>
    <LinearLayout>
    ....
    </LinearLayout>
</layout>

相應的Activity的setContentView也會變化

@Override
protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   MainActivityBinding binding = DataBindingUtil.setContentView(this, R.layout.main_activity);
   User user = new User("Test", "User");
   binding.setUser(user);
}

這裏一個JavaBean對應一個xml佈局文件,View的複用變得很困難.

TheMVP:MVVM和MVP的結合

TheMVP解決了這個問題,經過在Presenter中定義ViewModel接口,實現數據的雙向綁定與MVP的結合.
項目地址: kymjs/TheMVP

核心代碼:這裏的IDelegate至關與上面的Vu

//ViewModel接口
public interface DataBinder<T extends IDelegate, D extends IModel> {
    /**
     * 將數據與View綁定，這樣當數據改變的時候，框架就知道這個數據是和哪一個View綁定在一塊兒的，就能夠自動改變ui
     * 當數據改變的時候，會回調本方法。
     *
     * @param viewDelegate 視圖層代理
     * @param data         數據模型對象
     */
    void viewBindModel(T viewDelegate, D data);
}

Presenter:在數據改變的時候調用notifyModelChanged()更新View

public abstract class DataBindActivity<T extends IDelegate> extends
        ActivityPresenter<T> {
    protected DataBinder binder;

    public abstract DataBinder getDataBinder();

    public <D extends IModel> void notifyModelChanged(D data) {
        binder.viewBindModel(viewDelegate, data);
    }
}

MVPVM:View複用與瘦身

在MVPVM做者的介紹中.

• Model層,和MVP中的Model是相似的.即PO或者DO
• View層,依然是由Activity/Fragment來擔當,不一樣的是須要實現ViewModel的觀察者接口,來實現View的動態更新
• Presenter層,如上圖所示,Presenter做爲核心,鏈接着M,V,VM
• VM層,和MVVM中的VM是相似的,只是爲了讓VM能夠重用.再也不和特定的View綁定,並且再也不直接對Model進行操做.

詳見:從零開始的Android新項目3 - MVPVM in Action, 誰告訴你MVP和MVVM是互斥的

參考:
一種在android中實現MVP模式的新思路
ANDROID MVP模式 簡單易懂的介紹方式
MVVM_Android-CleanArchitecture
從零開始的Android新項目3 - MVPVM in Action, 誰告訴你MVP和MVVM是互斥的
用MVP架構開發Android應用