Android Handler 深入：同步屏障与 Choreographer 调度机制

Mon, 10 Aug 2026 00:00:00 +0800

一、Handler总体流程

Looper 每执行一轮，到底如何决定“下一步做什么”？

基础 Handler 机制只解释了正常路径：

MessageQueue.next()
↓
取出 Message
↓
Handler.dispatchMessage()
↓
再次 next()

而进阶机制，本质上是在这个循环的不同位置插入特殊能力：

MessageQueue.next()
├─ 普通消息调度
├─ SyncBarrier / Async Message
├─ IdleHandler
└─ nativePollOnce()
Looper.loopOnce()
├─ Printer
├─ Observer
├─ Trace / Slow dispatch
└─ Handler.dispatchMessage()
更上层：
Choreographer
└─ 借助异步消息 + VSYNC 构建帧调度

下面我们从源码把它们串起来讲：

二、先重新看一次Looper.loopOnce()

for (;;) {
 Message msg = queue.next();

 msg.target.dispatchMessage(msg);

 msg.recycleUnchecked();
}

但实际上 AOSP 的loopOnce()在dispatchMessage()前后做了不少事情。

其中有一段：

final Printer logging = me.mLogging;

if (logging != null) {
 logging.println(
 ">>>>> Dispatching to "
 + msg.target + " "
 + msg.callback + ": "
 + msg.what
 );
}

msg.target.dispatchMessage(msg);

if (logging != null) {
 logging.println(
 "<<<<< Finished to "
 + msg.target + " "
 + msg.callback
 );
}

也就是说，一条 Message 的执行过程实际上类似：

MessageQueue.next()
↓
Printer：Dispatching
↓
Observer / Trace 等监控开始
↓
Handler.dispatchMessage()
↓
Observer / Trace 等结束
↓
Printer：Finished
↓
Message.recycle()

当前 AOSP 的Looper.setMessageLogging()明确就是在每条消息 dispatch 开始和结束时调用 Printer。

三、Printer：Looper天然提供的消息监控点

API:

Looper.getMainLooper().setMessageLogging(printer);

例如：

Looper.getMainLooper().setMessageLogging { text ->
 Log.d("LooperMonitor", text)
}

实际上Printer只有：

void println(String x);

Looper会在消息执行前打印类似：

>>>>> Dispatching to Handler ... : 0

执行结束后：

<<<<< Finished to Handler ...

源码就是在dispatchMessage()前后进行这两次回调。

因此你可以记录时间：

Looper.getMainLooper().setMessageLogging { line ->

 if (line.startsWith(">>>>>")) {
 start = SystemClock.uptimeMillis()
 }

 if (line.startsWith("<<<<<")) {
 val cost =
 SystemClock.uptimeMillis() - start

 if (cost > 100) {
 Log.w(
 "BlockMonitor",
 "Main thread blocked ${cost}ms"
 )
 }
 }
}

这就是很多早期卡顿监控方案的基本思想：

Dispatching
↓
记录开始时间
↓
Message 执行
↓
Finished
↓
计算耗时

所以Printer并不是普通意义上的日志 API。

它实际暴露了一个非常重要的 Hook：

Looper 每条消息执行的边界。

三、Printer能检测什么，不能检测什么

假设：

handler.post {
 Thread.sleep(1000)
}

Printer 可以非常容易发现：

Dispatching
↓
1000ms
↓
Finished

所以它能检测:

单条 Looper Message 执行时间过长。

但要注意，它测量的是：

dispatchMessage 开始
↓
dispatchMessage 结束

而不是：

消息进入队列
↓
消息真正执行

所以如果：

Message B
已经在队列等待 3 秒

Printer 本身并不能直接告诉你：

B 在队列里等了 3 秒。

它更适合检测：

当前正在执行的 Message 是否太慢

而不是完整的 Message 排队延迟。

这也是为什么现代性能工作还需要 Trace、Prefetto 等更完整的调度信息。

四、IdleHandler：MessageQueue 空闲时还能做什么

Printer位于：

Looper.dispatchMessage()

附近。

IdleHandler 则完全不同。

它直接位于:

MessageQueue.next()

内部。

接口非常简单：

public interface IdleHandler {
 boolean queueIdle();
}

AOSP 注释对它的描述是：

当消息队列已经没有当前可以执行的消息、准备等待更多消息时调用。

而且即使队列中还有 Message，只要这些 Message 都是未来才执行的延迟消息，仍然可以视作 idle。

这一点很重要。

所谓：

MessageQueue idle

不是：

MessageQueue 完全为空

而是：

当前没有可以立即执行的 Message

例如：

当前时间：1000ms
MessageQueue：
A when=5000ms
B when=8000ms

虽然队列不为空，但现在没有任何 Message 能执行。

因此：

MessageQueue 扔然处于 idle 状态。

五、IdleHandler 在 next() 的哪个位置执行

简化MessageQueue.next()

for (;;) {

 nativePollOnce(...);

 synchronized (this) {

 Message msg = 找下一条消息;

 if (msg 已经到期) {
 return msg;
 }

 // 当前没有立即可执行 Message

 if (pendingIdleHandlerCount < 0
 && isIdle()) {

 pendingIdleHandlerCount =
 mIdleHandlers.size();
 }
 }

 // 执行 IdleHandler

 for (...) {

 boolean keep =
 idler.queueIdle();

 if (!keep) {
 removeIdleHandler(idler);
 }
 }

 ...
}

当前 AOSP 中仍然是这个基本流程：确认 queue idle 后复制IdleHandler列表，然后依次调用queueIdle()；返回false的 handler 会被移除。

所以：

MessageQueue.next()
↓
发现没有当前可执行 Message
↓
有没有 IdleHandler？
↓
有
↓
queueIdle()
↓
然后继续 next()
↓
最终 nativePollOnce()

六、同步屏障其实也发生在MessageQueue.next()

现在进入另一个特殊分支。

普通 Message：

msg.target != null

因为 Handler 入队时会：

msg.target = this;

但同步屏障是一个非常特殊的 Message：

msg.target == null

当前MessageQueue源码也明确要求普通enqueueMessage()的 Message 必须有target；而屏障节点则用target == null来区分。

假设队列：

Barrier
↓
Message A(sync)
↓
Message B(sync)
↓
Message C(async)

next()中有这样的核心逻辑：

if (msg != null && msg.target == null) {

 // 被 barrier 挡住

 do {
 prevMsg = msg;
 msg = msg.next;

 } while (
 msg != null
 && !msg.isAsynchronous()
 );
}

当前源码就是：

发现队首是 Barrier
↓
不断向后找
↓
直到发现 asynchronous Message

因此：

Barrier
↓
Sync A 跳过
↓
Sync B 跳过
↓
Async C 返回

七、同步屏障到底是什么作用

同步屏障之后的同步消息会暂停执行，直到调用removeBarrier()；异步消息不受barrier影响。并且barrier必须成对移除，否则消息队列可能无法恢复正常运行。

所以：

Sync Barrier

其实就是：

MessageQueue 临时改变自己的消息选择规则。

平时：

选择最早到期 Message

Barrier 存在：

选择最早到期 Async Message

一般开发者不应该，也基本不能直接调用同步屏障的添加/移除接口。postSyncBarrier()和removeSyncBarrier()虽然在源码里是 public 的，但同时也标记了@hide，属于隐藏 API。因此这套机制主要是给Framework 自己使用的调度能力，典型就是 View 绘制链路。

例如ViewRootImpl.scheduleTraversals()的经典设计就是：

UI 请求 layout / draw
↓
ViewRootImpl.scheduleTraversals()
↓
postSyncBarrier()
↓
普通同步 Message 暂时被挡住
↓
Choreographer 的异步帧消息可以穿过去
↓
VSYNC
↓
doFrame()
↓
Traversal
↓
doTraversal()
↓
removeSyncBarrier(token)

所以你可以把 SyncBarrier 看成：

Framework为了控制主线程消息调度顺序而保留的一种“内部交通管制能力”。

而不是开发者通用的：

“提高我的 Message优先级"工具。

不过开发者可以合法使用和它相关的另一半机制：异步 Handler。

Android 提供公开 API：

val handler = Handler.createAsync(Looper.getMainLooper())

这种 Handler 发出的消息会被标记为异步消息，因此如果队列里存在同步屏障，它们不会被屏障阻塞。

八、Choreographer 和 Handler连接起来的地方

Choreographer 源码开头直接说明了自己的职责：

协调 animation、input、drawing 的时间
接收来自显示系统的 timing pulse，例如 VSYNC
然后安排下一帧工作

而且每个Looper 线程可以拥有自己的 Choreographer，回调最终运行在那个 Choreographer 所绑定的 Looper 线程。

注意 Choreographer 内部字段：

private final Looper mLooper;
private final FrameHandler mHandler;

private final FrameDisplayEventReceiver
 mDisplayEventReceiver;

private final CallbackQueue[]
 mCallbackQueues;

构造：

mLooper = looper;
mHandler = new FrameHandler(looper);

mDisplayEventReceiver =
 new FrameDisplayEventReceiver(
 looper,
 vsyncSource,
 layerHandle
 );

也就是说：

Choreographer
├─ Looper
├─ Handler
├─ DisplayEventReceiver
└─ 自己的 CallbackQueue

这里一个非常重要的结论出现了：

Choreographer 自己还有一套 CallbackQueue，但它最终仍依托 Looper/Handler 驱动。

九、Choreographer为什么还需要自己的CallbackQueue

Handler的MessageQueue管：

整个线程的所有 Message

Choreographer 自己则需要进一步区分：

INPUT
ANIMATION
INSETS_ANIMATION
TRAVERSAL
COMMIT

当前源码定义的 callback 顺序就是：

CALLBACK_INPUT = 0
CALLBACK_ANIMATION = 1
CALLBACK_INSETS_ANIMATION = 2
CALLBACK_TRAVERSAL = 3
CALLBACK_COMMIT = 4

其中源码注释明确指出 Traversal 负责 layout 和 draw。

所以可以理解成两级调度：

一级调度
MessageQueue
负责线程所有任务
↓
二级调度
Choreographer.CallbackQueue
负责一帧内部的不同阶段

这跟我们前面说的：

target → Handler
what → Handler 内部分类

其实是类似的设计思想：

不同层级分别负责自己的任务分类和调度。

十、一次Choreographer回调是怎么样开始的

比如：

postCalback(
 CALLBACK_TRAVERSAL,
 runnable,
 token
);

内部：

final long now =
 SystemClock.uptimeMillis();

final long dueTime =
 now + delayMillis;

mCallbackQueues[callbackType]
 .addCallbackLocked(
 dueTime,
 action,
 token
 );

然后：

if (dueTime <= now) {
 scheduleFrameLocked(now);
}

否则：

Message msg =
 mHandler.obtainMessage(
 MSG_DO_SCHEDULE_CALLBACK,
 action
 );

msg.arg1 = callbackType;

msg.setAsynchronous(true);

mHandler.sendMessageAtTime(
 msg,
 dueTime
);

注意这里非常关键的一行：

msg.setAsynchronous(true);

当前 Choreographer 源码确实将这类调度 Message 标记为异步。

现在 Handler 与 Choreographer 就真正连起来了。

十一、VSYNC到底怎么进入Java世界

Choreographer里面还有：

FrameDisplayEventReceiver
 extends DisplayEventReceiver

当显示系统产生 VSYNC 时，会进入：

FrameDisplayEventReceiver.onVsync();

然后源码会创建一个 Message：

Message msg =
 Message.obtain(
 mHandler,
 this
 );

msg.setAsynchronous(true);

mHandler.sendMessageAtTime(
 msg,
 timestamp
);

之后 Runnable：

@Override
public void run() {
 mHavePendingVsync = false;

 doFrame(
 mTimestampNanos,
 mFrame,
 mLastVsyncEventData
 );
}

当前 Choreographer 的FrameDisplayEventReceiver就是这样把 VSYNC 转换成异步 Message，再最终调用doFrame()。

因此完整链：

Display subsystem
↓
VSYNC
↓
DisplayEventReceiver
↓
FrameDisplayEventReceiver
↓
创建 Async Message
↓
Main MessageQueue
↓
MainLooper
↓
FrameDisplayEventReceiver.run()
↓
Choreographer.doFrame()

这一步非常重要。

Choreographer 并不是：

一个独立线程不停轮询 VSYNC

而是：

VSYNC 最终被转换成 Looper 可以处理的任务，并在 Choreographer 所绑定线程上执行

十二、doFrame() 才是一帧真正执行的地方

进入：

Choreographer.doFrame()

后，源码最终按照顺序调用：

doCallbacks(CALLBACK_INPUT);

doCallbacks(CALLBACK_ANIMATION);

doCallbacks(
 CALLBACK_INSETS_ANIMATION
);

doCallbacks(CALLBACK_TRAVERSAL);

doCallbacks(CALLBACK_COMMIT);

于是整个主线程的结构变得很有意思：

Looper
│
└─ 一次 doFrame Message
↓
Choreographer
↓
INPUT
↓
ANIMATION
↓
TRAVERSAL
↓
COMMIT

也就是说：

对 Looper 来说，一帧可能只是它正在 dispatch 的一个任务；但这个任务内部，Choreographer 又实现了一套完整的帧阶段调度。

十三、那ViewRootImpl又是怎么进来的

ViewRootImpl的：

scheduleTraversals()

会安排：

TraversalRunnable

进入：

Choreographer.CALLBACK_TRAVERSAL

最后在：

Choreographer.doFrame()

执行：

doCallbacks(
 CALLBACK_TRAVERSAL
);

Traversal 的语义在当前 Choreographer 源码里就明确负责 layout 和 draw。

随后 ViewRootImpl 的：

TraversalRunnable.run()
↓
doTraversal()
↓
performTraversals()

进一步进入 View 树的：

messasure
layout
draw

所以：

Handler

一路往上最终可以连接到：

View 绘制

MessageQueue 解决的是整个主线程下一事情执行什么

Choreographer 解决的是既然现在要处理这一帧，那么这一帧内部各类任务以什么顺序执行

Sync Barrier on zed的博客