序
这篇文章之前发过一遍，但是有读者指出来有些地方描述的有问题，我后来再看的时候也觉得有问题，所以把之前的文章删掉(主线是没有问题的，删掉只是是避免更多的人误会)，准备修改勘误之后，再重新发布一遍，这次会补齐描述问题的 Demo 。
有问题继续文章后面留言，再次感谢细心的读者指出文章内的错误。
一、前言
有时候，我们会需要用到 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() 方法，或者原本写在页面布局的 xml 中(实际上也是调用的 addView())，加入到一个 ViewGroup 的时候，才会被调用到。
这就导致，如果你只是通过 new 或者使用 LayoutInflater 创建了一个 View ，而没有将它通过 addView() 加入到 布局视图中去，你通过这个 View.post() 出去的 Runnable ，将永远不会被执行到。 这也就是到了 Api24 下，View.post() 表现的现象不一致的缘故。
三、举个例子说明问题
既然只是复现这个问题，秉承最小改动原则，构造一个最简单的场景，单独 new 一个 View 出来，然后通过它去调用 post() 方法，看看执行的结果。
可以看到，这里直接 new 了一个 View，然后 post 出去了一个 Runnable ，间隔 10s 之后，将这个 View 加入到根布局中。
看看在 Api 23 下的执行效果：
可以看到，在 Api 23一下，这里是 Api19，新 new 出来的 View 对象，post 出去的 Runnable ，会立即得到执行，不需要等待 addView() 的执行。
再来看看在 Api24 下的执行效果：
从执行时间上可以看出来，post 出去的 Runnable ，并不是立即被执行了，而是等到了 addView() 的调用之后，才被执行的，这个中间正好被间隔了 10s。
据说这个问题，在 Android 8.0 上又被修改回去了，专门找了一款 8.0 的设备试试运行结果，如下图：
25 是 Android 8.0 的预览版，这里可以看到，依然是和在 7.0 上的表现一样，会等到最终 addView() 的时候再执行，正式版不知道会不会有所改动，这个还有待验证。
基本上确定，受到影响的是 Android Api 24+，但是依然是开发者需要注意的，毕竟发布出去的 App ，具体运行在什么设备上，这就不是我们能决定的了。
四、小结
View.post() 方法，在不同版本的差异，根本原因还是在于 Api23 和 Api24 中，executeActions() 方法的调用时机不同，导致 View 在没有 mAttachInfo 对象的时候，表现不一样了。
所以我们在使用的过程中需要慎用，区分出实际使用的场景，一般规范自己的代码即可：
动态创建的 View ，如果视条件去决定是否加入到根布局中，则不要使用它来调用 post() 方法。
尽量避免使用 View.post() 方法，可以直接使用 Handler.post() 方法来替代。
【本文为51CTO专栏作者“张旸”的原创稿件，转载请通过微信公众号联系作者获取授权】
戳这里，看该作者更多好文
