只需跟着Google学android:ViewModel篇
前言
系列文章:
只需跟着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层使用的输入数据。
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<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的内容,想聊的就这么多啦。
上述的内容主要从两个架构和“坑”的角度展开,更多的是想输出一种思路(希望各位同学能够接受),先从官方文档中思考技术出现的意义。有了这个基础再看其他的网文,就可以取其精华去其糟粕。