2.3 LiveData
官方介绍LiveData Overview
包含
LiveData的设计理念
LiveData的优点
-
如何使用LiveData
- 如何创建LiveData对象
- 监听LiveData对象
- 更新LiveData对象
转换LiveData
合并LiveData数据源
额外资源 demos+blogs+videos
添加lifecycle到工程中
2.3.1 理解
官方解释
- LiveData是可被观察的数据持有对象. 不像普通的被观察者,LiveData是对生命周期感知的, 意味着这个对象,会感知和遵守其他的应用组件的生命周期,像Activity,fragments,services. 这种对生命周期状态感知的组件,保证了app的这些观察者的组件,在处理时,都是处在有效的状态.
- LiveData考虑观察者,观察者用Observer表示, 在生命周期状态中,处于STARTED或者RESUMED状态的组件是处于激活状态,LiveData只有通知active的observer,那些inactive的观察者,不会被通知.
- 在注册观察者时,需要把其对应的或者感兴趣的LifeCycleOwner携带着. 在这个配对的Lifecycle处于DESTROYED的状态时,观察者会被移除掉.这种方式对于activity和fragment非常有用,因为有效避免了由于没有反注册导致的内存泄漏
官方解释 : 使用LiveData的优点
- UI与数据状态匹配,不会在UI处于非活跃状态时的动态更新,仅有在活跃状态的observer才会被通知
- 无内存泄漏
- 处于停滞状态的activities不会crash
- 不再需要人工的维护监听组件的生命周期
- 数据会实时更新,例如: 页面从后台到前台时,如果数据有更新,会马上体现出来
- 恰到的页面的configuration changes, 页面方向等更改后,observer会马上获取到最新的数据
- 适当的集成LiveData可以让我们在app内部共享数据
个人理解
- 之前,我们在使用观察者时,是比较简单的, Observable 和Observer, 两者之间结合, 而这样使用时,我们除了给Observable的对象添加Observer外,还需要解除绑定.使用起来并不方便.
- 在大前端中,这些Observer一般是要带来UI的更新的, 但是在注册后,在activity或者fragment处于后台时,这些状态是不应该更新的.而从后台切换到前台时,又需要将数据更新到前端.
- 根据上面描述的两种情况, 我们要可以用一种数据,是对生命状态感知的, 因而可以结合Lifecycle或者说是LifecycleOwner.
具体的案例,请查看Google的官方文档
2.3.2 类图
LiveData 常用的类
-
LiveData
:基础类, 支持了observe时,和生命周期绑定的方式, 并且也支持无生命周期的绑定, observeForever, 另外,可以remove这些observer, 无论是和生命周期绑定的方式还是observeForever的observer.
特别注意:- onActive方法和InActive的方法,当Observer的状态至少有一个是STARTED的状态时,才是onActive的状态, 如果没有一个是STARTED的,那么是InActive; 另外, observeForever的类在注册时,便是Active的状态.
MutableLiveData: 表示此对象可以更改, 可以通过返回值设置值
-
MediatorLiveData: 可以将多个数据源合并为一个数据源, 比较常见的是使用在LiveDataA变化时, 需要再次处理后,返回LiveDataB, 常用的工具类: Transformations的map和switchMap 查看案例, 案例查看后,分析源码
map(@NonNull LiveData source,
@NonNull final Function/** * Applies the given function on the main thread to each value emitted by {@code source} * LiveData and returns LiveData, which emits resulting values. ** The given function {@code func} will be executed on the main thread. *
* Suppose that you have a LiveData, named {@code userLiveData}, that contains user data and you * need to display the user name, created by concatenating the first and the last * name of the user. You can define a function that handles the name creation, that will be * applied to every value emitted by {@code useLiveData}. * *
* LiveData* * @param source a {@code LiveData} to listen to * @param func a function to apply * @paramuserLiveData = ...; * LiveData userName = Transformations.map(userLiveData, user -> { * return user.firstName + " " + user.lastName * }); * a type of {@code source} LiveData * @param a type of resulting LiveData. * @return a LiveData which emits resulting values */ @MainThread public static map(@NonNull LiveData source, @NonNull final Function result = new MediatorLiveData<>(); result.addSource(source, new Observer () { @Override public void onChanged(@Nullable X x) { result.setValue(func.apply(x)); } }); return result; }
方法的目的是将LiveData的X数据,经过Function
***
@NonNull final Function
/**
* Creates a LiveData, let's name it {@code swLiveData}, which follows next flow:
* it reacts on changes of {@code trigger} LiveData, applies the given function to new value of
* {@code trigger} LiveData and sets resulting LiveData as a "backing" LiveData
* to {@code swLiveData}.
* "Backing" LiveData means, that all events emitted by it will retransmitted
* by {@code swLiveData}.
*
* If the given function returns null, then {@code swLiveData} is not "backed" by any other
* LiveData.
*
*
* The given function {@code func} will be executed on the main thread.
*
*
* Consider the case where you have a LiveData containing a user id. Every time there's a new
* user id emitted, you want to trigger a request to get the user object corresponding to that
* id, from a repository that also returns a LiveData.
*
* The {@code userIdLiveData} is the trigger and the LiveData returned by the {@code
* repository.getUserById} is the "backing" LiveData.
*
* In a scenario where the repository contains User(1, "Jane") and User(2, "John"), when the
* userIdLiveData value is set to "1", the {@code switchMap} will call {@code getUser(1)},
* that will return a LiveData containing the value User(1, "Jane"). So now, the userLiveData
* will emit User(1, "Jane"). When the user in the repository gets updated to User(1, "Sarah"),
* the {@code userLiveData} gets automatically notified and will emit User(1, "Sarah").
*
* When the {@code setUserId} method is called with userId = "2", the value of the {@code
* userIdLiveData} changes and automatically triggers a request for getting the user with id
* "2" from the repository. So, the {@code userLiveData} emits User(2, "John"). The LiveData
* returned by {@code repository.getUserById(1)} is removed as a source.
*
*
* MutableLiveData userIdLiveData = ...;
* LiveData userLiveData = Transformations.switchMap(userIdLiveData, id ->
* repository.getUserById(id));
*
* void setUserId(String userId) {
* this.userIdLiveData.setValue(userId);
* }
*
*
* @param trigger a {@code LiveData} to listen to
* @param func a function which creates "backing" LiveData
* @param a type of {@code source} LiveData
* @param a type of resulting LiveData
*/
@MainThread
public static LiveData switchMap(@NonNull LiveData trigger,
@NonNull final Function> func) {
final MediatorLiveData result = new MediatorLiveData<>();
result.addSource(trigger, new Observer() {
LiveData mSource;
@Override
public void onChanged(@Nullable X x) {
LiveData newLiveData = func.apply(x);
if (mSource == newLiveData) {
return;
}
if (mSource != null) {
result.removeSource(mSource);
}
mSource = newLiveData;
if (mSource != null) {
result.addSource(mSource, new Observer() {
@Override
public void onChanged(@Nullable Y y) {
result.setValue(y);
}
});
}
}
});
return result;
}
比较多的应用switchMap的场景是: LiveData A变了, 但是不能从A直接获取到结果数据,需要根据A再次获取到新的LiveDataB,B是可用的结果数据.
但是在实现时, 因为A变了,获取到新的LiveDataB,但是LiveDataB可能是一个变量,因而B是直接不能使用的, 是一个中间变量, 需要引入新的变量,作为结果, 因而根据B生成C作为一个稳定的引用变量, LiveDataA是入参中的trigger, LiveDataB,是实现中的mSource, 而C是实现中的result, 因为trigger的变化和mSource的变化都会带来结果的更改,所以result监听这trigger和mSource,trigger变化时,重新调用func, 生成新的mSource; 而mSource自身也可能变化,自身变化时, 便直接设置给结果result即可
数据源的变化的总结
2.3.3 总结
LiveData 巧妙的结合了Lifecycle, 使其可感知生命周期, 并且自身可被观察, 使其拥有了三个特性
- 充当实际中的POJO, 在View, ViewModel和Model中被使用
- 可感知生命周期, 并且没有内存泄漏
- 充当数据的可被观察对象,变化时,观察者便通过监听,得知变化,更新UI