mvc、mvp是一种架构模式，在Android中的运用非常广泛，作为一名Android开发者，想要开发稍微大型一些的项目，必须得熟练运用mvp，正好最近在用mvp重构项目中的代码借此回顾一下mvp模式，这篇文章算是笔者在对自己学习 mvp 的一个总结归纳。
MVC
View层：
一般对应于
xml布局，当然遇到复杂的情况需要自定义View，自定义View也是属于View层。职责：View层只需要负责做一些视图显示的操作
Controller层：
一般对应于Activity/Fragment
职责：处理用户的交互，做一些逻辑处理操作，向Model层拿数据提供给View层，从而让View正确的显示出来。
Model层：
Model层没有明确的定义，一般的数据实体类 和 相关的业务逻辑处理 就属于Model层
职责：
1、存放 JavaBean实体类，比如：
public class User {
private int age;
private String name;
private ...
public void setAge(int age) {
}
public int getAge() {
return age;
}
...
}
2、一些业务逻辑处理，不过客户端很少会有，一般在服务端较多，所以大部分情况下Model也就包含一些基本数据和get、set方法，但并不是说明客户端不存在任何业务逻辑，比如我们需要显示用户的身体质量指数，但这个值不是Model自带的属性，而是需要通过一定算法算出来，这就是所谓的业务逻辑
体重（kg）÷ （身高^2（m）
public class User {
private int age;
private String name;
private float weight;
private float height;
...
...
public float getBMI() {
return weight / height * height;
}
}
注意：
有人认为Model层除了包括上面的 1、2 两点外，还应该包括对数据库的操作、对网络等的操作，这对于后端来说没问题，因为后端的数据全部来源于数据库。但对于客户端来说可不一样，客户端的数据来源很多：包括服务端的接口请求、本地数据库、文件、sharedpreference等等，Model本身主要职责应该是定义业务需要的数据模型以及简单的逻辑处理，如果同时还要处理本地数据库与网络数据会使Model层变得臃肿起来，职责不清晰。
MVC优点：
1、简单、成本低、容易理解
MVC缺点：
1、随着功能不断复杂，Controller层也就是Activity/Fragment 中的代码越来越多，臃肿难维护。
而且Android开发框架也并不是严格意义上的MVC，因为Activity/Fragment并不是严格意义上的Controller层，因为Activity/Fragment还有自己的生命周期要管理，还有附带着一些View相关的操作（比如：findViewById（）、View.setxxx（））,所以实际上Android默认的开发框架并没有一个真正的Controller，所以会导致Activity/Fragment的臃肿。
MVP
MVP 作为 MVC 的升级版，解决了 MVC Controller层臃肿的问题。
Model层：
这层相比MVC没什么变化
View层：
分为两层，一层是 接口 ，一层是 实现类 （一般是Activity或Fragment，也可以是自定义View），先定义所有View操作的接口，然后用 Activity/Fragment 去实现
职责：现在的 View 层（ Activity/Fragment ）相比MVC 的 View 层， Activity/Fragment 只需要管理自己的生命周期和一些View相关的操作，所有的逻辑操作全部抽出到P层
Presenter层：
同样分为两层，接口层和实现层，连接 View 与 Model ，处理所有的逻辑。
职责：
处理所有 View 和 Model 之间的逻辑，这也是为什么使用了MVP可以解决Activity过于臃肿的问题（相当于加了一个叫 Presenter 的类来分担原本属于 Activity 的一些工作）
一般来说：
1、View 和 Presenter 是一对一的，也就是说每个View有自己的Presenter来处理对应的逻辑
2、View 和 Presenter 都是通过接口进行交互的，这样有利于测试。
MVP优点：
1、Model 与 View 完全分离，耦合度更低。
原来在MVC中V层的数据可能来源于C层也可能来源于M层，数据流向不透明，这会导致如果出现bug，不能第一时间定位。
而现在 M层 和 V层 分离了以后，V层出了问题，直接定位到与其交互的P层，简单明了。
2、解放了Activity/Fragment，它们被规划到了V层，只需要处理一些View相关的操作，和自己的生命周期，代码简洁易维护
3、P层对V层是 通过接口的形式进行调用的，测试的时候很容易Mock一个View，使它继承View的接口，然后注入到Presenter，便于开展对Presenter的单元测试
4、减少内存泄漏的风险，因为异步任务完全抽象成了接口，减少了相互之间的引用
