经过一年的努力推动，公司研发部门同事终于走上了规范之路。对于旧项目的代码维护真是苦不堪言，一个OTA升级项目的实现，仅用了三个类实现所有的功能，修个小bug,用了两天在看整个项目代码怎么实现的...动一下就崩一下那种。

所以，能告诉我，为什么还要在Activity中写业务代码么？

MVVM模式浅谈

关于Android的MVVM开发框架，可能是老生常谈。与如停留在概念上讲解，不如与实战开发一起来说说。与MVC、MVP等模式的设计理念是一致的，就是为了解耦，方便后期维护和功能迭代。

MVVM模式在Android可以解读以下三个对象：

View: 这样指的应该是Activity、Fragment等UI控制器以及相关具体的View，当然也包括xml布局文件。主要负责界面的实现和与用户的交互。

Model: 数据模型，可以说，是应用对外数据交互的接口。在Model层关心的应该是数据。例如根据应用的不同环境或逻辑，从网络或者本地获取数据，为ViewModel提供数据。

ViewModel：View与Model交互的桥梁，也是应用逻辑实现的地方。将曾经大量在View层实现的逻辑代码转移到自身，从而减少UI控制器代码的臃肿。

采用MVVM模式在实际开发带来的好处是什么？

解耦三个层各司其职，专心负责自己的工作，例如Model层只负责数据的获取，为内部提供数据资源。不用处理ViewModel层的业务逻辑。
整洁，清晰 解耦之后，应用功能的实现非常整洁，思路也非常清晰，在哪个类该实现View,哪里类应该实现数据请求一目了然，不存在代码和逻辑相互嵌套等导致后期项目难以维护的问题。
协作在人力充足情况，可以多人负责一个层或者一人负责一个层，然后为另外一个层提供接口。

不可避免的是，无论是MVC、MVP还是我们所说的MVVM模式，都会导致类和代码的增加，但请相信，这值得去做。

实战中整体框架思路

View层

View层只关心和UI相关的工作，我们只在Activity、Fragment和xml布局写和UI相关代码，以及和用户的交互，例如监听用户的点击View之后，应该通知ViewModel去处理相关业务逻辑，而不是在Activity中处理。

更希望的时候，通过数据驱动来改变View，而不是View通知ViewModel有相关交互。例如，通过Jetpack中DataBinding来实现双向绑定。View的点击事件直接传递到ViewModel层，ViewModel层处理相关逻辑。或者View层监听ViewModel的LiveData变量，在数据发生变更时更改View。而不是View层为ViewModel层提供View改变的接口。

下面是View层一些推荐文章：

ConstraintLayout

DataBinding

LiveData

ViewModel层

ViewModel担任着View与Model交互的桥梁和业务逻辑的处理，具有举足轻重的地位。这里我们推荐使用Jetpack的ViewModel,至于能带来什么好处，可以看下文的链接。一定要记住，不要在ViewModel层去更新UI或者获取数据，它只负责UI和数据逻辑的交互，但不负责View层和Model层的工作。一般View层都会持有一个ViewModel实例，通过实例来操作数据，而操作结果通过改变LiveData的值，来做相关UI改变，例如更新数据展示。

Jetpack的ViewModel

Model层

Model层负责数据的获取，转为实体对象，映射到ViewModel层。ViewModel层一般持有Model实例，操作Model提供的接口。对于网络请求，一般推荐使用Retrofit，数据库推荐Room。在Model实现的操作一般都是耗时的，Java开发配合RxJava,Kotlin开发使用协程，效果最佳。对实体对象的返回，常有回调函数和EventBus来处理。

下图是以MVVM模式开发的用户登录：

终生愿望：希望各位研发同志早日用上开发框架MVVM也好，MVP也罢。