android开发框架总结 （二）MVP与MVVM详细介绍与对比，选择适合的框架

前言

本篇文章将非常“细致”地总结分析MVP与MVVM这两种框架对于架构的选择做了比较多的分析，应该是干货满满，如果你对这两者的使用与选择上还有迷惑之处。真的希望你能认真看完。

如果你是非常有经验的程序猿，那就当相互学习总结，如果有不同看法还望指教。当然，我也是非常想进步的。

---

目录

前言

1.MVP

MVP的优点

MVP的缺点

2.MVVM

MVVM的特点（优点）

MVVM的缺点

架构组件

3.MVP与MVVM的复用

4.如何选择

5.MVP+LiveData+ModeView+LifeCycle+Dagger2

---

1.MVP

文章的一开始，先来回顾一下，什么是MVP

MVP是在MVC的基础上进行改造，用Present解决了V与M之间耦合度的问题，activity是作为V层的。

View：对应于Activity/Fragment/自定义View，主要负责UI渲染。
Model：数据获取模块
Presenter： 负责数据处理以及View和Model的交互等，持有Model和View的引用。

在MVP模式中，View层只负责UI渲染，不再需要处理对应的业务逻辑，View层的量级大大轻化。而Presenter在获取到Model的数据，并进行处理后，通过View层暴露的接口调用去更新UI，这样View层和
Model层不互相持有引用，保证是隔离和解耦的。这样整个业务逻辑处理和视图的渲染是隔离的，就不会再出现上文提到的Activity/Fragment/View臃肿和混乱的问题。

我们来看一下MVP的结构图

当然，由于MVP比较多变，不同公司不同需求结构下P层可能会有比较多架构的变化。对于虚线部分，每个人的理解不同，情况不同，选择合适的就好，不用纠结谁对对错，本质不变就可以的。

MVP的优点

1.模型与视图完全分离

2.P层非常容易（适合）做单元测试，Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单元测试

3.（Presener的复用）一个Presener可以用于多个视图（View），而不需要改变Presenter的逻辑。视图（View）的变化比模型（Model）的变化更频繁的多 ，所以这样超级方便。

4.（View的复用）View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。Activity只处理生命周期的任务，代码变得更加简洁

5.可以更高效地使用Model，因为所有的交互都发生在一个地方——Presenter内部

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

MVP的缺点

1.Presenter层要处理的业务逻辑过多，复杂的业务逻辑会使P层非常庞大和臃肿。

2.Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑（没有做到像MVVM数据同步那样一劳永逸），造成