livedata数据倒灌与粘性事件
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了livedata数据倒灌与粘性事件相关的知识,希望对你有一定的参考价值。
参考技术A 事件发送后,观察者才订阅,订阅后会收到之前的事件。当先订阅,后事件发送,
这里以setValue来分析,会调用dispatchingValue(),注意这里传的是null。
因为initiator为null,所以会走else,然后遍历注册的observer。调用considerNotify().
满足上面判断的条件,最后就会收到onChange()的通知,去做更新UI的操作。
而粘性事件是说先发送数据,再进行订阅,也会收到之前的数据。所以这个时候需要来看observe方法。
会先把observer,和LifecycleOwner封装成LifecycleBoundObserver包装类,接着以Observer为key,新创建的LifecycleBoundObserver为value,存储到mObservers这个map中。在后面LiveData postValue中会遍历出该map的value值ObserverWrapper,获取组件生命周期的状态,已此状态来决定分不分发通知
此处会进入while循环,然后调用dispatchEvent方法,
然后会调用LifeCycleBoundObserver的onStateChanged方法
这里又可以看到熟系的dispatchingValue(),它这里传的是this。然后后前面的流程一样,就可以接收到先前发送的数据。
会出现的场景为:
屏幕旋转
用户手动切换系统语言
下面用屏幕旋转场景来解释。
点击button,给getTestLiveData赋值,然后数值发生变化,上面就会监听到数据的变化,休眠三秒自动跳转到CommonTabLayoutActivity中,然后再返回到MainActivity中,将屏幕旋转,没有点击的操作,三秒过后,又可以看到会自动跳转到CommonTabLayoutActivity中。
这得从生命周期来分析,将屏幕旋转时,其生命周期为:onStop -> onRetainCustomNonConfigurationInstance -> onDestory -> getLastNonConfigurationInstance -> onCreate -> onStart -> onResume,在onCreate的时候会重新创建一个LifecycleBoundObserver实例,LifecycleBoundObserver继承ObserverWrapper,在ObserverWrapper中,会将mLastVersion重新赋值。而调用considerNotify的时候,会将mLastVersion和mVersion做判断。mVersion是在每次setValue或者postValue的时候都会递增。
而新创建的mLastVersion会被重新赋值为-1,小于mVersion,于是将会往下走,调用onChanged回调。
解决方法有四种:
关于LiveData粘性事件所带来问题的解决方案
参考文献:
关于LiveData粘性事件所带来问题的解决方案
Jetpack系列理解LiveData的粘性事件,并去除
文章目录
1. 现象
在使用Jetpack
的LiveData
时,我们经常会遇到所谓的粘性
事件,具体什么是粘性
事件呢?我们可以看一个例子,存在两个Activity
,分别为FirstActivity
和SecondActivity
, 我们在FirstActivity
中先发射了数据,然后进入了SecondActivity
中,在SecondActivity
中监听LiveData
的变化,但是我们会很惊奇的发现,SecondActivity
在FirstActivity
发射之后才注册监听LiveData
的事件,居然也能收到以前的发射数据。这就有些和我们的尝试相悖了,我们一般的常识,是先注册监听事件了才会有事件回调,并且注册事件是不管之前发生的逻辑的。
我们可以看一下具体表现形式:
2. 粘性事件的原理
现在我们可以简单的过一下源码,LiveData
的源码算是比较简单的,基本上能在很短的时间内去掌握的。
对于LiveData
的用法,这里就不详细去讲了,我们直接看一个代码:
private val mLiveData : MutableLiveData<String> = MutableLiveData()
fun sendEvent(content: String)
mLiveData.value = content
直接调用LiveData#setValue()
方法:
@MainThread
protected void setValue(T value)
mVersion++;
mData = value;
dispatchingValue(null);
setValue
主要做了三件事:
- 设置将版本号mVersion + 1, 那么此时mVersion经过++之后,由默认值-1变为了0;
- 将 mData设置为最新值;
- 通知已经注册的监听器,mData已经发生改变,请及时更改。
在dispatchingValue
方法中,我们可以看到参数填的是null
,那么再次进入代码:
void dispatchingValue(@Nullable ObserverWrapper initiator)
// ... 代码省略
for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator
= mObservers.iteratorWithAdditions();
iterator.hasNext(); )
considerNotify(iterator.next().getValue());
if (mDispatchInvalidated)
break;
对于每一个监听器来说,需要走一遍considerNotify
方法:
private void considerNotify(ObserverWrapper observer)
// ... 代码省略
if (observer.mLastVersion >= mVersion)
return;
observer.mLastVersion = mVersion;
observer.mObserver.onChanged((T) mData);
这里有一个判断,如果当前的ObserverWrapper
的版本mLastVersion
大于或者当前的mVersion
,将不会再执行下去,代码直接返回。如果observer.mLastVersion
的版本号小于mVersion
,那么更新版本号,然后调用mObserver.onChanged
回调。
过完了setValue
逻辑,我们再来一下注册事件:
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer)
//... 代码省略
//1.
LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
//2.
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
//3.
owner.getLifecycle().addObserver(wrapper);
同样,在observe
中也同样做了三件事:
- 将我们的Observer封装成LifecycleBoundObserver, 因为需要在Android组件中运行,所以需要设置生命周期的边界;
- 将封装之后的LifecycleBoundObserver保存到 Observers Map集合中;
- 将封装之后的LifecycleBoundObserver添加到Lifecycle组件中,方便监听生命周期事件的变化。
现在我们需要把目光移到LifecycleBoundObserver
源码中,因为已经被LifecycleOwner
添加过,因此在监听到Activity
的生命周期变化时,会触发onStateChanged
方法:
class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event)
Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
Lifecycle.State prevState = null;
while (prevState != currentState)
prevState = currentState;
activeStateChanged(shouldBeActive());
currentState = mOwner.getLifecycle().getCurrentState();
在该方法中,将Lifecycle.State
进行了更新,使得能和宿主LifeCycleOwner
生命周期一致,然后调用activeStateChanged
方法:
void activeStateChanged(boolean newActive)
mActive = newActive;
changeActiveCounter(mActive ? 1 : -1);
if (mActive)
dispatchingValue(this);
我们可以看到,最终还是会调用dispatchingValue
方法,但是此时传入的参数并不是null
,而是ObserverWrapper
自己本身,因此进入:
void dispatchingValue(@Nullable ObserverWrapper initiator)
//代码省略
mDispatchingValue = true;
do
mDispatchInvalidated = false;
if (initiator != null)
considerNotify(initiator);
initiator = null;
while (mDispatchInvalidated);
mDispatchingValue = false;
然后我们进入considerNotify
方法:
private void considerNotify(ObserverWrapper observer)
// 代码省略....
// 条件①
if (observer.mLastVersion >= mVersion)
return;
observer.mLastVersion = mVersion;
observer.mObserver.onChanged((T) mData);
此时,我们可以看到, observer.mLastVersion
是初始值,为-1
, 但是mVersion
由于刚才设置了一次,所以mVersion
现在的值为0,因此条件①不成立,会进入下面的回调阶段,此时就会出现,刚一注册,就会收到上次发射数据的回调。
源码到这里,基本上就流程就走了一遍了。
3. 去掉粘性事件
首先,这个粘性事件并不是Google的一个bug,他们这么写肯定是有他们的作用的。有些特殊情况下我们还是需要粘性事件的。但是对于一般情况下,如果我们想去掉这个粘性事件,应该如何操作呢?
我们使用的是反射去做的,由于分析过源码,其实最容易入手的地方就是 observer.mLastVersion >= mVersion
这个条件了。我们在注册Observer
之后,在宿主下一个生命周期事件到来之前,把我们的Observer
的mLastVesion
强制设置为mVersion
的值就行了。
下面贴一下代码:
public class LiveDataStickinessFixUtils
public static void fixStickiness(MutableLiveData<?> liveData)
try
// 第一步
Field versionField = liveData.getClass().getSuperclass().getDeclaredField("mVersion");
versionField.setAccessible(true);
Integer currentVersion = (Integer) versionField.get(liveData);
if (null == currentVersion)
Log.e("TAG", "live data version is null");
return;
// 第二步
Field mObserversField = liveData.getClass().getSuperclass().getDeclaredField("mObservers");
mObserversField.setAccessible(true);
Iterable iterable = (Iterable) mObserversField.get(liveData);
if (null == iterable)
Log.d("TAG", "live data mObservers is null");
return;
// 第三步
Iterator iterator = iterable.iterator();
while (iterator.hasNext())
Map.Entry entry = (Map.Entry) iterator.next();
Object value = entry.getValue();
Log.d("TAG","show the value:" + value + "," + value.getClass());
Field mLastVersionField = value.getClass().getSuperclass().getDeclaredField("mLastVersion");
mLastVersionField.setAccessible(true);
mLastVersionField.set(value, currentVersion);
catch (Exception e)
e.printStackTrace();
下面来主要介绍这三步的作用:
第一步: 获取到LiveData中的mVersion值,因此这个mVersion值是未知的,所以需要动态获取;
第二步:将LiveData中所有注册的ObserverWrapper监听器统一取出来;
第三步:通过反射,将注册的ObserverWrapper中属性值mLastVersion通过反射设置为mVersion值。
然后在使用:
class SecondLiveDataUI : AppCompatActivity()
override fun onCreate(savedInstanceState: Bundle?)
super.onCreate(savedInstanceState)
setContentView(R.layout.second_live_data_layout)
MyLiveDataManager.findLiveData().observe(this) t -> Toast.makeText(this@SecondLiveDataUI, t, Toast.LENGTH_LONG).show()
LiveDataStickinessFixUtils.fixStickiness(MyLiveDataManager.findLiveData());
在我们设置Observe
监听之后,立即调用我们的LiveDataStickinessFixUtils.fixStickiness
方法即可,然后就可以去掉所谓的粘性事件了。
以上是关于livedata数据倒灌与粘性事件的主要内容,如果未能解决你的问题,请参考以下文章