附上官网链接:developer.android.google.cn/topic/libra…
ViewModel简介
该ViewModel
类被设计用来存储和管理UI界面相关的数据生命周期中的意识的方式。ViewModel
类允许生存数据配置更改,如屏幕旋转。
存在的意义 (解决痛点)
1. 数据的持久化
eg: 当系统销毁或重新创建UI控制器(Activity
、fragment
、View
等),则您存储在其中的所有与UI相关的瞬时数据都将丢失。 activity
的onSaveInstanceState()
机制可以用来保存和恢复数据。 缺点:此方法仅适用于可以先序列化然后反序列化的少量数据,不适用于潜在的大量数据,例如用户列表或位图。
生命周期.png
的ViewModel
生命周期可以看到,它的生命周期横跨Activity
的所有生命周期,包括旋转等出现的重新创建的生命周期,直到 Activity
真正意义上销毁后才会结束。这样子数据存储在ViewModel
中时,便可以保证在生命周期中数据不会丢失
2. UI控制器(Activity、fragment等)异步调用,导致的潜在内存泄漏
面对请求网络、读取IO、或者操作数据库等异步操作,有些操作相当耗时,在UI控制器中我们设置这些回调等待结果,有可能在UI控制器销毁的时候才返回。
在ViewModel
中处理数据的回调,当Activity
销毁的时候,ViewModel
也会跑onCleared()清理数据 这样子就不会存在Activity
内存泄漏的问题。
3.分担UI控制器的负担
类似MVP中的P层,MVVM中VM存在意义就是替UI 控制器减轻负担。UI控制器只用于相应用户操作,展示数据,将具体的数据逻辑操作(eg:加载网络、数据库数据...等)放到VM层做处理。分工更加明确,也方便测试。
4.在Fragment之间共享数据
比如Activity
在两或多个Fragment
中,你使用一个Fragment
跟另外的Fragment
通信,常见的操作是定义接口在Activity
中根据接口返回逻辑调用到另外的Fragmet
,也有其他可以用EventBus 广播
等其它的处理方式,但是前者耦合度高,后者也是相对繁琐
在ViewModel
中,你可以获取同一个Activity绑定的ViewModel
并监听数据的变化 进而实现通信 下面是官网的例子
好处:
Activity
不需要知道两者间的交互也不需要做什么,解耦Fragment
不需要判断对方是否存在等问题,也不需要持有对方的引用,不影响本身的任何工作,对其生命周期无感。
重点关注的点!!! 在ViewModel中不要持有Activity的引用在ViewModel中不要持有Activity的引用在ViewModel中不要持有Activity的引用 (重要的事情说三遍,因为生命周期比Activity略长 会导致Activity被挟持!!!) 如果需要
context
对象,可以自行导入Application
的context
官方也提供一个含有context
的ViewModel
的子类,AndroidViewModel
你可以直接继承它
简单使用
- 导入库
- 创建子类继承
ViewModel()
的
- Activity中使用
上面的展示了最基本的使用方式,先获取到
mViewModel
对象,然后ViewModel.currencyName.observe(this, nameObserver)
进行监听Observer<String> { newName -> name_text.text = newName }
当数据改变的时候,便会回调监听的内容,并且传入新的newName
的值
基础封装
下面对基本项目上用到的ViewModel
进行基本的封装 先封装 BaseViewModel
BaseActivity
(以下的封装只涉及ViewModel
,基本的类根据自己的需求进行其他的封装) BaseViewModel
BaseActivity
使用:
构造器有参数的ViewModel
当ViewModel
构造函数带有参数的时候,就不能像上面那种实例化,而是要借助ViewModelProvider
的Fatory
进行实例化
对上面的ViewModel
基础使用改动一波
使用 获取一个ViewModel对象
相比第一次获取实例的方式是调用了ViewModelProvider of(@NonNull FragmentActivity activity, @Nullable Factory factory)
增加多了一个工厂对象其它的数据监听跟基本的不带参数实例化ViewModel
的用法一致
源码跟踪解读
从最开始的ViewModelProviders.of
开始追踪
从上图可以看到ViewModelProviders
主要是用于生成跟返回实例化的ViewModelProvider
对象的。
看最本篇文章简单在Activity
中使用的时候
调用了
可以看到在关键代码2的方法中先是对Activity
进行Application
判空逻辑(关键代码4 ),我们传进来的factory
是空的,则ViewModelProvider.AndroidViewModelFactory.getInstance(application)
(关键代码5)获得一个factory
,再调用 关键代码6 进而返回一个ViewModelProvider
关键代码7 我们传进来的ViewModel
类通过反射的形式创建ViewModel
对象并返回 先跟踪关键代码5进去看看factory
是怎么来的
这里返回了一个单例对象AndroidViewModelFactory
返回上面的 关键代码6 return new ViewModelProvider(activity.getViewModelStore(), factory);
跟踪一下
这里将mViewModelStore
跟mFactory
實例化了 mViewModelStore
是从activity.getViewModelStore()
得到的
看到上面已经生成了ViewModelStore
接下来跟踪一下 ViewModelProviders.of(this).get(NameViewModel::class.java)
的get()
方法看看
上面的代码解释一下:先从mViewModelStore.get(key);
获取出来ViewModel,如果有则返回,没有的话就调用之前拥有的工厂对象mFactory
类去viewModel = (mFactory).create(modelClass)
或者((KeyedFactory) (mFactory)).create(key, modelClass)
,最终调用mViewModelStore.put(key, viewModel);
看到上面的代码了吗? 最终返回的viewModel
,返回前先调用了mViewModelStore.put(key, viewModel)
将这个 viewModel
存到mViewModelStore
中的HashMap
既然mViewModelStore
是存储ViewModel
的地方 那我们也看一下ViewModelStore
中的clear()
是在哪里被调用的
我们跟踪一下ComponentActivity
的
上面可以看到在Lifecycle.Event.ON_DESTROY
为的状态时调用getViewModelStore().clear();
方法。也就说在Activity
的生命周期到onDestory
的时候将本Activity
所有的ViewmModel
清除掉
这篇文章只是对基本的使用到这个调用的开始到结束,进行源码的一个追踪,对
ViewModel
有个比较深刻的印象,里面还有很多细节可以考究,只是本人技术有限,如果读者有没什么疑问可以在评论中说一下~