为什么还要在Activity中写业务代码?

8,800 阅读4分钟

经过一年的努力推动,公司研发部门同事终于走上了规范之路。对于旧项目的代码维护真是苦不堪言,一个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也罢。