View.post() 不靠谱的地方你知道吗？

版权声明：

本账号发布文章均来自公众号，承香墨影（cxmyDev），版权归承香墨影所有。

每周会统一更新到这里，如果喜欢，可关注公众号获取最新文章。

未经允许，不得转载。

一、前言

有时候，我们会需要用到 View.post() 方法，来将一个 Runnable 发送到主线程去执行。这一切，看似很美好，它最终会通过一个 Handler.post() 方法去执行，又避免我们重新定义一个 Handler 对象。

但是，从 Android 7.0（Api level 24）开始，View.post() 将不再那么靠谱了，你 post() 出去的 Runnable ，可能永远也不会有机会执行到。

二、post 在 7.0 的差异

2.1 post 方法的差异

前面提到，这个问题只出现在 Android 7.0 上。那么就先从源码分析 Android 7.0 到底对 View.post() 做了什么改动。

用 Diff 看一下它们的差异，左边是 Api Level 24+（以下简称 Api24）的代码，右边是 Api level 23-（以下简称 Api23）的代码。

很明显的可以看出来，它们只有在 mAttachInfo 为 null 的时候，执行的逻辑才会有差异。

Api24 中，会调用 getRunQueue().post(action)，而 Api23 会调用 ViewRootImpl.getRunQueue().post(action) 方法，他们的差异就在这里。

2.2 Api23 post 的细节

先简单理解一下，ViewRootImpl 是什么。

ViewRootImpl 可以理解是一个 Activity 的 ViewTree 的根节点的实例。每个 ViewRootImpl 就是用来管理 DecorView 和 ViewTree。

ViewRootImpl 中的用来承载 Runnable 的队列是 sRunQueues ，它一个静态的变量，也就是说在 App 的生命周期内，ViewRootImpl 中的这个消息队列都是同一个。

再来看看前面提到的 ViewRootImpl.getRunQueue().post() 到底干了什么？

post() 方法只是单纯的将它包装成一个 HandlerAction 对象，然后放入 mActions 这个 ArrayList 中。继续追查下去就需要知道 mActions 中添加的 HandlerAction 在何时被消费掉了。

消费 HandlerAction 的地方，是 executeActions() 方法。

它最终，还是调用的 handler.postDelayed() ，这没什么好说的，关键点在于 executeAction() 方法，是在什么时候被调用的。

executeAction() 是被 TraversalRunnable 调用 doTraversa() ，在doTraversa() 方法中，进行调用的。而 TraversalRunnable 又是通过 Choreographer.postCallBack() 去循环调用的。这个 Choreographer 通过 doScheduleCallback() 发送一个 MSG_DO_SCHEDULE_CALLBACK 类型的消息循环调用，间隔就是一个 VSync 的间隔。

关于 Choreographer ，不是本文的重点，有兴趣可以单独了解一下。

所以，在 Api23 以下，executeAction() 是会被循环调用，基本上其内的 mActions 只要有未执行的 Runnable 立刻就会被消费掉。

所以在 Api23 以下的设备上，View.post() 基本上是靠谱的，post 出去的 Runnable 都会有机会执行到。

2.3 Api24 的细节

再来看看在 Api24 中的实现细节，在 Api24 中，调用的是 getRunQueue().post() 方法，它操作的是一个 HandlerActionQueue 对象。

内部的结构其实和 Api23 很像，也是维护了一个 HandlerAction 的数组 mActions 。

最终消费掉 mActions 的地方，依然是一个 executeActions() 方法。

回到根本的问题，executeActions() 方法在什么时机会被调用到，继续追查可以看到它在 View.dispatchAttachedToWindow() 方法中，会被调用。

既然，executeActions() 方法，在 Api24 及以上，只会在 dispatchAttachedToWindow() 的方法中，才有机会被调用到，而 View.dispatchAttachedToWindow() 方法，只有在这个 View 通过 addView() 等方法，加入到一个 ViewGroup 的时候，才会被调用到。这就导致写在 Layout 布局中的控件，是不会有机会再调用 addView() 方法的，所以它永远也得不到执行。这也就到时了 Api24 下，View.post() 表现的现象不一致的缘故。

三、小结

View.post() 方法，在不同版本的差异，根本原因还是在于 Api23 和 Api24 中，executeActions() 方法的调用时机不同，导致 View 在没有 mAttachInfo 对象的时候，表现不一样了。

所以我们在使用的过程中需要慎用，区分出实际使用的场景，一般规范自己的代码即可：

在 View 已经被显示出来之后，再调用 View.post() 方法（这个时候 mAttachInfo 已经不为空了）。
尽量避免使用 View.post() 方法，可以直接使用 Handler.post() 方法来替代。