在上篇Handler源码分析中遗留了一个问题，就是Handler的延迟发送消息的机制是怎么实现的。本次想继续分析这个问题，并增加一些平常再用handler的时候应该注意的问题。附上篇链接。
Handler的Message延迟机制
上次说到在Handler中，首先我们脑海里要有以下几个点。
- handler既可以发送一个普通Message消息，也可发送一个Runnable对象.
- 不管是Runnable对象还是普通message对象，最后都会在handler中被封装成一个Messge。
- 所有的Message对象最终都会通过handler的enqueueMessage()方法，将一条message排列到消息队列中。而该方法内部实际调用的是MessgeQueue的 enqueueMessage(msg, uptimeMillis);方法。
- enqueueMessage()方法的返回值代表是否被
可以注意到的是方法参数中传入了所需进行排列的msg对象，还传入了一个时间uptimeMillis。那么这个时间是不是和handler的延迟执行有关联呢？我们继续分析。
// 返回值boolean
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
- 探查uptimeMills.
通常来说，我们发送Messge对象分为延迟msg与不延迟msg，延迟多久我们就会在相应传参数中传上相应的延迟时间，比如delayMillis=1000ms,delayMillis=2000ms，delayMillis=3000ms等等，当我们msg不设置延迟时间，那么传入的delayMillis在hanlder内部会默认为0，如果我们传入小于0的数那么也会在handler中被修正为0ms延迟。最终传入进 enqueueMessage(msg, uptimeMillis); 方法中的uptimeMillis实际上是SystemClock.uptimeMillis()+0或者SystemClock.uptimeMillis() + delayMillis，单位为毫秒。
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
值得注意的是SystemClock.uptimeMillis()，不是指我们经常用的System.currentTimeMillis()， SystemClock.uptimeMillis()指的是从系统启动以来的毫秒计数值，当系统进入深度睡眠（比如CPU关闭，显示黑暗，设备等待外部输入）时，此时钟停止。这是大多数间隔计时的基础，例如 {@Thread.sleep(millls)}, {@lObject.wait(millis)}, {@link System.nanoTime()}.。
Message如何排队
- 探查MessageQueue的enqueueMessage（）方法
boolean enqueueMessage(Message msg, long when) {
1. if (msg.target == null) {
2. throw new IllegalArgumentException("Message must have a target.");
3. }
4. if (msg.isInUse()) {
5. throw new IllegalStateException(msg + " This message is already in use.");
6. }
7. synchronized (this) {
8. if (mQuitting) {
9. IllegalStateException e = new IllegalStateException(
10. msg.target + " sending message to a Handler on a dead thread");
11. Log.w(TAG, e.getMessage(), e);
12. msg.recycle();
13. return false;
14. }
15. msg.markInUse();
16. msg.when = when;
17. Message p = mMessages;
18. boolean needWake;
19. if (p == null || when == 0 || when < p.when) {
20. // New head, wake up the event queue if blocked.
21. msg.next = p;
22. mMessages = msg;
23. needWake = mBlocked;
24. } else {
25. // Inserted within the middle of the queue. Usually we don't have to wake
26. // up the event queue unless there is a barrier at the head of the queue
27. // and the message is the earliest asynchronous message in the queue.
28. needWake = mBlocked && p.target == null && msg.isAsynchronous();
29. Message prev;
30. for (;;) {
31. prev = p;
32. p = p.next;
33. if (p == null || when < p.when) {
34. break;
35. }
36. if (needWake && p.isAsynchronous()) {
37. needWake = false;
38. }
39. }
40. msg.next = p; // invariant: p == prev.next
41. prev.next = msg;
42. }
43. // We can assume mPtr != 0 because mQuitting is false.
44. if (needWake) {
45. nativeWake(mPtr);
46. }
47. }
48. return true;
}
可以看到在第16行。将经过换算好的时间uptimeMillis对应传给了此时需要插入MessageQueue队列的msg.when。
此时不得不再提一下Message类;一个Message对象除了包含着数据信息外，同样在内部有个next 节点，此节点也是Message类型。而这个next节点在本处的enqueueMessage起着至关重要的作用。我们可以把一个MessageQueue看成一个单向链表，链表中的每个节点就是一个Message对象,每个子节点Message的next节点都指向了下一条子Message节点,直到最后一个message的next节点的指向为null.
在MessageQueue中有个全局Message对象为mMessage,我在此暂且称之为头结点。
可以发现在17行Message p=mMessage; 定义了一个局部p变量,相当于mMessage。
①当我们还未通过handler发送一个消息到消息队列的时候，mMessage为null,我将此认为此时消息队列的节点个数为1。
②如果我们发送一个message到消息队列，就会使19行的条件为true.随后经过21行和22行后，将我们传入的这个msg对象设为头结点，并将next节点指向null;此时消息队列节点个数为2。
③经过步骤②后，我们再次传入一个mssage对象，此时19行的p=null条件不成立了，就会进行时间判断。当传入的msg的when小于此时头结点的when,或者等于0 (此情况很少但还是有，比如我们通过handler的sendEmptyMessageAtTime（）方法传入), 那么条件再次成立。会将此条message设为新的头结点并将next节点指向之前的头结点。此时消息队列节点个数为3.
④在步骤③的时候如果19行的条件判断都不成立，也就是新传入的msg的when时间是大于消息队列头结点的msg的when时间。那么就会进入24行的代码块，可以看见代码块内部有个for循环，在满足33行的条件后，跳出循环。意思是新传入的msg的when时间会依次会和next节点的when去对比，直到满足msg的when时间小于next节点的when,或者next节点为null。
总之，重复经过如上的步骤之后。消息队列将是一条Message形成的链表，并且头结点至尾结点的时间从小到大递增。最后一个有效结点的next节点始终为null
关于这一块的文字描述，后续的话我想配上图片。
上面分析了如何将消息进行排队。继续分析如何从消息队列取出的
Message如何取出
首先，我们需要知道一点
- Looper.loop方法中，去拿到一个msg消息的时候，是调用MssageQueue的next方法去拿到一个Message.
- 探查MessageQueue的next方法。代码如下。
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// Try to retrieve the next message. Return if found.
1. final long now = SystemClock.uptimeMillis();
2. Message prevMsg = null;
3. Message msg = mMessages;
4. if (msg != null && msg.target == null) {
5. // Stalled by a barrier. Find the next asynchronous message in the queue.
6. do {
7. prevMsg = msg;
8. msg = msg.next;
9. } while (msg != null && !msg.isAsynchronous());
10. }
11. if (msg != null) {
12. if (now < msg.when) {
13. // Next message is not ready. Set a timeout to wake up when it is ready.
14. nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
15. } else {
16. // Got a message.
17. mBlocked = false;
18. if (prevMsg != null) {
19. prevMsg.next = msg.next;
20. } else {
21. mMessages = msg.next;
22. }
23. msg.next = null;
24. if (DEBUG) Log.v(TAG, "Returning message: " + msg);
25. msg.markInUse();
26. return msg;
27. }
28. } else {
29. // No more messages.
30. nextPollTimeoutMillis = -1;
31. }
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
上面代码我只给主要行编了行号。在第1行开始，可以看见通过SystemClock.uptimeMillis();取出了一个时间now。
我们目前知道的是msg不为null时，msg.target肯定不会为null,直接跳到11行的判断，如果now时间是小于当前msg的when,则说明下一条message还未准备好，就不会取出message，那么handler也就暂时收不到消息，这很好的解释了延迟执行。
如果已经准备好，也就是now>msg.when,此时由于未执行4-10的代码段，随意18行的条件为false,从而执行第21行，此行的意思就是将消息队列的头结点指向头结点所指向的next结点，也就是下一条message从新成为新的头结点。同时在第26行返回此次取出的这个头结点msg。
总结
1.在对Message消息进行排列的时候，会去比较传入的msg与已在消息队列里面的Mssage进行时间比较。
2.消息队列的是由一系列Message按时间从小到大排列的单向不循环链表，最后一个Message的Next节点为null.
3.在从消息队列取出消息的时候会去做SystemClock.uptimeMillis()与当前头结点mMessage.when做比较，如果未达到when,则不取出消息，否者就会取出消息。
4.从消息队列取出消息的时候，每次都取头结点的Message.
遗留问题：
对于Handler的延迟机制大概上如之前描述所说，但还有一些在之前方法中出现的成员还需要分析。
handler与Android组件之间的关系。
