解决LiveData数据倒灌的新思路

数据倒灌现象

对于LiveData“数据倒灌”的问题,我相信很多人已经都了解了,这里提一下。所谓的“数据倒灌”:其实是类似粘性广播那样,当新的观察者开始注册观察时,会把上次发的最后一次的历史数据传递给当前注册的观察者

比如在在下面的例子代码中:

val testViewModel = ViewModelProvider(this)[TestViewModel::class.java]
testViewModel.updateData("第一次发送数据")
testViewModel.testLiveData.observe(this,object :Observer<String>{
    override fun onChanged(value: String) {
        println("==============$value")
    }
})

updateData方法发送了一次数据,当下面调用LiveData的observe方法时,会立即打印==============第一次发送数据,这就是上面说的“数据倒灌”现象。

发生原因

原因其实也很简单,其实就是 LiveData内部有一个mVersion字段,记录版本,其初始的 mVersion 是-1,当我们调用了其 setValue 或者 postValue,其 mVersion+1;对于每一个观察者的封装 ObserverWrapper,其初始 mLastVersion 也为-1,也就是说,每一个新注册的观察者,其 mLastVersion 为-1;当 LiveData 设置这个 ObserverWrapper 的时候,如果 LiveDatamVersion 大于 ObserverWrappermLastVersionLiveData 就会强制把当前 value 推送给 Observer

也就是下面这段代码

    private void considerNotify(ObserverWrapper observer) {
        if (!observer.mActive) {
            return;
        }

        if (!observer.shouldBeActive()) {
            observer.activeStateChanged(false);
            return;
        }
        // 判断observer的版本是否大于LiveData的版本mVersion
        if (observer.mLastVersion >= mVersion) {
            return;
        }
        observer.mLastVersion = mVersion;
        observer.mObserver.onChanged((T) mData);
    }

所以要解决这个问题,思路上有两种方式:

  • 通过改变每个ObserverWrapper的版本号的值
  • 通过某种方式,保证第一次分发不响应

解决方法

目前网络上可以看到有三种解决方式

每次只响应一次

public class SingleLiveData<T> extends MutableLiveData<T> {
    private final AtomicBoolean mPending = new AtomicBoolean(false);

    public SingleLiveData() {
    }

    public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
        super.observe(owner, (t) -> {
            if (this.mPending.compareAndSet(true, false)) {
                observer.onChanged(t);
            }

        });
    }

    @MainThread
    public void setValue(@Nullable T t) {
        this.mPending.set(true);
        super.setValue(t);
    }

    @MainThread
    public void call() {
        this.setValue((Object)null);
    }
}

这个方法能解决历史数据往回发的问题,但是对于多Observe监听就不行了,只能单个监听,如果是多个监听,只有一个能正常收到,其他的就无法正常工作

反射

这种方式就是每次注册观察者时,通过反射获取LiveData的版本号,然后又通过反射修改当前Observer的版本号值。这种方式的优点是:

  • 能够多 Observer 监听
  • 解决粘性问题

但是也有缺点:

  • 每次注册 observer 的时候,都需要反射更新版本,耗时有性能问题

UnPeekLiveData

public class UnPeekLiveData extends LiveData {

    protected boolean isAllowNullValue;

    private final HashMap observers = new HashMap();

    public void observeInActivity(@NonNull AppCompatActivity activity, @NonNull Observer super T> observer) {
        LifecycleOwner owner = activity;
        Integer storeId = System.identityHashCode(observer);
        observe(storeId, owner, observer);
    }

    private void observe(@NonNull Integer storeId,
                         @NonNull LifecycleOwner owner,
                         @NonNull Observer super T> observer) {

        if (observers.get(storeId) == null) {
            observers.put(storeId, true);
        }

        super.observe(owner, t -> {
            if (!observers.get(storeId)) {
                observers.put(storeId, true);
                if (t != null || isAllowNullValue) {
                    observer.onChanged(t);
                }
            }
        });
    }

    @Override
    protected void setValue(T value) {
        if (value != null || isAllowNullValue) {
            for (Map.Entry entry : observers.entrySet()) {
                entry.setValue(false);
            }
            super.setValue(value);
        }
    }

    protected void clear() {
        super.setValue(null);
    }
}

这个其实就是上面 SingleLiveData 的升级版,SingleLiveData 是用一个变量控制所有的 Observer,而上面采用的每个 Observer 都采用一个控制标识进行控制。 每次 setValue 的时候,就打开所有 Observer 的开关,表示可以接受分发。分发后,关闭当前执行的 Observer 开关,即不能对其第二次执行了,除非你重新 setValue。 这种方式基本上是比价完美了,除了内部多一个用HashMap存放每个Observer的标识,如果Observer比较多的话,会有一定的内存消耗。

新的思路

我们先看下LiveData获取版本号方法:

int getVersion() {
    return mVersion;
}

这个方法是一个包访问权限的方法,如果我新建一个和LiveData同包名的类,是不是就可以不需要反射就能获取这个值呢?其实这是可行的

// 跟LiveData同包名
package androidx.lifecycle

open class SafeLiveData<T> : MutableLiveData<T>() {

    override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
        // 直接可以通过this.version获取到版本号
        val pictorialObserver = PictorialObserver(observer, this.version > START_VERSION)
        super.observe(owner, pictorialObserver)
    }

    class PictorialObserver<T>(private val realObserver: Observer<in T>, private var preventDispatch: Boolean = false) :
        Observer<T> {

        override fun onChanged(value: T) {
            // 如果版本有差异,第一次不处理
            if (preventDispatch) {
                preventDispatch = false
                return
            }
            realObserver.onChanged(value)
        }

    }
}

这种取巧的方式的思路就是:

  • 利用同包名访问权限可以获取版本号,不需要通过反射获取
  • 判断LiveDataObserver是否有版本差异,如果有,第一次不响应,否则就响应

我个人是偏向这种方式,也应用到了实际的开发中。这种方式的优点是:改动小,不需要反射,也不需要用HashMap存储等,缺点是:有一定的侵入性,假如后面这个方法的访问权限修改或者包名变动,就无效了,但是我认为这种可能性是比较小,毕竟androidx库迭代了这么多版本,算是比较稳定了。

如果你看到了这里,觉得文章写得不错就给个赞呗?
更多Android进阶指南 可以扫码 解锁更多Android进阶资料


1、《Android性能优化实战篇》
2、《音视频精编源码解析》
3、24种设计模式介绍与6大设计原则
4、360°全方面性能调优
5、2021最新版数据结构与算法面试题手册 1
6、2023年Android中高级最全面试真题答案解析
7、Android Compose 强化实战
8、Android Framework 源码开发揭秘(2)
9、Android Jetpack Compose开发应用指南第三版
10、Android 音视频开发进阶指南-无水印(1)
11、Android车载操作系统开发揭秘
12、Android车载系统应用指南(1)
13、Android多媒体应用开发实战详解:图像、音频、视频、2D和3D-2
14、Android高级UI开源框架进阶解密(1)无水印版
15、Android源码解析(1)
16、Flutter技术解析与实战
17、Flutter技术进阶
18、Flutter入门与实战 无水印
19、Flutter完整开发实战详解
20、Jetpack架构组件从入门到精通
21、KMM跨平台框架入门教程无水印
22、Kotlin 入门教程指南(1)
23、kotlin从入门到精通
24、高级Android插件化强化实战(附源码)
25、高级Android组件化强化实战(附源码)
26、高级Jetpack强化实战
27、高级Kotlin强化实战(附Demo)
28、鸿蒙零基础入门学习指南
29、史上最详android版kotlin协程入门进阶实战指南
30、音视频开发教程(附面试题)
敲代码不易,关注一下吧。ღ( ´・ᴗ・` )

  • 14
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值