畅享博客 > 学习的小窝 > [分享]可能有的同学会问,为什么要写一个 MVPView 的接口
2018/7/1 21:23:20

[分享]可能有的同学会问,为什么要写一个 MVPView 的接口

什么是 MVP

MVP 全称:Model-View-Presenter ;MVP 是从经典的模式 MVC 演变而来,它们的基本思想有相通的地方:Controller/Presenter 负责逻辑的处理,Model 提供数据,View 负责显示。

为什么要使用 MVP

在讨论为什么要使用 MVP 架构之前,我们首先要了解传统的 MVC 的架构的特点及其缺点。

首先看一下 MVC 架构的模型图,如下

mvc

这个图很简单,当 View 需要更新时,首先去找 Controller,然后 Controller 找 Model 获取数据,Model 获取到数据之后直接更新 View。

在 MVC 里,View 是可以直接访问 Model 的。从而,View 里会包含 Model 信息,不可避免的还要包括一些业务逻辑。 在 MVC 模型里,更关注的 Model 的不变,而同时有多个对 Model 的不同显示,即 View。所以,在 MVC 模型里,Model 不依赖于 View,但是View 是依赖于 Model 的。不仅如此,因为有一些业务逻辑在 View 里实现了,导致要更改 View 也是比较困难的,至少那些业务逻辑是无法重用的。

编者按:大多数情况下,View和Model都不会直接交互,而是通过Controller来间接交互。

这样说可能会有点抽象,下面通过一个简单的例子来说明。

假设现在有这样一个需求,Activity 中有一个 Button 和一个 TextView,点击 Button 时会请求网络获取一段字符串,然后把字符串显示在 TextView 中,按照正常的逻辑,代码应该这么写

public class MVCActivity extends AppCompatActivity {

    private Button button;
    private TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        button = findViewById(R.id.button);
        textView = findViewById(R.id.text_view);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                new HttpModel(textView).request();
            }
        });
    }
}



public class HttpModel {
    private TextView textView;

    public HttpModel(TextView textView) {
        this.textView = textView;
    }

    private Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            textView.setText((String) msg.obj);
        }
    };

    public void request() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(2000);
                    Message msg = handler.obtainMessage();
                    msg.obj = "从网络获取到的数据";
                    handler.sendMessage(msg);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53

代码很简单,当点击 Button 的时候,创建一个 HttpModel 对象,并把 TextView 对象作为参数传入,然后调用它的 request 方法来请求数据,当请求到数据之后,切换到主线程中更新 TextView,流程完全符合上面的 MVC 架构图。

但是这里有个问题,首先很显然,HttpModel 就是 Model 层,那么 View 层和 Controller 层呢,我们分析一下 View 层和 Model 层分别干了什么事,在本例中,View 层主要做的事就是当获取到网络数据的时候,更新 TextView,Controller 层主要做的事就是创建 HttpModel 对象并调用它的 request 方法,我们发现 MVCActivity 同时充当了 View 层和 Controller 层。

这样会造成两个问题,第一,View 层和 Controller 层没有分离,逻辑比较混乱;第二,同样因为 View 和 Controller 层的耦合,导致 Activity 或者 Fragment 很臃肿,代码量很大。由于本例比较简单,所以这两个问题都不是很明显,如果 Activity 中的业务量很大,那么问题就会体现出来,开发和维护的成本会很高。

如何使用 MVP

既然 MVC 有这些问题,那么应该如何改进呢,答案就是使用 MVP 的架构,关于 MVP 架构的定义前面已经说了,下面看一下它的模型图

mvp

这个图也很简单,当 View 需要更新数据时,首先去找 Presenter,然后 Presenter 去找 Model 请求数据,Model 获取到数据之后通知 Presenter,Presenter 再通知 View 更新数据,这样 Model 和 View 就不会直接交互了,所有的交互都由 Presenter 进行,Presenter 充当了桥梁的角色。很显然,Presenter 必须同时持有 View 和 Model 的对象的引用,才能在它们之间进行通信。

接下来用 MVP 的架构来改造上面的例子,代码如下

interface MVPView {
    void updateTv(String text);
}


public class MVPActivity extends AppCompatActivity implements MVPView {
    private Button button;
    private TextView textView;
    private Presenter presenter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_test);
        button = findViewById(R.id.button);
        textView = findViewById(R.id.text_view);
        presenter = new Presenter(this);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                presenter.request();
            }
        });
    }

    @Override
    public void updateTv(String text) {
        textView.setText(text);
    }
}


interface Callback {
    void onResult(String text);
}


public class HttpModel {
    private Callback callback;

    public HttpModel(Callback callback) {
        this.callback = callback;
    }

    private Handler handler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            callback.onResult((String) msg.obj);
        }
    };

    public void request() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(2000);
                    Message msg = handler.obtainMessage();
                    msg.obj = "从网络获取到的数据";
                    handler.sendMessage(msg);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}


public class Presenter {
    private MVPView view;
    private HttpModel model;

    public Presenter(MVPView view) {
        this.view = view;
        model = new HttpModel(new Callback() {
            @Override
            public void onResult(String text) {
                Presenter.this.view.updateTv(text);
            }
        });
    }

    public void request() {
        model.request();
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88

简单解释一下上面的代码,首先创建一个 MVPView 的接口,它即时 View 层,里面有一个更新 TextView 的方法,然后让 Activity 实现这个接口,并复写更新 TextView 的方法。Model 层不再传入 TextView 了,而是传入一个回调接口 Callback,因为网络请求获取数据是异步的,在获取到数据之后需要通过 Callback 来通知 Presenter。Presenter 也很简单,首先在它的构造方法中,同时持有 View 和 Model 的引用,再对外提供一个 request 方法。

分析一下上面代码执行的流程,当点击 Button 的时候,Presenter 调用 request 方法,在它的内部,通过 Model 调用 request 方法来请求数据,请求到数据之后,切换到主线程,调用 callback 的 onResult 方法来通知 Presenter,这时候 Presenter 就会调用 View 的 updateTv 方法来更新 TextView,完成了整个流程,可以发现,在整个过程从,View 和 Model 并没有直接交互,所有的交互都是在 Presenter 中进行的。

注意事项

接口的必要性  可能有的同学会问,为什么要写一个 MVPView 的接口,直接把 Activity 本身传入到 Presenter 不行吗?这当然是可行的,这里使用接口主要是为了代码的复用,试想一下,如果直接传入 Activity,那么这个 Presenter 就只能为这一个 Activity 服务。举个例子,假设有个 App 已经开发完成了,可以在手机上正常使用,现在要求做平板上的适配,在平板上的界面显示效果有所变化,TextView 并不是直接在 Activity 中的,而是在 Fragment 里面,如果没有使用 View 的接口的话,那就需要再写一个针对 Fragment 的 Presenter,然后把整个过程再来一遍。但是使用 View 的接口就很简单了,直接让 Fragment 实现这个接口,然后复写接口里面的方法,Presenter 和 Model 层都不需要做任何改动。同理,Model 层也可以采用接口的方式来写。

防止内存泄漏  其实上面的代码存在内存泄漏的风险。试想一下,如果在点击 Button 之后,Model 获取到数据之前,退出了 Activity,此时由于 Activity 被 Presenter 引用,而 Presenter 正在进行耗时操作,会导致 Activity 的对象无法被回收,造成了内存泄漏,解决的方式很简单,在 Activity 退出的时候,把 Presenter 对中 View 的引用置为空即可。

// Presenter.java
public void detachView() {
    view = null;
}

// MVPActivity.java
@Override
protected void onDestroy() {
    super.onDestroy();
    presenter.detachView();
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

另外还有一个问题,虽然这里 Activity 不会内存泄漏了,但是当 Activity 退出之后,Model 中请求数据就没有意义了,所以还应该在 detachView 方法中,把 Handler 的任务取消,避免造成资源浪费,这个比较简单,就不贴代码了。

MVP 的封装

很显然,MVP 的实现套路是大致相同的,如果在一个应用中,存在大量的 Activity 和 Fragment,并且都使用 MVP 的架构,那么难免会有很多重复工作,所以封装就很有必要性了。

在说 MVP 的封装之前,需要强调一点,MVP 更多的是一种思想,而不是一种模式,每个开发者都可以按照自己的思路来实现具有个性化的 MVP,所以不同的人写出的 MVP 可能会有一些差别,笔者在此仅提供一种实现思路,供读者参考。

首先 Model、View 和 Presenter 都可能会有一些通用性的操作,所以可以分别定义三个对应的底层接口。

interface BaseModel {
}

interface BaseView {
    void showError(String msg);
}

public abstract class BasePresenter<V extends BaseView, M extends BaseModel> {
    protected V view;
    protected M model;

    public BasePresenter() {
        model = createModel();
    }

    void attachView(V view) {
        this.view = view;
    }

    void detachView() {
        this.view = null;
    }

    abstract M createModel();
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25

这里的 View 层添加了一个通用的方法,显示错误信息,写在接口层,可以在实现处按照需求来显示,比如有的地方可能会是弹出一个 Toast,或者有的地方需要将错误信息显示在 TextView 中,Model 层也可以根据需要添加通用的方法,重点来看一下 Presenter 层。

这里的 BasePresenter 采用了泛型,为什么要这么做呢?主要是因为 Presenter 必须同时持有 View 和 Model 的引用,但是在底层接口中无法确定他们的类型,只能确定他们是 BaseView 和 BaseModel 的子类,所以采用泛型的方式来引用,就巧妙的解决了这个问题,在 BasePresenter 的子类中只要定义好 View 和 Model 的类型,就会自动引用他们的对象了。Presenter 中的通用的方法主要就是 attachView 和 detachView,分别用于创建 View 对象和把 View 的对象置位空,前面已经说过,置空是为了防止内存泄漏,Model 的对象可以在 Presenter 的构造方法中创建。另外,这里的 Presenter 也可以写成接口的形式,读者可以按照自己的喜好来选择。



评论

您还未登录,不能对文章发表评论!请先登录