Android 自定义View的post(Runnable)方法非100%执行的原因和处理方法解析

最新推荐文章于 2022-05-05 19:24:35 发布

原创

最新推荐文章于 2022-05-05 19:24:35 发布 · 8.6k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#Android #View #Handler #post #Runnable

本文探讨了Android中View.post(Runnable)在特定情况下可能不执行的现象，解释了原理，并提供了确保Runnable执行的解决方案。在View detached状态时，Runnable不会执行，但在重新attached或另一个View的post被调用时，Runnable会执行。解决方案是在View detached期间使用其他方法确保异步任务的执行。

最近在写一个需求，需要在view.post(Runnable)方法当中进行一些操作。但是实际使用中（特定场景）发现并不靠谱。

现象

如果调用了view的post(Runnable)方法，该Runnable在View处于detached状态期间并不会执行；只有当此View或另一个View的view.post()方法被调用，且这个view处于attached状态时（也就是这个Runnable能顺利执行时），前一个post的Runnable才会顺带一块被执行。

原理

一个功能既然一部分能够成功运行，一部分不能够成功运行，那一定是有原因的，那我们来看看View的post方法里面都干了什么：

    public boolean post(Runnable action) {
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            return attachInfo.mHandler.post(action);
        }
        // Assume that post will succeed later
        ViewRootImpl.getRunQueue().post(action);
        return true;
    }

可以看到，post()当中实际使用的是attachInfo的Handler，正好与我们出现问题的场景吻合（其实100%复现问题后找原因就很简单了）。第三行，attachInfo 是否为空进行判断，我们的问题场景明显不符合，因此走到第7行。可以看到仍然是使用的ViewRootImpl这个根View，获取它的RunQueue来post这个这个Runnable。看到第6行这个注释，我们就知道不太妙了：『假设它待会会成功执行』，然后系统默默地返回了true。。。可以看到这里与我们的问题已经完全对应了。

解决方案

从解决问题的角度，分析到这里已经能够形成解决方案了。那么根据View的attach状态，我们只需要在attached过后的detached期间，换用另一种更靠谱的方法弥补这个方法的不足即可。对于