为何还要在Activity中写业务代码？

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