只需跟着Google学android：ViewModel篇

前言

系列文章：
只需跟着Google学android：ViewModel篇

关于ViewModel的内容，大概半年前已经写过两篇内容（但是建议看官方文档）：

官方文档：ViewModel

上述官方文档：ViewModel地址：https://developer.android.com/topic/libraries/architecture/viewmodel
我之前的文章：一点点入坑JetPack：ViewModel篇

官方文档：Saved State module for ViewModel

上述官方文档：Saved State module for ViewModel地址：https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate
我之前的文章：ViewModel的局限，销毁重建的方案SavedStateHandle

之前写的文章现在来看也是没啥毛病，ViewModel该聊的基本也都聊到了。因此今天这篇文章更多的是对之前文章的补充：

• ViewModel存在的意义
• Android-KTX对ViewModel的增强
• ViewModel的错误用法

正文

官方对ViewModel的定义：

• 1、类职责：负责为界面准备数据（意味着一切处理数据逻辑的业务代码，应该写在ViewModel中）
• 2、在配置更改期间会自动保留ViewModel对象：因此可以作为跨页面（Fragment）通讯的基石

image.png

接下来我们进一步深究一下这俩个定义：

一、ViewModel的意义

在Model/View/ViewModel(MVVM)模型中，ViewModel层是这样的定义：

上述Model/View/ViewModel(MVVM)模型链接地址：https://docs.microsoft.com/zh-cn/archive/blogs/johngossman/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps

只有一小部分View层控件可以直接与Model层进行数据绑定，尤其是在Model层是开发人员无法控制的情况下（由其他人提供）。该Model层提供的数据很可能是无法直接映射到控件上。 此外UI控件可能需要执行复杂的操作，而这些代码写在View层中没有意义（因为它们不属于UI控件的逻辑），并且这些操作逻辑太过具体，也无法包含在Model层中（因为这也不是Model层应该关心的） 。 所以，我们需要一个处理View层状态的地方。

ViewModel层就是负责这些任务。ViewModel层包含将Model层数据结构转换为View层数据结构的数据转换器，并且包含View层可用于与Model层进行交互的命令。

由上述定义，我们可以清晰的明确：ViewModel层是转换层。用于把Model层的输出数据转换成View层使用的输入数据，把View层的输出数据转换成Model层使用的输入数据。

image.png

咱们会发现MVVM中ViewModel的定义，和Google推出的ViewModel库的第一个职责定义很类似。

因此，可以顺其自然使用ViewModel来作为MVVM中ViewModel层的实现方案。既然使用ViewModel作为ViewModel层，那么它的一大意图也就明确了：规范我们的代码组织结构，告诉我们处理数据数据的代码应该写在ViewModel中。

明确了第一大意图，咱们再看一看上述第二大意图：在配置更新期间，保存ViewModel实例。

短短的几个字，有2个很重要的信息：

• 1、ViewModel实例的生命周期对Activity/Fragment长。
• 2、ViewModel不能处理Activity销毁重建的情况。

第一个信息意味着我们不能这么干：

image.png

如果需要context，可以使用AndroidViewModel

第二个信息如何处理？详见ViewModel的局限，销毁重建的方案SavedStateHandle

二、Android-KTX

引用官方的一句话解释一下什么叫KTX：

Android KTX 是包含在 Android Jetpack 及其他 Android 库中的一组Kotlin 扩展程序。

KTX 扩展程序可以为 Jetpack、Android平台及其他API提供简洁的惯用Kotlin代码。为此，这些扩展程序利用了多种 Kotlin 语言功能，其中包括：

• 扩展函数
• 扩展属性
• Lambda
• 命名参数
• 参数默认值
• 协程

KTX有很多，有兴趣了解其他KTX的内容，可以访问官网。

上述官网地址：https://developer.android.google.cn/kotlin/ktx?hl=zh_cn#viewmodel

2.1、Fragment-KTX为我们提供了什么？

日常我们获取到ViewModel实例时，大概是这个样子：

lateinit var viewModel: XXViewModel

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    viewModel = ViewModelProviders.of(this)[XXViewModel::class.java]
}

使用带SavedStateHandle还要这样：

lateinit var viewModel: XXViewModel

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    viewModel = ViewModelProvider(
        this,
        SavedStateViewModelFactory(Application, this)
    )[XXViewModel::class.java]
}

巨麻烦，而且这都是样本代码。如果我们引入Fragment-KTX：

dependencies {
    implementation "androidx.fragment:fragment-ktx:1.2.4"
}

上述俩种初始化ViewModel的方式，可以简化为一个by关键字：

// Fragment级别的ViewModel
private val viewModel: XXViewModel by viewModels()
// Activity级别的ViewModel
private val viewModel: XXViewModel by activityViewModels()

2.2、ViewModel-KTX为我们提供了什么？

给我们提供了一协程环境viewModelScope，因此在ViewModel中，如果我们想要使用协程，可以直接：

viewModelScope.launch  {
    // ...
}

而且也不用担心Job是否被cancel掉。

注意，协程是协作式的。不是说调了Job.canel()就万事大吉了，我们还需要在对应的launch中显示的基于isActive去判断当前的协程是否存活（协程部分有机会再展开）。

三、ViewModel的错误用法

聊完上述部分，我们再聊一聊错误或者是有坑的点。

3.1、AndroidViewModel中慎重进行R.string.xxx

先上一段代码：

public class MyViewModel extends AndroidViewModel {
    public final MutableLiveData statusLabel = new MutableLiveData<>();
    
    public SampleViewModel(Application context) {
        super(context);
        statusLabel.setValue(context.getString(R.string.labelString));
    }
}

这种用法的问题在于，ViewModel在配置更新的时候，并不会销毁重建因此构造函数不会重走。

因此如果此时需要动态替换R.string.labelString，那么这种情况下是不正确的。

因此在ViewModel里动态加载string，是有坑的，需要慎重。

3.2、ViewModel不能解决销毁重建问题

销毁重建，这个问题八成没有人注意,但是一旦遇到这个问题，基本上是“致命”的。

上述销毁重建地址：https://developer.android.com/topic/libraries/architecture/saving-states#use_onsaveinstancestate_as_backup_to_handle_system-initiated_process_death

不知道大家日常有没有处理过：“一定”不为null的情况下，出现了空指针的crash。这种case归咎于销毁重建基本跑不了。

复现销毁重建的场景很简单，在开发者选项中，开启：不保留活动。

因此，在ViewModel中存储成员变量、Callback等行为。在销毁重建的场景下都是很危险的。那针对这种情况该怎么办？

• 成员变量（如果业务场景不在意销毁重建，可以无视。如果不能无视，回头瞅一下开篇的文章。）
• Callback（下一篇LiveData篇，会结合Google的文章，展开一段合理的处理CallBack的方案）

尾声

关于ViewModel的内容，想聊的就这么多啦。

上述的内容主要从两个架构和“坑”的角度展开，更多的是想输出一种思路（希望各位同学能够接受），先从官方文档中思考技术出现的意义。有了这个基础再看其他的网文，就可以取其精华去其糟粕。

个人公众号：咸鱼正翻身