LiveData大坑之不走回调

前言:

测试大佬突然发现页面上有一块UI在某些情况下无内容展示,但是接口有下发对应字段。这种偶现的bug就很头秃了,排查一波也没发现啥异常,就是个简单的接口请求,然后在LiveData回调中更新UI。这样看来问题出在LiveData了?正好本地也复现了这个问题,疯狂刷新调用接口,UI也没发生变化。

赶紧debug一下,发现LiveData.setValue()此时卡在了dispatchingValue()方法开头处,mDispatchingValue为true,直接return,没有走后续的observer.onChange()回调。mDispatchingValue字段顾名思义,标记正在分发事件,此时继续setValue()不会立即更新。mDispatchingValue是个全局变量,找一下引用发现赋值处全在dispatchingValue()方法中。

    void dispatchingValue(@Nullable ObserverWrapper initiator) {
    
    
        if (mDispatchingValue) {
    
    
            mDispatchInvalidated = true;
            return;
        }
        mDispatchingValue = true;
        do {
    
    
            mDispatchInvalidated = false;
            if (initiator != null) {
    
    
                considerNotify(initiator);
                initiator = null;
            } else {
    
    
                for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
                        mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
    
    
                    considerNotify(iterator.next().getValue());
                    if (mDispatchInvalidated) {
    
    
                        break;
                    }
                }
            }
        } while (mDispatchInvalidated);
        mDispatchingValue = false;
    }

所以说正常流程下mDispatchingValue初始值应该为false,然后在do的入口处置为true,标记正在分发事件,分发事件后跳出循环再次置为fasle。有可能出现问题的地方就在do中的分发事件,considerNotify()就是我们的回调,回调中如果出现异常,mDispatchingValue 就没法在最后重置为false,那么后续的setValue()都会被return掉。

这里有的同学就会问了,LiveData回调中出现异常不就崩溃了吗,崩溃了就能找到问题解决了啊,还哪有后续不分发事件的坑呢。but基础框架大概率会把接口调用整个流程try catch住,我这边用的协程,整个协程体都被try catch住了,所以不会崩溃。然后应该是某个接口字段的问题出现了异常,进而导致后续事件不再分发。

思考了一下,找到接口字段fix掉貌似是个不错的选择,但是吧,我们能相信后端吗?就算和后端大佬遵守了彼此的约定,那我们能保证回调中永远不出现异常吗?回调中的业务代码崩溃了其实也还好,起码能快速定位然后解决,就怕catch住了,然后一脸懵逼不走回调。

先来个兜底方案吧,在你确定回调被catch住不会崩溃进而引发这个bug的时候,不妨自己catch处理。

fun <T> MutableLiveData<T>.safeObserve(owner: LifecycleOwner, onChange: (T) -> Unit) {
    
    
    this.observe(owner) {
    
    
        try {
    
    
            onChange(it)
        } catch (e: Exception) {
    
    
            val field = this::class.java.superclass.getDeclaredField("mDispatchingValue")
            field.isAccessible = true
            field.setBoolean(this, false)
        }
    }
}

思路很简单,发生异常的时候反射将mDispatchingValue置为false即可。本来想吐槽一下谷歌大佬应该在do中try catch住然后在catch块中置为false的,但是吧很不合理,try catch就不会崩,不会崩很难找到问题所在,而且大佬也没想到你会乱用try catch啊。

当然啦,该改的还是要改,具体是哪个字段没下发有可能为空还是要保护一下的。我应该是被data class坑了,解析json反射给字段赋值不会走构造函数的默认值,最好都写成可空类型。

如果你不希望发生崩溃,也不希望LiveData后续永远不走回调,可以尝试上面这个方案。搬砖式的把observe都改为safeObserve也很难受啊,ASM替换一下调用比较舒服,这个没什么难度也就不展开了。ASM统一替换的话不要太暴力,搞个注解啥的做成可配才是王道。

猜你喜欢

转载自blog.csdn.net/u012165769/article/details/122386277

相关文章