Android、IOS、Web、桌面、跨平台等前端应用开发中有很多把MVC、MVP等架构改造成MVVM的需求场景，但标准的MVVM改造往往有以下问题：
- View和Data绑定的原理和应用有不少学习成本；
- 标准MVVM改造往往有较大的代码改动量；
- 在一些框架下，数据绑定更新View会增加问题定位难度；
这就形成了MVVM改造复杂度高、工作量大的固有印象，在犹疑、恐惧中造成了改造计划流产，或者启动计划后进度缓慢等问题。那有没有简单可行、改动量小的方案呢？那必须得有啊！！！在揭晓答案前，我们先从架构演化角度看看MVVM的核心思想是什么。
架构演化
图中箭头方向代表依赖：比如在MVP中P依赖M，就是说P通过调用M中的实例对象或者静态类来实现自己功能；M不依赖P，就是说M的实现则完全不需要P，M中不存在任何引用P的代码。
再看上图，对比MVP，MVVM核心思想在于ViewModel不依赖View，一般在架构设计上相互依赖的两个模块可以认为是同一个层级，那MVP到MVVM改造的关键在于去除P对于V的依赖, 将两层架构变成三层架构，这个三层架构又跟当前常见的服务端分层架构是等价的，这里又引入两个额外的问题：
- 当我们构建一个系统时候，选择架构的依据是什么？
- MVP、MVVM、分层架构等架构，它们分层设计的依据是什么？
这些问题以后文章再谈，回到正题，如何去掉P对于V的依赖呢，直接上图讨论：
MVVM架构图
如图，去除P对于V的依赖，实现MVP到MVVM的改造，我们只需要三步：
1. 去除Presenter 对View的引用，Presenter改名为ViewModel；
2. ViewModel的数据和状态都存储在自己实例中实现共享，或者通过不同数据通道发送出去；
3. 宿主View调用ViewModel实例启动各种业务流程，并监听ViewModel的数据变化，根据接收到的数据来驱动自己和子View的UI变化；
为了更好的实现MVVM，对于实现过程我还有一些建议的原则：
- ViewModel功能分割尽量原子化，方便复用；
- 梳理ViewModel共同能力，构建不同的ViewModel基类，方便快速扩展；
- 数据传递采用同一个ViewModel共享优先，其他通信方式传递其次；
- ViewModel生命周期尽量短，避免占用太多内存；
最后是 Android MVVM架构最简实现方案
由于ViewModel开发完全不依赖View，所以UI和逻辑可以完全分开开发，但为了UI开发时候方便看到数据进行自测，可以优先开发ViewModel，再开发页面UI，具体实施路径如下：
- ViewModel开发：梳理ViewModel共同能力，构建不同的ViewModel基类和接口，根据业务逻辑开发不同的ViewModel;
- 布局和UI开发： 不建议使用DataBinding， 跟之前一样构建Xml、自定义View、Fragment等UI元素；
- 数据产生、存储、发送：ViewModel的数据和状态都保存在实例中，如果不能通过共享ViewModel获取数据，则通过LiveData/EventBus广播出去；
- 业务请求、UI更新：Activity/Fragment中，通过ViewModel实例，发起方法调用实现数据请求、数据更新，并通过监听ViewModel 中Livedata数据变化来更新自己和子View的UI。
网友评论