MVP

MVC痛点：Controller过大。

痛点举例：下雪Demo，拖住雪花可动这个需求需要依赖于Activity，导致Activity过重。

MVP和MVC的最大区别：

数据Model和view不交互。

好处举例：不会造成View（Activity）被finish回收之后，持有View（Activity）引用的Model才回调，此时发生的内存泄露

核心思想：

将activity的业务逻辑放到Presenter，并且把关于UI的逻辑抽象成View接口供Presenter回调， Model还是原来的Model

举例 加载数据进行显示的例子：

Presenter与Model：Presenter调用Model的loadData；Model加载数据完毕后 回调Presenter的onLoadDataSuccess

Presenter与View：presenter调用View的showloading、showDataResult

优点：

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

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

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

3.对于内存泄露方面。

采用传统的MVC模式，一大堆异步任务和对UI的操作都放在Activity里面，比如你可能从网络下载一张图片，在下载成功的回调里把图片加载到 Activity 的 ImageView 里面，所以异步任务保留着对Activity的引用。这样一来，即使Activity已经被切换到后台（onDestroy已经执行），这些异步任务仍然保留着对Activity实例的引用，所以系统就无法回收这个Activity实例了，结果就是Activity Leak。

而MVP，可以在BaseActivity的onCreate的时候，统一通过view接口弱引用 与presenter建立联系。onDestroy的时候，进行分离。

缺点：

需要通过接口与视图进行操作，接口爆炸。接口封装时如果粒度小，接口数量陡然增多；如果粒度过大，耦合大、违反单一原则

缺乏自动性、监听性，UI和Data没能双向绑定、自动响应（可通过MVVM架构解决）

依然以UI事件驱动，避免不了findViewById、还需考虑activity的生命周期

封装示例--

abstract class BasePresenter<V, T extends BasePresenter>

MainActivity extends BaseActivty<ViewImpl, PresenterImpl>