Android默认采用的是MVC：
- View：对应于布局文件
- Model：业务逻辑和实体模型
- Controllor：对应于Activity
但是却存在很多问题：
1.这个View对应于布局文件，其实能做的事情特别少。
2.所有的事件处理的代码都在Activity中，造成了Activity既像View又像Controller这可能
所以出现了MVP，这个P,即Presenter，他将Actvity视为View层，Presenter负责完成View层与Model层的交互
- View 对应于Activity，负责View的绘制以及与用户交互
- Model 依然是业务逻辑和实体模型
- Presenter 负责完成View于Model间的交互
这种模式减少了Activity的职责，简化了Activity中的代码，将复杂的逻辑代码提取到了Presenter中进行处理。与之对应的好处就是，耦合度更低，更方便的进行测试。
MVP模式的核心思想：
MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
这就是MVP模式，现在这样的话，Activity的工作的简单了，只用来响应生命周期，其他工作都丢到Presenter中去完成。从上图可以看出，Presenter是Model和View之间的桥梁，为了让结构变得更加简单，View并不能直接对Model进行操作，这也是MVP与MVC最大的不同之处。
上面一张简单的MVP模式的UML图，从图中可以看出，使用MVP，至少需要经历以下步骤：
- 创建IPresenter接口，把所有业务逻辑的接口都放在这里，并创建它的实现PresenterCompl（在这里可以方便地查看业务功能，由于接口可以有多种实现所以也方便写单元测试）
- 创建IView接口，把所有视图逻辑的接口都放在这里，其实现类是当前的Activity/Fragment
- 由UML图可以看出，Activity里包含了一个IPresenter，而PresenterCompl里又包含了一个IView并且依赖了Model。Activity里只保留对IPresenter的调用，其它工作全部留到PresenterCompl中实现
- Model并不是必须有的，但是一定会有View和Presenter
通过上面的介绍，MVP的主要特点就是把Activity里的许多逻辑都抽离到View和Presenter接口中去，并由具体的实现类来完成。这种写法多了许多IView和IPresenter的接口
如果需要添加新的业务逻辑，只需要添加到IPresenter里，然后通过它的实现类PresenterCompl去实现，最后在Activity里调用IPresenter 抽象方法
如果需要新的操作ui，需要抽取到IView里，Activity去实现抽象方法，在PresenterCompl里可以调用IView的抽象方法。
LoginPresenterCompl保留了ILoginView的引用，因此在LoginPresenterCompl里就可以直接进行UI操作了，而不用在Activity里完成。这里使用了ILoginView引用，而不是直接使用Activity，这样一来，如果在别的Activity里也需要用到相同的业务逻辑，就可以直接复用LoginPresenterCompl类了（一个Activity可以包含一个以上的Presenter，总之，需要什么业务就new什么样的Presenter，这也是MVP的核心思想）
通过IVIew和IPresenter，把Activity的
UI Logic和Business Logic分离开来，Activity just does its basic job! 至于Model，还是原来MVC里的Model。 所有的逻辑都不在Activity里去实现。
参考：https://segmentfault.com/a/1190000003927200
