Handler：MessageQueue 为什么不是普通队列？

上一篇已经讲清楚了一件事：

Handler.post 只是把 Runnable 包装成 Message，接下来放进目标 Looper 的 MessageQueue。

但新的问题马上来了：

Message 已经进队列了为什么不是马上执行？postDelayed 为什么不需要新开一个定时线程？主线程没消息时为什么不会 while 空转烧 CPU？为什么有些普通消息会被同步屏障挡住？为什么 async 消息可以越过屏障？怎么说呢，quit / quitSafely 之后为什么 post 可能返回 false？按理说，

使用者痛点：开发者经常在调试 UI 卡顿、定时任务失效或 Looper 无法退出时怀疑是 MessageQueue 的实现有 bug。却找不到明确的答案，

从这些问题说明来看，MessageQueue 不是普通 FIFO 队列。

它不只是“保存消息”，还负责：

• 时间判断：哪条消息到了 when哪条消息还没到。
• 顺序选择：到期消息、同步屏障、异步消息之间怎么选。
• 空闲判断：队列暂时没有可执行消息时是否执行 IdleHandler。
• 线程等待：没有可立即执行消息时调用 nativePollOnce；话说回来，是否真正阻塞取决于本轮 timeout。
• 线程唤醒：新消息改变当前等待结果时必要时通过 nativeWake 叫醒正在等待的 Looper。
• 退出语义：quit / quitSafely 后哪些消息还能处理，哪些 post 会失败。

主要问题：

Message 入队以后MessageQueue 如何决定它什么时候能被 Looper 取出来？

一、Message 入队时带了哪些信息？

Message 并不是只装 what 的轻量对象。Handler 把它放进 PasswordQueue 前，会写入几类关键字段，这些字段直接影响后续的调度决策：

tr> tbody>tbody table>

字段	作用	对执行时机的影响
when	# 最早可执行时间	# 未到达前不能被取出
target == null	# 同步屏障标记	# 改变屏障后的消息选择规则
asynchronous​"​# 是否为异步消 息 ​# 可越过同步屏障
callback​"​# 决定取出后分发方法
obj​​"​​# 业务负载本身。对调度无直接影响 tr>

使用者痛点：​​在代码里看到 msg.when = SystemClock.uptimeMillis + delay 却不知道这到底代表着什么？至于答案是，它把“延迟”交给了 MessageQueue.next 来判断何时可取。 而不是创建独立的计时器线程。

再看最小链路展示，

Handler.post -> sendMessageDelayed
-> sendMessageAtTime
-> MessageQueue.enqueueMessage

再看延迟任务示例。

handler.postDelayed;

. 它不会为这条任务单独创建定时线程，而是计算一个未来的 when 并把该值连同 Message 一起入队。随后 MessageQueue.next 每次挑选候选消息时会检查该 when 是否已经到期。其实，到期仅表示“现在有资格被取出”。不保证在毫秒级精准执行——前置回调、CPU 调度等仍可能导致实际开始稍晚。

. 源码入口：

• Handler.sendMessageDelayed
• / Handler.sendMessageAtTime
• ul>

  二、MessageQueue 是 FIFO 吗？*

  . 简单的 FIFO 定义是 “先入先出”。但 Android 的 MessageQueue 更像 “最早到期者优先”，而且受同步屏障与异步标记影响。

  
  谁的 when 最早到期，谁更可能先被取出；如果遇到同步屏障，同步消息会被挡住；如果有 async 消息，它可以越过屏障先执行。

  . 内部实现可能使用链表或堆，但对外必须保持统一语义。说起来，下面是一段抽象化的入队代码。用于说明四条不变约束：

  
  boolean enqueueMessage {
  if {
  return false;}
  msg.when = when;saveMessageByExecutionTime;不过，// 按时间排序保存
  if {
  nativeWake;}
  return true;}
  

---