MVP模式解析

标签： Android 架构 MVP

MVP模式的核心思想

MVP将Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
因此，在Activity中就是响应生命周期和显示界面，其他工作，如业务逻辑等就都泡到Presenter中进行完成，Presenter其实是Model层和View的桥梁。

MVP模式需要的步骤

这里写图片描述
mvp UML图

创建IPresenter接口，将所有业务逻辑写在里面，并且创建他的实现PresenterCompl（在这里可以方便地查看业务功能，而且也方便进行单元测试）
创建IView接口，把所有的视图逻辑的接口都放这里，其实现类是当前的Activity/Fragment。
由UML图可以看出，Activity中包含了一个IPresener，而PresenterCompl又包含了一个IView并且依赖Model。Activity中保留了对IPresener的调用，其他工作全部保留到PresenterComal中实现。
Model并不是必须有的,但一定会有View和Presenter

MVP的一次简单实践

这是一个很简单的MVP实践，关于用户登录与清除的功能。
项目架构
首先看最直观的LoginActivity

public class LoginActivity extends AppCompatActivity implements ILoginView{
    @BindView(R.id.et_name)
    AppCompatEditText etName;
    @BindView(R.id.et_password)
    AppCompatEditText etPassword;
    @BindView(R.id.btn_login)
    Button btnLogin;
    @BindView(R.id.btn_clear)
    Button btnClear;

    ILoginPresenter loginPresenter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);
        ButterKnife.bind(this);

        loginPresenter = new LoginPresenterCompl(this);
    }

    @OnClick({R.id.btn_login, R.id.btn_clear})
    public void onViewClicked(View view) {
        switch (view.getId()) {
            case R.id.btn_login:
                String name = etName.getText().toString();
                String password = etPassword.getText().toString();
                loginPresenter.doLogin(name,password);
                break;
            case R.id.btn_clear:
                loginPresenter.clear();
                break;
        }
    }

    @Override
    public void onClearText() {
        etName.setText("");
        etPassword.setText("");
        ToastUtils.showShort("清除成功");
    }

    @Override
    public void onLoginResult(Boolean result, int code) {
        btnLogin.setEnabled(true);
        btnClear.setEnabled(true);
        if (result){
            ToastUtils.showShort("登录成功");
        } else{
            ToastUtils.showShort("登录失败");
        }
    }
}

界面逻辑接口 ILoginView

public interface ILoginView {
     void onClearText();
     void onLoginResult(Boolean result,int code);
}

业务逻辑接口 ILoginPresenter

public interface ILoginPresenter {
    void clear();
    void doLogin(String name,String password);
}

业务逻辑实现类 LoginPresenterCompl 实现上面的ILoginPresenter接口

public class LoginPresenterCompl implements ILoginPresenter {

    private ILoginView loginView;
    private User user;

    public LoginPresenterCompl(ILoginView view){
        loginView = view;
        user = new User("yongfeng","123123");
    }
    @Override
    public void clear() {
        loginView.onClearText();
    }

    @Override
    public void doLogin(String name, String password) {
        boolean result = false;
        int code = 0;
        if (TextUtils.equals(user.getName(),name) && TextUtils.equals(user.getPassword(),password)){
            result = true;
            code = 1;
        }else {
            result = false;
            code = 0;
        }
        loginView.onLoginResult(result,code);
    }
}

像以往那样的实体类 User

public class User {
    private String name;
    private String password;

    public User(String name, String password) {
        this.name = name;
        this.password = password;
    }

    public String getName() {
        return name == null ? "" : name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getPassword() {
        return password == null ? "" : password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    @Override
    public String toString() {
        return "User{" +
                "name='" + name + '\'' +
                ", password='" + password + '\'' +
                '}';
    }
}

总结

使用了MVP架构后，只用来显示界面，具体的业务逻辑都交由ILoginPresenter去完成（注意要new 的时候，使用ILoginPresenterCompl这个实现类），识得整个Activity看上去会很清爽，在也不用在Activity中去找业务逻辑了，而界面显示逻辑则交由ILoginView这个接口去完成。

MVP的优势

使Activity代码更整洁

在传统中的Activity中随着项目的延展，使得在Activity中的代码越来越来，项目耦合性越来越高，使得代码难以维护。后续维护时，通常找一个业务逻辑要改的地方都难。（我就维护了一个三年前的项目，看得真是头大哦）。

但使用MVP后，Activity就能瘦身许多了，基本上只有 FindView、SetListener 以及Init的代码。其他的就是对 Presenter的调用，还有对 View接口 的实现。这种情形下阅读代码就容易多了。

而且你只要看 Presenter 的接口，就能明白这个模块都有哪些业务，很快就能定位到具体代码。Activity 变得容易看懂，容易维护，以后要调整业务、删减功能也就变得简单许多。

便于单元测试

一般单元测试都是用来测试某些新加的业务逻辑有没有问题，如果采用传统的代码风格，我们可能要先在Activity里写一段测试代码，测试完了再把测试代码删掉换成正式代码，这时如果发现业务有问题又得换回测试代码，咦，测试代码已经删掉了！好吧重新写吧……

MVP 中，由于业务逻辑都在Presenter 里，我们完全可以写一个 PresenterTest 的实现类继承 Presenter 的接口，现在只要在Activity 里把 Presenter 的创建换成 PresenterTest，就能进行单元测试了，测试完再换回来即可。万一发现还得进行测试，那就再换成 PresenterTest 吧。

避免Activity内存泄漏

采用传统的模式，一大堆异步任务和对UI的操作都放在 Activity里面，比如你可能从网络下载一张图片，在下载成功的回调里把图片加载到 Activity 的 ImageView 里面，所以异步任务保留着对 Activity 的引用。

这样一来，即使 Activity 已经被切换到后台（onDestroy 已经执行），这些异步任务仍然保留着对 Activity 实例的引用，所以系统就无法回收这个 Activity 实例了，结果就是 Activity Leak。

Android 的组件中，Activity 对象往往是在堆（Java Heap）里占最多内存的，所以系统会优先回收 Activity 对象，如果有 Activity Leak，APP很容易因为内存不够而 OOM。

采用 MVP模式，只要在当前的 Activity 的 onDestroy 里，分离异步任务对Activity 的引用，就能避免 Activity Leak。

参考地址