前言(原地址： https://MP.weixin.QQ.com/s/- dtuumuofzjpwsdfvenobw ) ) ) ) ) ) ) ) ) )。

随着MVP概念的兴起和发展，MVP得到了越来越广泛的应用，当然MVP的优势也得到了认可，MVP在协同开发功能模块细分中得天独厚。 本文简要介绍了MVP的使用方法。

什么是MVP

MVP是MVC的变种，其实是一种升级。 要说MVP，那就是MVC，在MVC中，Activity其实是View级别的，但在正常使用过程中，Activity既可以是View，也可以是Controller，没有将View层和Controller层分开，大大提高了耦合度，管理项目这时MVP诞生了。

MVP分为三层

模特

视图

Presenter

MVP模式的核心思想

MVP将Activity中的UI逻辑抽象到View界面，将业务逻辑抽象到Presenter界面。 模型类保持原始模型。

在MVP模式下，Activity的功能是响应生命周期和显示界面，所有其他工作都是抛弃在搭建模型层和视图层桥梁的Presenter层进行的。

具体的MVP的优点还有很多，我就不详细介绍了，让我们来看看MVP的使用方法吧。

从上面简单的MVP模式UML图中可以看出，要使用MVP，至少需要执行以下步骤：

创建IPresenter接口，将所有业务逻辑的接口放在此处，然后创建其实现PresenterCompl。 (在这里可以很容易地看到商务功能，因为界面可以安装多个，所以单元测试也很容易写。 )。

创建IView界面，并将所有视图逻辑的界面放置在此处。 其实现类是当前的活动/框架。

从UML图中可以看到，Activity包含IPresenter，而PresenterCompl包含IView，并且依赖于模型。 Activity中只剩下对IPresenter的调用，其他工作都留在PresenterCompl中实现。

模型不是必需的，但一定有视图和Presenter。

通过以上介绍，MVP的主要特点是使Activity中的许多逻辑离开View和Presenter接口，完成具体的实现类。 这种写法增加了很多IView和IPresenter的接口。

在一定程度上增加了开发的工夫，对于刚开始使用MVP的伙伴来说，这种写法可能会有违和感，难以记忆。 其实一开始想得太多也成不了什么蛋。 在具体项目中多次书写，就能熟悉MVP模式的书写方式，理解意图，享受由此带来的好处。

使用MVP

理论说了这么多，其实很少用于鸡蛋，所以我们来看看在代码中怎么用。

首先，让我们看一下项目中的代码结构。 结构图如下。

从代码结构图中可以看出，MVP结构是分层的。 如果要在项目中使用MVP，建议在模块中进行分层。 这是因为它易于管理，结构清晰。

视图层代码

ILoginView接口代码如下。

publicinterfaceiloginview { publicvoidoncleartext (； publicvoidonloginresult (布尔结果，int code； }复制代码

可以看出ILoginView只是一个界面，简单地定义了两种方法。

让我们看一下ILoginView的实现类，即我们的LoginActivity :

在LoginActivity中，您可以看到LoginActivity实现了ILoginView接口，并实现了未实现的方法。 在代码中，您可以看到LoginActivity并不从事逻辑处理工作，所有的数据处理工作都是通过调用ILoginPresenter完成的。

Presenter代码

下面就来看看 ILoginPresenter：

public interface ILoginPresenter { public void clear(); public void doLogin(String name, String password);}复制代码

也是简单的接口定义两个未实现的方法。

看看其实现类 LoginPresenterCompl：

该实现类也比较简单，定义了用户名是危机的刺猬，密码是123456的一个登陆用户，然后进行登陆和清除的操作。

Model层代码

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; } public void setName(String name) { this.name = name; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; }}复制代码

OK，这就完成了最简单的 MVP模式 了。

看完上述 MVP 的代码后可能有的同学会说一个简单的登陆就是简单的验证用户名和密码为什么要设计的这么复杂，可能有人会觉得还没有以前的写法简单呢。但是这只是一个简单的实现 MVP 的例子。

当项目越来越大，代码越来越多的时候就能够真正的体现出 MVP模式 的优势了。

知道了什么是 MVP 也知道了如何在项目中使用 MVP，那MVP的优势到底有哪些呢？

MVP的优势

使Activity代码更加简洁

在传统的项目中 Activity 兼顾着 Controller 和 View，这使得其代码分分钟上千行（本人深受其害），这使得代码难以理解难以维护，看到这样的 Activity 就想吐。

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

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

方便进行单元测试

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

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

避免Activity内存泄露

APP发生 OOM 的最大原因就是出现内存泄露造成APP的内存不够用，而造成内存泄露的两大原因之一就是 Activity泄露（Activity Leak）（另一个原因是 Bitmap泄露（Bitmap Leak））。

Java一个强大的功能就是其虚拟机的内存回收机制，这个功能使得Java用户在设计代码的时候，不用像 C++ 用户那样考虑对象的回收问题。然而，Java用户总是喜欢随便写一大堆对象， 然后幻想着虚拟机能帮他们处理好内存的回收工作。可是虚拟机在回收内存的时候，只会回收那些没有被引用的对象，被引用着的对象因为还可能会被调用，所以不能回收。

Activity 是有生命周期的，用户随时可能切换 Activity，当APP的内存不够用的时候，系统会回收处于后台的Activity的资源以避免 OOM。

采用传统的模式，一大堆异步任务和对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。

总结

以上就是 MVP的简单实现，可能示例代码太简单无法体现 MVP的优势，但是理解了 MVP的思路 在项目中使用 MVP 就才能够真正体验到 MVP 带来的好处优势。