MVP框架

一、MVP 由来

按照MVC的分层，Activity应该属于View层，用于展示UI界面，以及接收用户的输入，此外还要承担一些生命周期的工作。 特别是生命周期的功能，所以开发的时候我们经常把一些业务逻辑直接写在Activity里面，这非常直观方便，代价就是Activity会越来越臃肿;

超过1000行代码是常有的事，如果有进行代码重构经验的人，看到1000+行的类肯定会有所顾虑。Activity不仅承担了View的角色，还承担了一部分的Controller角色，这样一来V和C就耦合在一起了，虽然这样写方便，但是如果业务调整的话，要维护起来就难了，而且在一个臃肿的Activity类查找业务逻辑的代码也会非常难受，所以看起来有必要在Activity中，把View和Controller抽离开来，而这就是MVP模式的工作了。

二、框架图对比

三、MVP解决什么问题

View 对应于Activity，负责View的绘制以及与用户交互
Model 依然是业务逻辑和实体模型

Presenter 作为桥梁，负责完成View于Model间的交互

view层和model层不再相互可知，完全的解耦，取而代之的presenter层充当了桥梁的作用，用于操作view层发出的事件传递到presenter层中，presenter层去操作model层，并且将数据返回给view层，整个过程中view层和model层完全没有联系

mvp 对应模块

View         对应于Activity，负责View的绘制以及与用户交互
Model      依然是业务逻辑和实体模型

Presenter 负责完成View于Model间的交互

mvp的使用

项目结构

MVP的优点

分离了视图逻辑和业务逻辑，降低了耦合

Activity只处理生命周期的任务，代码变得更加简洁

视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去，提高代码的可阅读性

Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单分离了视图逻辑和业务逻辑，降低了耦合

Activity只处理生命周期的任务，代码变得更加简洁

视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去，提高代码的可阅读性

Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单元测试