Android源码分析之Message

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

准备开始写点东西，算是对自己阅读源码的一个记录/笔记，也希望能对同样感兴趣的人有所帮助，希望能坚持下去，加油。

在Android的开发中，我们经常用到Handler.postXXX方法，或者View.postXXX方法，用来在下一次looper到来时执行。

我是那样的人，什么事情最好能够知道下内部实现机理是什么，否则我在用它的时候可能会觉得不爽，或者说不自然，不太愿意去用。

典型例子就是我始终不太愿意用Android引入的SparseArray<E>，而是一直坚持Java的HashMap<Key, Value>，直到我自己读了

SparseArray<E>的源码，才开始放心大胆的使用（后面会写一篇文章专门分析它）。

首先来看下面的代码：

private Runnable mRunnable = new Runnable() {
@Override
public void run() {
// do something...
removeCallbacks(this);
}
};postDelayed(mRunnable, SOME_DELAY_IN_MILLIMS);

第一直觉告诉我run方法里的removeCallbacks(this);调用显然是多余的。通读代码发现的确是如此，因为任何Message

(即使post的是Runnable也会被包装到Message里)在被处理之前都已经从MessageQueue里取出来了(delete掉了，所以客户端

代码大可不必有这样的代码)。这里顺便提下慎用View.removeCallbacks的返回值，看源码：

/**
* <p>Removes the specified Runnable from the message queue.</p>
*
* @param action The Runnable to remove from the message handling queue
*
* @return true if this view could ask the Handler to remove the Runnable,
* false otherwise. When the returned value is true, the Runnable
* may or may not have been actually removed from the message queue
* (for instance, if the Runnable was not in the queue already.)
*
* @see #post
* @see #postDelayed
* @see #postOnAnimation
* @see #postOnAnimationDelayed
*/
public boolean removeCallbacks(Runnable action) {
if (action != null) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
attachInfo.mHandler.removeCallbacks(action);
attachInfo.mViewRootImpl.mChoreographer.removeCallbacks(
Choreographer.CALLBACK_ANIMATION, action, null);
} else {
// Assume that post will succeed later
ViewRootImpl.getRunQueue().removeCallbacks(action);
}
}
return true;
}

我们可以看到这个方法always返回true，所以不要基于它的返回值做任何事情，还有它的返回值的意义也需要格外留意下。

我在第一次看到这个方法时就自以为然的觉得返回值肯定代表了Runnable action有没有成功地从MessageQueue中移除，true代表成功

移除了，false代表移除失败，呵呵，你想错了。仔细看看方法的doc，人家说的是return true表示这个view可以让它的Handler

去处理这件事情，并没提及处理的结果，而且即使返回true的时候也不能说明Runnable就已经从MessageQueue中移除了，

比如说此时Runnable已经不在MessageQueue中了；其他情况都是返回false。这里顺便看眼View.postDelayed方法:

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

这里不论是postDelayed还是removeCallbacks方法都首先检查了自己的mAttachInfo，如果非空才delegate给attachInfo的Handler

处理，所以你尽量不要过早（mAttachInfo还没初始化完毕）的调用这些方法。比如在早期版本的Android中如果你过早的调用post，

runnable不会被执行，参考这个问题：

http://stackoverflow.com/questions/4083787/runnable-is-posted-successfully-but-not-run；

感兴趣的同学可以在google中搜索view post runnable not run或者自行验证。我现在分析的是Android4.4的源码，依现在的代码来看

即使mAttachInfo是null，也会执行ViewRootImpl.getRunQueue().postDelayed(action, delayMillis); 所以可能在较新的平台上不是

问题（有待考证）。经测试验证确实没问题，即使在Activity.onCreate中调用View.postXXX方法，runnable还是会被执行。

好了说了一大堆了，开始正题。作为开始我今天挑了一个最简单的开始分析，那就是Message.java文件。

其实说白了，Message就是一个数据类，持有data的。基本的数据字段我就不介绍了，都能望文生义。看下几个我觉得有必要的字段：

/*package*/ Handler target; /*package*/ Runnable callback; // sometimes we store linked lists of these things
/*package*/ Message next; private static final Object sPoolSync = new Object();
private static Message sPool;
private static int sPoolSize = 0; private static final int MAX_POOL_SIZE = 50;

target是消息的处理者，在以后Looper.loop()方法中Message被从MessageQueue取出来后会调用msg.target.dispatchMessage(msg);

callback是消息要执行的动作action。这里提前插播下Handler的dispatchMessage方法：

public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}

我们可以看到Handler在分发消息的时候，Message自身的callback优先级高，先被调用如果非空的话（callback的run方法直接被调用）。

next表示消息队列中的下一个Message，类似单链表的概念。

剩下的pool相关的字段都是Message引入的重用（reuse）所要用到的变量，sPoolSync是对象锁，因为Message.obtain方法会在任意

线程调用；sPool代表接下来要被重用的Message对象；sPoolSize表示有多少个可以被重用的对象；MAX_POOL_SIZE显然是pool的上限，

这里hardcode是50。这里我要分析的就2个方法，

obtain和recycle，代码如下：

/**
* Return a new Message instance from the global pool. Allows us to
* avoid allocating new objects in many cases.
*/
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
sPoolSize--;
return m;
}
}
return new Message();
} /**
* Return a Message instance to the global pool. You MUST NOT touch
* the Message after calling this function -- it has effectively been
* freed.
*/
public void recycle() {
clearForRecycle(); synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}

首先我们来看obtain方法，第一次调用也就是说没有什么东西可以重用，这时sPool是null，直接new一个Message对象返回，等到

Message对象使用完毕（在Looper.loop方法最后有msg.recycle();这样的代码），它的recycle会被调用，在recycle里首先会调用

clearForRecycle方法，它只是把各个字段置空或清零。接下来sPoolSize没到上限，next保存下sPool的旧值（也就是在当前Message

回收利用之前上一个要被回收利用的对象），然后sPool被更新成新值，即当前Message，sPoolSize加1，表示又多了一个可以重用的

Message对象。之后在等到obtain被调用的时候就不是直接return一个new Message了，因为我们已经有可以重用的Message对象了。

将sPool的值设置给我们要返回的Message m对象，接着sPool被更新成上一个要被重用的Message对象（相比recycle是反向过程），

最后设置m的next字段为空（m.next会在重新入队列的时候被设置成合适的值），相应的sPoolSize减1，表示可重用的对象少了一个，

最后返回重用的对象m。

基于有这么个回收再利用的机制，Android建议我们调用Message的obtain方法来获取一个Message对象，而不是调用ctor，因为很

可能会省掉分配一个新对象的开销。

到目前为止，我们好像忽略了Message的一个（重要）方面，即异步性，代码如下：

/**
* Sets whether the message is asynchronous.
*
* Asynchronous messages represent interrupts or events that do not require global ordering
* with represent to synchronous messages. Asynchronous messages are not subject to
* the synchronization barriers introduced by {@link MessageQueue#enqueueSyncBarrier(long)}.
*
* @param async True if the message is asynchronous.
*
* @see #isAsynchronous()
* @see MessageQueue#enqueueSyncBarrier(long)
* @see MessageQueue#removeSyncBarrier(int)
*
* @hide
*/
public void setAsynchronous(boolean async) {
if (async) {
flags |= FLAG_ASYNCHRONOUS;
} else {
flags &= ~FLAG_ASYNCHRONOUS;
}
}

看方法的doc，我们知道异步的Message表示那些不需要全局顺序的中断或事件（相比同步Message来说），这里的全局顺序是指

MessageQueue中的先后顺序，而且异步消息的处理不受MessageQueue中引入的enqueueSyncBarrier(long)方法的影响；

具体见MessageQueue的next()方法中有段这样的代码：

Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}

也就是说当我们在队列中遇到一个sync barrier的时候，紧接着的同步Message的处理就会被本次循环忽略，而是直奔下一个

异步的消息。sync barrier是通过MessageQueue中的enqueueSyncBarrier(long when)、removeSyncBarrier(int token)

调用来实现添加、删除的；它们是在android.view.ViewRootImpl执行Traversals相关的代码时被调到的，代码如下：

final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
final TraversalRunnable mTraversalRunnable = new TraversalRunnable(); void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().postSyncBarrier(); // 添加一个sync barrier
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
scheduleConsumeBatchedInput();
}
} void unscheduleTraversals() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().removeSyncBarrier(mTraversalBarrier); // 移除对应的sync barrier
mChoreographer.removeCallbacks(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
}
} void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
mHandler.getLooper().removeSyncBarrier(mTraversalBarrier); // 移除对应的sync barrier if (mProfile) {
Debug.startMethodTracing("ViewAncestor");
} Trace.traceBegin(Trace.TRACE_TAG_VIEW, "performTraversals");
try {
performTraversals();
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
} if (mProfile) {
Debug.stopMethodTracing();
mProfile = false;
}
}
}