Android LiveData粘性,粘连,倒灌

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android LiveData粘性,粘连,倒灌相关的知识,希望对你有一定的参考价值。

参考技术A 工作机制:每次改变LiveData数据都会对数据版本号加1,并触发版本号小于数据版本号的观察者监听,触发后观察者的版本号与数据版本号一致。

粘性事件:更新数据后,观察者再订阅,新注册的观察者版本号为-1小雨数据版本号,所以注册时会触发一次数据监听。

数据粘连:LiveData的激活状态标识,会在对应的LifecyOwner执行onStart后设置为true,执行onDestroy后设置为false,在未激活状态下无论发生多少次改变,只有最后一次数据会发送给观察者。

数据倒灌:由于LiveData的激活状态标识先变为false,再变为true,导致触发小于数据版本号的所有观察者的监听。常见场景为:使用ViewModel持有LivaData,并在生命周期内创建监听对象,则在Activity由于屏幕翻转等配置变化引发onDestroy时,ViewModel不会执行clear,因此保留了内部的LiveData,而在生命周期内重新创建监听对象的版本号为-1,所以在onStart之后会触发观察者监听。

解决方案:
1.修改version
2.复写LiveData
3.包装事件,事件内带处理状态

2022-04-11

Jetpack系列理解LiveData的粘性事件,并去除

文章目录

1. 现象

在使用JetpackLiveData时,我们经常会遇到所谓的粘性事件,具体什么是粘性事件呢?我们可以看一个例子,存在两个Activity,分别为FirstActivitySecondActivity, 我们在FirstActivity中先发射了数据,然后进入了SecondActivity中,在SecondActivity中监听LiveData的变化,但是我们会很惊奇的发现,SecondActivityFirstActivity发射之后才注册监听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主要做了三件事:

  1. 设置将版本号mVersion + 1, 那么此时mVersion经过++之后,由默认值-1变为了0;
  2. 将 mData设置为最新值;
  3. 通知已经注册的监听器,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中也同样做了三件事:

  1. 将我们的Observer封装成LifecycleBoundObserver, 因为需要在Android组件中运行,所以需要设置生命周期的边界;
  2. 将封装之后的LifecycleBoundObserver保存到 Observers Map集合中;
  3. 将封装之后的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之后,在宿主下一个生命周期事件到来之前,把我们的ObservermLastVesion强制设置为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方法即可,然后就可以去掉所谓的粘性事件了。

以上是关于Android LiveData粘性,粘连,倒灌的主要内容,如果未能解决你的问题,请参考以下文章

对 Android 的 LiveData 网传的数据倒灌做一个深层次的解释

对 Android 的 LiveData 网传的数据倒灌做一个深层次的解释

对 Android 的 LiveData 网传的数据倒灌做一个深层次的解释

Activity销毁重建导致LiveData数据倒灌

Jetpack系列理解LiveData的粘性事件,并去除

Jetpack系列理解LiveData的粘性事件,并去除