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

最近在写一个需求，需要在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期间，换用另一种更靠谱的方法弥补这个方法的不足即可。对于异步但不要求delay的Runnable，直接执行即可：

if(mAttached) {
post(r);
} else {
r.run();
}

其中r是我自己new出来的Runnable变量。如果仍然期待使用post()达到的效果拒绝立即同步调用，也可以换用Handler，代码也都相当简单：

if(mAttached) {
post(r);
} else {
Handler handler = new Handler();
handler.post(r);
}

mAttached是自行维护的一个变量，等价于View的：

isAttachedToWindow()

，只是该api较高，通常为了兼容于是自行维护该状态。维护的代码如下：

@Override
protected void onAttachedToWindow() {
super.onAttachedToWindow();
mAttached = true;
}

@Override
protected void onDetachedFromWindow() {
mAttached = false;
super.onDetachedFromWindow();
}

是不是很简单。当一个问题能100%复现后，其解决方案总是很简单。

[b]浅析深入原理[/b]

只是解决问题，到上面的部分就可以结束了。但作为一个原理，我们还是希望继续深入了解一下Android对post()这些机制的处理，那么我们继续深挖刚才看到的RunQueue的代码，至少能够把我们的好奇心说服为止。来看看ViewRootImpl.GetRunQueue()的方法：

static RunQueue getRunQueue() {
RunQueue rq = sRunQueues.get();
if (rq != null) {
return rq;
}
rq = new RunQueue();
sRunQueues.set(rq);
return rq;
}

可以发现，只是一个相对简单的get方法，存在了sRunQueues里。那么这个RunQueue是个啥Queue，我们来看一下这个RunQueue类型的说明。

/**
* The run queue is used to enqueue pending work from Views when no Handler is
* attached.  The work is executed during the next call to performTraversals on
* the thread.
* @hide
*/
static final class RunQueue {
private final ArrayList<HandlerAction> mActions = new ArrayList<HandlerAction>();

void post(Runnable action) {
postDelayed(action, 0);
}

void postDelayed(Runnable action, long delayMillis) {
HandlerAction handlerAction = new HandlerAction();
handlerAction.action = action;
handlerAction.delay = delayMillis;

synchronized (mActions) {
mActions.add(handlerAction);
}
}

void executeActions(Handler handler) {
synchronized (mActions) {
final ArrayList<HandlerAction> actions = mActions;
final int count = actions.size();

for (int i = 0; i < count; i++) {
final HandlerAction handlerAction = actions.get(i);
handler.postDelayed(handlerAction.action, handlerAction.delay);
}

actions.clear();
}
}

private static class HandlerAction {
Runnable action;
long delay;
...
}
}

这里只包括了主要的变量和方法。RunQueue是ViewRootImpl.class的一个内部静态类，可以看到这个队列是用一个叫做mActions的ArrayList实现的，元素就是一个Runnable（系统叫做action）和一个delay时间组成的对象。对于我们从使用角度理解原理，注释已经把把该类的功能进行了一个概括：
『这个运行队列用于在没有Handler attached时，把来自View的即将运行的工作加入此队列。这个工作会此此线程下次调用遍历时执行。』

这个代码较多，再精简来看一下我们在post时会调用的runQueue.post(Runnable)方法：

void post(Runnable action) {
postDelayed(action, 0);
}

首先调用到postDelayed(Runnable, long)，再看看实现：

void postDelayed(Runnable action, long delayMillis) {
HandlerAction handlerAction = new HandlerAction();
handlerAction.action = action;
handlerAction.delay = delayMillis;

synchronized (mActions) {
mActions.add(handlerAction);
}
}

可以看到new了一个HandlerAction包装我们传入的action，并添加到mActions中。什么？整个方法竟然就只是add到了一个List中。没错，这和我们之前观察的现象是完全一致的。调用了post()，但并没有执行。这些Runnable对象，会在excuteActions当中会执行：

void executeActions(Handler handler) {
synchronized (mActions) {
final ArrayList<HandlerAction> actions = mActions;
final int count = actions.size();

for (int i = 0; i < count; i++) {
final HandlerAction handlerActi
93f0
on = actions.get(i);
handler.postDelayed(handlerAction.action, handlerAction.delay);
}

actions.clear();
}
}

而在什么时机调用的呢？在performTraversals当中，会调用该方法，执行加入队列的操作如果有detached的view往队列里加入过action。action就是我们传入的Runnable对象。使用的Handler仍然是attachInfo的Handler，可以知道原理和view.post(Runnable)当中的前面那段的逻辑一致，也就是说相当于做了一个暂停，并在合适的时机再执行。执行时的调用实现都是一致的。

private void performTraversals() {

...

// Execute enqueued actions on every traversal in case a detached view enqueued an action
getRunQueue().executeActions(mAttachInfo.mHandler);

...

}

总结

至此，我们已经了解清楚，View在执行post(Runnable)方法时，会使用attachInfo中的mHandler；而在没有attachedInfo时，会使用一个RunQueue暂时装载着Runnable对象而不会立即执行；在进行遍历时，会用新的attachInfo的Handler执行这个Runnable对象。这与我们观察到的现象，以及使用的解决方法是一致的。

如果有需要一定执行同时又使用view.post(Runnable)实现时，留心一下post(Runnable)调用时View的生命周期，避免实际执行时机与顺序与预期的不一致。