1. MVP是啥？

M-model：即javaBean，数据模型层；
V-view：即视图层，通常指Activity，fragment；
P-presenter：即数据处理层，所有的数据逻辑，业务逻辑都在这个处理；

与MVC的比较：

在 MVC 中 Activity 其实是 View层级，但是通常在使用中 Activity即是View也是Controller，并没有将 View层和 Controller层进行分离，耦合度大大提高，非常不利于项目的管理。
在MVP中，MVP 把 Activity 中的 UI逻辑抽象成 View接口，把业务逻辑抽象成 Presenter接口，Model类还是原来的 Model。
在 MVP 模式中 Activity 的功能就是响应生命周期和显示界面，具体其他的工作都丢到了 Presenter层中进行完成，Presenter 其实是 Model层和 View层的桥梁。

2. MVP的优势有啥？

（1）使Activity代码更加简洁
在传统的项目中 Activity 兼顾着 Controller 和 View，这使得其代码分分钟上千行，这使得代码难以理解难以维护。

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

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

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

MVP 中，由于业务逻辑都在 Presenter 里，我们完全可以写一个 PresenterTest 的实现类继承 Presenter 的接口，现在只要在 Activity 里把 Presenter 的创建换成 PresenterTest，就能进行单元测试了，测试完再换回来即可。万一发现还得进行测试，那就再换成 PresenterTest 吧。
（3）避免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 google官方demo比较分析
 MVP模式解析实践