作为Android的基础知识,消息机制已被无数人写过。笔者曾经也写过一篇深入分析的文章,但总体而言乏善可陈,并无新颖之处。最近恰好重新整理了一下思路,想着可以从细节的角度出发,对一些冷门的知识点做一个归纳。记录于此,供大家批评讨论。
本文所有代码基于Android Q (10.0)
假设线程1此时正在处理一个消息,线程2通过如下方式(方式Ⅰ)往线程1的消息队列中插入两个消息。请问消息A和消息B哪个先被处理呢?
handler.sendMessage(msgA); handler.sendMessage(msgB); 复制代码
那如果是通过下面这种方式(方式Ⅱ),消息A和消息B又是哪个先被处理呢?
handler.sendMessageAtFrontOfQueue(msgA); handler.sendMessageAtFrontOfQueue(msgB); 复制代码
答案是通过方式Ⅰ发送时,消息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 } 复制代码
Handler类中所有的sendMessage方法,最终都是调用MessageQueue.enqueMessage方法将消息加入到队列之中。调用时传入两个参数:msg和uptimeMillis。msg自然是想要发送的消息,而uptimeMillis则是消息预计发送的时间。
SystemClock.uptimeMillis(): Returns milliseconds since boot, not counting time spent in deep sleep.
/frameworks/base/core/java/android/os/Handler.java
610 public final boolean sendMessage(@NonNull Message msg) { 611 return sendMessageDelayed(msg, 0); 612 } 复制代码
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 } 复制代码
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 } 复制代码
最终传入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 } 复制代码
一个消息若是加入到队列中来,只可能是两种情况:
对于第一种情况,假设A先加入到队列头部,只有当B的when(uptime) 小于 A的when时,B才会加入到A的前面;对于第二种情况,同样是只有B的when 小于 A的when时,B才会加入到A的前面。当B的when和A相等时,B只会加入到A的后面。因此,A先被处理。
/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 } 复制代码
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; 复制代码
如上代码验证了这一点,当when == 0时,则不论队列中已有的消息是什么状态,新来的消息都会被添加到队首。因此,如果A已经被加入到队列中,当再次调用sendMessageAtFrontOfQueue将B加入队列时,B会抢占A的队首位置,因此B先被处理。
/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 } 复制代码
mIdleHandlers是ArrayList<IdleHandler>类型,为何不直接遍历它来取出其中的IdleHandler对象,而是先将该ArrayList中的元素复制到另一个数组mPendingIdleHandlers中(394行)呢?
关键的原因在于两点:
基于以上两点要求,只能通过复制数组的方式,既保证mIdleHandlers的更新被this同步锁保护,又将可能的耗时操作从同步块中挪出。
同步屏障一个主要的作用就是屏蔽队列中已有的同步消息,使得它们无法被及时处理。通过这种方式可以将线程的执行权让渡给异步消息,从而让异步消息享受到VIP的待遇。
由于同步屏障的本质也是一个消息(该消息target为null,以区别开普通消息),所以只要后续的同步消息添加在它前面,就依然可以正常得到处理。
对于一个已经激活的同步屏障而言,将一个新的同步消息添加在它之前最简单的方法就是
sendMessageAtFrontOfQueue。通过该方法可以将一个同步消息添加到队首,因此也就获得了被处理的权利。
对于system_server进程而言,其主线程、UiThread和FgThread都会设置slow detection。当线程中消息的delivery time或dispatch time大于阈值时,将会有相应的warning log输出。
默认dispatch的阈值是100ms,而delivery的阈值是200ms。
Slow dispatch warning:
03-23 14:23:17.533 1505 1505 W Looper : Slow dispatch took 111ms main h=android.app.ActivityThread$H c=android.app.LoadedApk$ServiceDispatcher$RunConnection@67031fa m=0
Slow delivery warning:
03-17 02:36:14.623 914 1243 W Looper : Slow delivery took 648ms android.ui h=com.android.server.policy.PhoneWindowManager$PolicyHandler c=com.android.server.policy.PhoneWindowManager$22@7dd9dd5 m=0.
03-17 02:57:06.409 914 1243 W Looper : Drained
Delivery time的warning log有一种特殊形式:Drained。
估计很多人看到这句Log有点不知所云,这其实是Android为了减少无效输出所做的优化。此话怎讲?
一旦某个消息的delivery time超过阈值,便意味着两种可能:
这两种情况的本质都是前面的消息对当前消息的影响,因此这种影响具有传递性。当一个消息报出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 } 复制代码
当slow delivery的警告输出一次以后,后面的消息即便超出阈值,也不会再输出log。只到当某一个消息的delivery time ≤ 10ms时,才会输出一句新的log:Drained。
Drained的原意是排干、耗尽。用在这里表示原本拥塞的MessageQueue现在已经变得顺畅,当前消息的delivery time≤10ms表示此前消息的负面影响已经消散。所以当这句话输出以后,新一轮的slow delivery检测又重新开始生效。
另外,由于delivery time的计算需要message.when的参与,而通过sendMessageAtFrontOfQueue发送的消息其when为0。所以对于这一类消息,是不会有slow delivery的警报的。