ViewModel是Jetpack AAC的重要组件,同时也有一个同名抽象类。
ViewModel,意为 视图模型,即 为界面准备数据的模型。简单理解就是,ViewModel为UI层提供数据。 官方文档定义如下:
ViewModel 以注重生命周期的方式存储和管理界面相关的数据。(作用)
ViewModel 类让数据可在发生屏幕旋转等配置更改后继续留存。(特点)
到这里,你可能还是不清楚ViewModel到底是干啥的,别急,往下看。
1.1 出场背景
在详细介绍ViewModel前,先来看下背景和问题点。
-
Activity可能会在某些场景(例如屏幕旋转)销毁和重新创建界面,那么存储在其中的界面相关数据都会丢失。例如,界面含用户信息列表,因配置更改而重新创建 Activity 后,新 Activity 必须重新请求用户列表,这会造成资源的浪费。能否直接恢复之前的数据呢?对于简单的数据,Activity 可以使用 onSaveInstanceState() 方法保存 然后从 onCreate() 中的Bundle恢复数据,但此方法仅适合可以序列化再反序列化的少量数据(IPC对Bundle有1M的限制),而不适合数量可能较大的数据,如用户信息列表或位图。 那么如何做到 因配置更改而新建Activity后的数据恢复呢?
-
UI层(如 Activity 和 Fragment)经常需要通过逻辑层(如MVP中的Presenter)进行异步请求,可能需要一些时间才能返回结果,如果逻辑层持有UI层应用(如context),那么UI层需要管理这些请求,确保界面销毁后清理这些调用以避免潜在的内存泄露,但此项管理需要大量的维护工作。 那么如何更好的避免因异步请求带来的内存泄漏呢?
这时候ViewModel就闪亮出场了——ViewModel用于代替MVP中的Presenter,为UI层准备数据,用于解决上面两个问题。
1.2 特点
具体地,相比于Presenter,ViewModel有以下特点:
1.2.1 生命周期长于Activity
ViewModel最重要的特点是 生命周期长于Activity。来看下官网的一张图:
看到在因屏幕旋转而重新创建Activity后,ViewModel对象依然会保留。 只有Activity真正Finish的时ViewModel才会被清除。
也就是说,因系统配置变更Activity销毁重建,ViewModel对象会保留并关联到新的Activity。而Activity的正常销毁(系统不会重建Activity)时,ViewModel对象是会清除的。
那么很自然的,因系统配置变更Activity销毁重建,ViewModel内部存储的数据 就可供重新创建的Activity实例使用了。这就解决了第一个问题。
1.2.2 不持有UI层引用
我们知道,在MVP的Presenter中需要持有IView接口来回调结果给界面。
而ViewModel是不需要持有UI层引用的,那结果怎么给到UI层呢?答案就是使用上一篇中介绍的基于观察者模式的LiveData。 并且,ViewModel也不能持有UI层引用,因为ViewModel的生命周期更长。
所以,ViewModel不需要也不能 持有UI层引用,那么就避免了可能的内存泄漏,同时实现了解耦。这就解决了第二个问题。
2、ViewModel使用
=============
2.1 基本使用
了解了ViewModel作用解特点,下面来看看如何结合LivaData使用的。(gradle依赖在第一篇中已经介绍过了。)
步骤:
-
继承ViewModel自定义MyViewModel
-
在MyViewModel中编写获取UI数据的逻辑
-
使用LiveData将获取到的UI数据抛出
-
在Activity/Fragment中使用ViewModelProvider获取MyViewModel实例
-
观察MyViewModel中的LiveData数据,进行对应的UI更新。
举个例子,如果您需要在Activity中显示用户信息,那么需要将获取用户信息的操作分放到ViewModel中,代码如下:
public class UserViewModel extends ViewModel {
private MutableLiveData userLiveData ;
private MutableLiveData loadingLiveData;
public UserViewModel() {
userLiveData = new MutableLiveData<>();
loadingLiveData = new MutableLiveData<>();
}
//获取用户信息,假装网络请求 2s后 返回用户信息
public void getUserInfo() {
lo