在传统的Android开发中，我们一般是使用MVC模式进行开发的。 传统MVC模式介绍：
View: 视图层，对应xml文件 Controller: 控制层，对应Activity和Fragment层，进行数据处理 Model：实体层，负责获取实体数据
在Android开发中采用MVC模式的一个有一个的弊端就是xml作为View层视图能力实在太弱，所以一般情况下我们都是通过Controller层来辅助处理一些视图的。这样的结果就导致Controller既作为控制层的同时又承担了View层的大部分功能，采用MVC模式往往会导致Activity和Fragment中的代码非常复杂。也有人说，Android的MVC不是MVC 因为V 和C 基本融合在一起了。
举个例子，简单的登录功能 Model层：
View层 Control层
随着功能的增加，Activity的代码也会越来越多。
MVP模式介绍：
View: 视图层，对应xml文件与Activity/Fragment Presenter: 逻辑控制层，同时持有View和Model对象 Model: 实体层，负责获取实体数据
先看一个demo，也是一个登录的例子，点击Aty上的登录按钮，实现登录
IModel
ModelImpl 访问服务器后，通知P层处理success事件
P层 ，做为M V的通信桥梁，在这里，P层继要将Aty点击事件传给Modle层，又要强modle层的返回数据处理后，返回给Aty，代码如下
P层实现
可以看到，在接收到Model的success之后，P层可以继续对数据做一些处理，然后逻辑处理完成后，再通知V层去更新View
V层
V层实现层
如果以后业务逻辑增加我们可以这样，比如说 需求忽然要再访问服务器后做一些事情。
P层
以后不管逻辑怎么增加，我们在Activity里面可以这样做
采用MVP模式的优势是：
把业务逻辑抽离到Presenter层中，View层专注于UI的处理。 分离视图逻辑与业务逻辑，达到解耦的目的。 提高代码的阅读性。 可拓展性强。
采用MVP模式的缺点：
项目结构会对后期的开发和维护有一定的影响。具体视APP的体量而定。 代码量会增多，如何避免编写过多功能相似的重复代码是使用MVP开发的一个重点要处理的问题。 有一定的学习成本。
