Android MVVM架构分析

最新推荐文章于 2026-05-10 17:59:09 发布

原创

最新推荐文章于 2026-05-10 17:59:09 发布 · 7.7k 阅读

本文探讨Android的MVVM架构，分析其数据驱动、低耦合度等优点，介绍DataBinding库和AAC（LiveData）两种实现方案，并比较MVVM与MVC、MVP的演进过程，强调MVVM在团队协作、可复用性和单元测试方面的优势。

前言

本文俩个任务：

1.对MVVM进行学习
2.总结梳理MVC-MVP-MVVM的演进过程

什么是MVVM

MVP是对MVC的C的演化，MVVM是对MVP的P的演化。而Android领域的MVVM自身也进行了一次演化，即从2015年DataBinding推出开始，由传统的MVVM到2017谷歌推出了AAC标准架构。并在二者迭代的过程中，也出现了基于传统的DataBinding增强的方案（MVVM Light Toolkit使用指南）。

MVVM是一种思想。即UI随数据更改而更改。它独特的地方就在于它的DataBinding特性。但请注意，虽然Google2015专门发布了一个库叫做DataBinding，但是这里说的DataBinding并不是指的某个具体的库，而是指的一种“行为”，指的是一类的”将数据Model映射到View”的框架。譬如老的DataBing库，新AAC的LiveData。

View: 对应于Activity和XML，负责View的绘制以及与用户交互。
Model: 实体模型。
ViewModel: 负责完成View与Model间的交互，负责业务逻辑。

特点

数据驱动

在常规的开发模式中，数据变化需要更新UI的时候，需要先获取UI控件的引用，然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中，这些都是通过数据驱动来自动完成的，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据，不需要直接和UI打交道，在业务处理过程中简单方便很多。

低耦合度

MVVM模式中，数据是独立于UI的。

数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事，也不持有UI控件的引用。即便是控件改变了（比如：TextView换成EditText），ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel，解决了上面我们所说的MVP的痛点。

更新UI

在MVVM中，数据发生变化后，我们在工作线程直接修改（在数据是线程安全的情况下）ViewModel的数据即可，不用再考虑要切到主线程更新UI了，这些事情相关框架都帮我们做了。

团队协作

MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的：一个是处理业务和数据、一个是专门的UI处理。所以，完全由两个人分工来做，一个做UI（XML和Activity）一个写ViewModel，效率更高。

可复用性

一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。

单元测试

有些同学一看到单元测试，可能脑袋都大。是啊，写成一团浆糊的代码怎么可能做单元测试？如果你们以代码太烂无法写单元测试而逃避，那可真是不好的消息了。这时候，你需要MVVM来拯救。

我们前面说过了，ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的（部分数据是可以直接反映出UI上的内容），那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。