Android Framework | 消息机制的冷门知识点，你能答出来几个？_drained android

作为Android的基础知识，消息机制已被无数人写过。笔者曾经也写过一篇深入分析的文章，但总体而言乏善可陈，并无新颖之处。最近恰好重新整理了一下思路，想着可以从细节的角度出发，对一些冷门的知识点做一个归纳。记录于此，供大家批评讨论。

本文所有代码基于Android Q (10.0)

1. 哪个消息在前？哪个消息在后？

假设线程1此时正在处理一个消息，线程2通过如下方式（方式Ⅰ）往线程1的消息队列中插入两个消息。请问消息A和消息B哪个先被处理呢？

handler.sendMessage(msgA);
handler.sendMessage(msgB);
1
2

那如果是通过下面这种方式（方式Ⅱ），消息A和消息B又是哪个先被处理呢？

handler.sendMessageAtFrontOfQueue(msgA);
handler.sendMessageAtFrontOfQueue(msgB);
1
2

答案是通过方式Ⅰ发送时，消息A先被处理；通过方式Ⅱ发送时，消息B先被处理。具体解释如下：

/frameworks/base/core/java/android/os/Handler.java

746      private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
747              long uptimeMillis) {
748          msg.target = this;
749          msg.workSourceUid = ThreadLocalWorkSource.getUid();
750  
751          if (mAsynchronous) {
752              msg.setAsynchronous(true);
753          }
754          return queue.enqueueMessage(msg, uptimeMillis);
755      }
1
2
3
4
5
6
7
8
9
10

Handler类中所有的sendMessage方法，最终都是调用MessageQueue.enqueMessage方法将消息加入到队列之中。调用时传入两个参数：msg和uptimeMillis。msg自然是想要发送的消息，而uptimeMillis则是消息预计发送的时间。

SystemClock.uptimeMillis(): Returns milliseconds since boot, not counting time spent in deep sleep.

1.1 当我们调用sendMessage发送消息时

/frameworks/base/core/java/android/os/Handler.java

610      public final boolean sendMessage(@NonNull Message msg) {
611          return sendMessageDelayed(msg, 0);
612      }
1
2
3

669      public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
670          if (delayMillis < 0) {
671              delayMillis = 0;
672          }
673          return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
674      }
1
2
3
4
5
6

695      public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
696          MessageQueue queue = mQueue;
697          if (queue == null) {
698              RuntimeException e = new RuntimeException(
699                      this + " sendMessageAtTime() called with no mQueue");
700              Log.w("Looper", e.getMessage(), e);
701              return false;
702          }
703          return enqueueMessage(queue, msg, uptimeMillis);
704      }
1
2
3
4
5
6
7
8
9
10

最终传入MessageQueue.enqueMessage的uptimeMillis是sendMessageDelayed中临时获取的当下时间。当消息B获取到的uptime大于A时，B在队列中必然插入到A的后面。但是由于uptimeMillis的单位是毫秒，所以A和B完全可能获取到一样的uptimeMillis（在一毫秒内完成两次消息发送的动作）。如果二者的uptimeMillis一样，那么他们的顺序又该怎么排列呢？

/frameworks/base/core/java/android/os/MessageQueue.java#enqueueMessage

569              if (p == null || when == 0 || when < p.when) {
570                  // New head, wake up the event queue if blocked.
571                  msg.next = p;
572                  mMessages = msg;
573                  needWake = mBlocked;
574              } else {
575                  // Inserted within the middle of the queue.  Usually we don't have to wake
576                  // up the event queue unless there is a barrier at the head of the queue
577                  // and the message is the earliest asynchronous message in the queue.
578                  needWake = mBlocked && p.target == null && msg.isAsynchronous();
579                  Message prev;
580                  for (;;) {
581                      prev = p;
582                      p = p.next;
583                      if (p == null || when < p.when) {
584                          break;
585                      }
586                      if (needWake && p.isAsynchronous()) {
587                          needWake = false;
588                      }
589                  }
590                  msg.next = p; // invariant: p == prev.next
591                  prev.next = msg;
592              }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

一个消息若是加入到队列中来，只可能是两种情况：

• 消息加入到队列头部。
• 消息加入到别的消息后面。

对于第一种情况，假设A先加入到队列头部，只有当B的when（uptime）小于A的when时，B才会加入到A的前面；对于第二种情况，同样是只有B的when小于A的when时，B才会加入到A的前面。当B的when和A相等时，B只会加入到A的后面。因此，A先被处理。

1.2 当我们调用sendMessageAtFrontOfQueue发送消息时

/frameworks/base/core/java/android/os/Handler.java

718      public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg) {
719          MessageQueue queue = mQueue;
720          if (queue == null) {
721              RuntimeException e = new RuntimeException(
722                  this + " sendMessageAtTime() called with no mQueue");
723              Log.w("Looper", e.getMessage(), e);
724              return false;
725          }
726          return enqueueMessage(queue, msg, 0);
727      }
1
2
3
4
5
6
7
8
9
10

sendMessageAtFrontOfQueue和sendMessage最大的不同在于它传入的uptime为0。0作为一种特殊的uptime，它表示将消息加入到队列头部。

/frameworks/base/core/java/android/os/MessageQueue.java#enqueueMessage

569              if (p == null || when == 0 || when < p.when) {
570                  // New head, wake up the event queue if blocked.
571                  msg.next = p;
572                  mMessages = msg;
573                  needWake = mBlocked;
1
2
3
4
5

如上代码验证了这一点，当when == 0时，则不论队列中已有的消息是什么状态，新来的消息都会被添加到队首。因此，如果A已经被加入到队列中，当再次调用sendMessageAtFrontOfQueue将B加入队列时，B会抢占A的队首位置，因此B先被处理。

2. mIdleHandlers为什么要拷贝数组？

/frameworks/base/core/java/android/os/MessageQueue.java

338              synchronized (this) {
......
......
394                  mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
395              }
396  
397              // Run the idle handlers.
398              // We only ever reach this code block during the first iteration.
399              for (int i = 0; i < pendingIdleHandlerCount; i++) {
400                  final IdleHandler idler = mPendingIdleHandlers[i];
401                  mPendingIdleHandlers[i] = null; // release the reference to the handler
402  
403                  boolean keep = false;
404                  try {
405                      keep = idler.queueIdle();
406                  } catch (Throwable t) {
407                      Log.wtf(TAG, "IdleHandler threw exception", t);
408                  }
409  
410                  if (!keep) {
411                      synchronized (this) {
412                          mIdleHandlers.remove(idler);
413                      }
414                  }
415              }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

mIdleHandlers是ArrayList类型，为何不直接遍历它来取出其中的IdleHandler对象，而是先将该ArrayList中的元素复制到另一个数组mPendingIdleHandlers中（394行）呢？

关键的原因在于两点：

1. mIdleHandlers中成员的更改必须要持有this（MessageQueue对象）同步锁，否则可能造成线程间的数据竞争状态。
2. IdleHandler.queueIdle方法的执行时间是未知的，因此不能在持有this同步锁的状态下去执行该方法。如果是持有this同步锁，且queueIdle方法的执行时间过长，那么其他调用Handler.sendMessage的线程将可能因为等锁而发生阻塞。这其实是多线程编程中一条基本法则：在同步块中只做必要的事，少做耗时的事。

基于以上两点要求，只能通过复制数组的方式，既保证mIdleHandlers的更新被this同步锁保护，又将可能的耗时操作从同步块中挪出。

3. 当消息队列头部是已激活的同步屏障时，还能够处理同步消息么？

同步屏障一个主要的作用就是屏蔽队列中已有的同步消息，使得它们无法被及时处理。通过这种方式可以将线程的执行权让渡给异步消息，从而让异步消息享受到VIP的待遇。

由于同步屏障的本质也是一个消息（该消息target为null，以区别开普通消息），所以只要后续的同步消息添加在它前面，就依然可以正常得到处理。

对于一个已经激活的同步屏障而言，将一个新的同步消息添加在它之前最简单的方法就是sendMessageAtFrontOfQueue。通过该方法可以将一个同步消息添加到队首，因此也就获得了被处理的权利。

4. Delivery Time 和 Dispatch Time

• Delivery Time = Dispatch Start - message.when，表示该消息实际轮询与理论轮询的时间差。
• Dispatch Time = 消息的实际处理时间。

对于system_server进程而言，其主线程、UiThread和FgThread都会设置slow detection。当线程中消息的delivery time或dispatch time大于阈值时，将会有相应的warning log输出。

默认dispatch的阈值是100ms，而delivery的阈值是200ms。

Slow dispatch warning:

Slow delivery warning:

03-17 02:57:06.409 914 1243 W Looper : Drained

Delivery time的warning log有一种特殊形式：Drained。

估计很多人看到这句Log有点不知所云，这其实是Android为了减少无效输出所做的优化。此话怎讲？

一旦某个消息的delivery time超过阈值，便意味着两种可能：

1. 前面有太多的消息需要处理，虽然每个消息处理时间都不长，但是雪崩来了，没有一片雪花是无辜的。
2. 前面某些消息的处理时间过长。

这两种情况的本质都是前面的消息对当前消息的影响，因此这种影响具有传递性。当一个消息报出slow delivery time的警报时，它后面的消息大概率也会报出这个警报。但是这些警报本质上反映的问题是同一个，所以为何要将重复的信息输出多次呢？

为了减少slow delivery警报重复输出，Android采用如下代码进行过滤：

/frameworks/base/core/java/android/os/Looper.java

231                  if (slowDeliveryDetected) {
232                      if ((dispatchStart - msg.when) <= 10) {
233                          Slog.w(TAG, "Drained");
234                          slowDeliveryDetected = false;
235                      }
236                  } else {
237                      if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
238                              msg)) {
239                          // Once we write a slow delivery log, suppress until the queue drains.
240                          slowDeliveryDetected = true;
241                      }
242                  }
1
2
3
4
5
6
7
8
9
10
11
12

当slow delivery的警告输出一次以后，后面的消息即便超出阈值，也不会再输出log。只到当某一个消息的delivery time ≤ 10ms时，才会输出一句新的log：Drained。

Drained的原意是排干、耗尽。用在这里表示原本拥塞的MessageQueue现在已经变得顺畅，当前消息的delivery time≤10ms表示此前消息的负面影响已经消散。所以当这句话输出以后，新一轮的slow delivery检测又重新开始生效。

另外，由于delivery time的计算需要message.when的参与，而通过sendMessageAtFrontOfQueue发送的消息其when为0。所以对于这一类消息，是不会有slow delivery的警报的。