前言
系列文章：
只需跟着Google学android：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）通讯的基石
接下来我们进一步深究一下这俩个定义：
一、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层使用的输入数据。
咱们会发现MVVM中ViewModel的定义，和Google推出的ViewModel库的第一个职责定义很类似。
因此，可以顺其自然使用ViewModel来作为MVVM中ViewModel层的实现方案。既然使用ViewModel作为ViewModel层，那么它的一大意图也就明确了：规范我们的代码组织结构，告诉我们处理数据数据的代码应该写在ViewModel中。
明确了第一大意图，咱们再看一看上述第二大意图：在配置更新期间，保存ViewModel实例。
短短的几个字，有2个很重要的信息：
- 1、ViewModel实例的生命周期对Activity/Fragment长。
- 2、ViewModel不能处理Activity销毁重建的情况。
第一个信息意味着我们不能这么干：
如果需要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<String> 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不能解决销毁重建问题
销毁重建，这个问题八成没有人注意,但是一旦遇到这个问题，基本上是“致命”的。
不知道大家日常有没有处理过：“一定”不为null的情况下，出现了空指针的crash。这种case归咎于销毁重建基本跑不了。
复现销毁重建的场景很简单，在开发者选项中，开启：不保留活动。
因此，在ViewModel中存储成员变量、Callback等行为。在销毁重建的场景下都是很危险的。那针对这种情况该怎么办？
- 成员变量（如果业务场景不在意销毁重建，可以无视。如果不能无视，回头瞅一下开篇的文章。）
- Callback（下一篇LiveData篇，会结合Google的文章，展开一段合理的处理CallBack的方案）
尾声
关于ViewModel的内容，想聊的就这么多啦。
上述的内容主要从两个架构和“坑”的角度展开，更多的是想输出一种思路（希望各位同学能够接受），先从官方文档中思考技术出现的意义。有了这个基础再看其他的网文，就可以取其精华去其糟粕。
