MVP模式解析
标签： Android 架构 MVP
MVP模式的核心思想
MVP将Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
因此，在Activity中就是响应生命周期和显示界面，其他工作，如业务逻辑等就都泡到Presenter中进行完成，Presenter其实是Model层和View的桥梁。
MVP模式需要的步骤
[图片上传失败...(image-8e9527-1527057828991)]
- 创建
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。
