注：本文提到的调用Handler#post，其Handler对象都指的是用UI主线程的Looper创建的Handler对象。
View#post方法的实现跟版本有关，具体为：
- API level 24（Android7.0）及以上：
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
getRunQueue().post(action);
return true;
}
- API level 23及以下：
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;
}
由上可知，两种版本，当attachInfo不为空时，实现是一样的，都是调用attachInfo的Handler对象，往UI主线程的MessageQueue中扔Runnable，这和直接调用Handler#post的效果一样。
当attachInfo为空时，就得分版本来分析了：
- 7.0及其以上是：往HandlerActionQueue中扔Runnable。具体实现为：
首先，调用getRunQueue()获得HandlerActionQueue对象，获取过程很简单，看HandlerActionQueue对象有没有，有就直接返回，没有就new一个再返回。
private HandlerActionQueue getRunQueue() {
if (mRunQueue == null) {
mRunQueue = new HandlerActionQueue();
}
return mRunQueue;
}
然后，调用HandlerActionQueue对象的post方法，再调postDelayed方法（delay 0毫秒），将Runnable对象封装成HandlerAction对象再扔进队列里：
public class HandlerActionQueue {
private HandlerAction[] mActions;
private int mCount;
public void post(Runnable action) {
postDelayed(action, 0);
}
public void postDelayed(Runnable action, long delayMillis) {
// 将Runnable封装成HandlerAction对象
final HandlerAction handlerAction = new HandlerAction(action, delayMillis);
synchronized (this) {
if (mActions == null) {
mActions = new HandlerAction[4];
}
mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
mCount++;
}
}
//省略其他代码
......
}
- 7.0以下是：通过ViewRootImpl获取到的RunQueue，然后往这个队列中扔Runnable。具体实现为：
public final class ViewRootImpl implements ViewParent,
View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
//省略代码
...
static final ThreadLocal sRunQueues = new ThreadLocal();
//省略代码
...
static RunQueue getRunQueue() {
RunQueue rq = sRunQueues.get();
if (rq != null) {
return rq;
}
rq = new RunQueue();
sRunQueues.set(rq);
return rq;
}
//省略代码
...
}
可以发现两个版本主要的不同点在队列对象上。
7.0以下的版本，队列是从一个ThreadLocal对象里面获取到的，也就是说，不同的线程会获取到不同的RunQueue队列对象，且在同一个线程里，队列对象是共享的，大家用一个。
而7.0及以上版本，不管在什么线程里，获取的都是同一个HandlerActionQueue队列对象，且队列对象是属于View实例自己的，自己用自己的，不共享。
再回顾下，AttachInfo为空时，会先将Runnable缓存在一个队列（队列对象在Android7.0版本前后不同）里面，那么什么时候把缓存在队列中的Runnable取出来呢？
答案在ViewRootImpl#performTraversals方法中。
- 7.0及以上：调用了host的dispatchAttachedToWindow方法，这个host就是DecorView对象。
private void performTraversals() {
//省略代码
...
if (mFirst) {
//省略代码
...
host.dispatchAttachedToWindow(mAttachInfo, 0);
//省略代码
...
} else {
//省略代码
...
}
//省略代码
...
}
在DecorView和其父类FrameLayout中都没有重写dispatchAttachedToWindow方法，于是直接去ViewGroup中找dispatchAttachedToWindow的方法实现：
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mGroupFlags |= FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;
super.dispatchAttachedToWindow(info, visibility); //首先，调View的dispatchAttachedToWindow，即通知自身AttachedToWindow
mGroupFlags &= ~FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
final View child = children[i];
child.dispatchAttachedToWindow(info,
combineVisibility(visibility, child.getVisibility())); //然后，调子View的dispatchAttachedToWindow，通知子View AttachedToWindow
}
final int transientCount = mTransientIndices == null ? 0 : mTransientIndices.size();
for (int i = 0; i < transientCount; ++i) {
View view = mTransientViews.get(i);
view.dispatchAttachedToWindow(info,
combineVisibility(visibility, view.getVisibility()));
}
}
这样，从父View到子View，通过深度优先遍历，将AttachToWindow这个事儿传遍View树。
在View的dispatchAttachedToWindow中，终于将缓存在RunQueue中的Runnable取出来了，通过AttachInfo的Handler扔到UI线程的MessageQueue中，等待被执行。
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
//省略代码
...
// Transfer all pending runnables.
if (mRunQueue != null) {
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
//省略代码
...
}
- 7.0以下，通过之前的分析我们知道，那个缓存队列是通过ViewRootImpl的一个静态方法getRunQueue()去获取的。这里同样调用getRunQueue()方法获取对应线程的缓存队列，然后调用executeActions()方法将缓存在队列中的Runnable取出来，最后同样是通过AttachInfo的Handler往主线程的MessageQueue中扔：
private void performTraversals() {
//省略代码
...
// Execute enqueued actions on every traversal in case a detached view enqueued an action
getRunQueue().executeActions(mAttachInfo.mHandler);
基于AttachInfo为空这个大前提下，值得注意的一点是，如果是在子线程调用的View#post，那么Runnable是往子线程的缓存队列里扔的，而ViewRootImpl#performTraversals是在主线程中被执行的，
getRunQueue()取的是主线程对应的缓存队列，这是两个不同的缓存队列实例，因此Runnable当然不会被执行了。
总结：
-
如果view已经attach到window了，那么View#post和Handler#post作用一样，都是往调用UI主线程的MessageQueue中扔Runnable。
-
如果view还未attach到window中，则需要通过一个缓存队列将Runnable暂时先缓存起来，等到view attach到window上之后，再将缓存队列中的Runnable取出来，再扔到UI线程的MessageQueue中，此时：
- 如果是在主线程调用的View#post，那么在各个Android版本上都没问题，都会在ViewRootImpl的下一次performTraversal()是被执行；
- 如果是在非主线程调用的View#post，就得分版本考虑：
1)如果是在Android7.0及以上版本，没毛病。缓存队列用的是各个View对象实例自己的，跟线程没关系，通过ViewRootImpl#performTraversal方法，最后会把各个View的缓存队列中的Runnable都扔到主线程消息队列MessageQueue中，等待被执行。
2)如果是在Android7.0以下版本，就悲剧了。缓存队列是从ViewRootImpl中的一个ThreadLocal静态变量里获取的，各个线程取到的是不同的RunQueue对象实例，子线程是往子线程自己的RunQueue队列中扔Runnable，ViewRootImpl#performTraversal是在主线程中被执行，取的是主线程的RunQueue队列，于是你在子线程post的Runnable就没法被执行了。
reference: 两者区别