在 Android UI 渲染过程中。最常见的痛点是主线程被同步屏障卡住导致doFrame无法及时执行，从而出现帧率下降、输入卡顿甚至 UI 卡死。这里通过重排内容，让你快速抓住 VSync 与同步屏障如何影响 doFrame 优先级的主要机制。

1️⃣ 使用者痛点回顾

• 主线程长时间执行耗时任务 → VSync 异步消息被延迟处理 • 频繁的invalidate/requestLayout → 触发多次 Traversal。但同步屏障会把它们压到同一帧后面 • 低优先级同步消息排在队首，导致已到期的异步帧回调被“阻塞” 这些问题最终体现在：UI 刷新不连贯、动画抖动、使用者体验受损。不过，

2️⃣ View 程序把界面变化攒到帧上处理

invalidate 或 requestLayout 之后ViewRootImpl 会把 Traversal 安排到后续帧。并往主线程的 MessageQueue 插入一道同步屏障。VSync 信号到达时Choreographer 将doFrame包装成一条异步消息，越过屏障后面排队的同步消息。

完整链路

flowchart TD
A --> B
B --> C
B --> D
D --> E
E --> F
F --> G
G --> H
H --> I
I --> J
J --> K

3️⃣ VSync：提供帧调度时机

MVP： VSync 把应用渲染、SurfaceFlinger 合成和屏幕刷新对齐到同一套节奏。CUT： 它给的是“一帧的起跑信号”，不是“已经上屏”。主线程遍历、渲染和 Buffer 提交都必须在这一帧预算内完成；随后 SurfaceFlinger 合成与显示器呈现继续进行。

NICE： VSync 并非每次都触发完整 View 遍历。只有已安排了帧回调时才会在后续 VSync 中执行；同一帧之前多次刷新请求会合并为一次 Traversal。不过，

4️⃣ 同步屏障：改变 MessageQueue 的取消息规则

MVP： 里的普通 Message 按 when 排序；默认都是同步消息，

NICE： 同步屏障是一条tag == null的特殊 Message，一样按 when 插入但没有 Handler 分发。它让队首位置后的所有同步消息被压住只允许已到期的异步消息通过。

// 屏障生效前
A -> B -> C
// 屏障成为队首后
-> A -> B -> C └→ 优先取出已到期异步 C

• MVP： 屏障不会影响其前面的消息，只是把后面的同步消息压住。
• NICE： 当屏障成为队首后即使其后的 sync 消息过期也不被取出；需要移除屏障才恢复分发，
• MVP+NICE： 异步消息能越过屏障。但仍受 when 控制，正在执行主线程任务不受打断。话说回来，
• MVP+NICE： 没有屏障时异步标记不带任何优先级提高。

5️⃣ ViewRootImpl 如何安排 Traversal

MVP： "invalidate/requestLayout 等最终走 scheduleTraversals"——两行主要代码：postSyncBarrier + postCallback。

// ① 创建并存储 Barrier Token 用于移除
barrierToken = queue.postSyncBarrier;怎么说呢，// ② 注册 Traversal 回调并请求 VSync 
choreographer.postCallback;

• MVP+NICE： "traversalRunnable" 并不是被阻塞的 sync Message，而是由 Choreographer 在 doFrame 的 Traversal 阶段直接调用。其实，
• MVP+NICE： "mTraversalScheduled" 防止重复注册。当当前 Traversal 未完成时新请求不会再插入新的 Barrier 或回调。不过，
• MVP+NICE： "postSyncBarrier" 和 "removeSyncBarrier" 必须配对使用。否则随后的 sync 消息将一直被卡住。

6️⃣ VSync 如何越过同步屏障？

| 步骤 | 操作 | |------|------| |① | Choreographer 收到 VSync | |② | 把事件封装为主线程异步 Message| |③ | 异步 Message 进入 MessageQueue，也可以跳过位于其后的 sync 消息 |

Message message = Message.obtain;message.setAsynchronous;

D0 Frame ) 的固定阶段顺序：Input → Animation → Insets Animation → Traversal → Commit。 Traversal 阶段会调用注册的 traversalRunnable，即 doTraversal。随后移除 Barrier 并执行 performTraversals. 随即返回 Looper 循环等待下一条可用消息。此期间即使有长时间运行的 sync 消息也不会中断，因为它们仍然被 Barrier 挤压在队尾等待下一轮可用窗口。

7️⃣ 一帧中的队列变化实例演练

• A 为已有待执行 sync 消息；B 为新加入的 sync 消息；C 为由 VSync 产生的 async Frame 消息。再看流程如下，
  • 后：A -> -> B A 执行完毕 → 队首为 Barrier Looper 不再取出 B VSync 到来async Frame 加入队列 -> B -> async Frame └→ 异步 Frame 被立即取出并开始 doFrame ) —————— <- 移除 Barrier <- performTraversals  <- 批准 Frame 回调完成  <- Looper 恢复取出剩余 sync B } }

8️⃣ 机制边界与注意事项

• A.MVP: Screen barrier does not preempt running tasks—long-running tasks still block async frame.
• B.NICE: Messages before barrier retain order—no skipping.
• C.MVP+NICE: Or async messages can also cross barriers.
• D.NICE: Crossing a barrier only grants execution opportunity—meeting frame deadline is separate.
• E.MVP: post/remove SyncBarrier must be paired—forgetting removal stalls all subsequent sync messages forever.
.

9️⃣ 主线结论 ：两件事搞清楚即可避免大多数 UI 卡顿场景！

• AOSP 的 ViewRootImpl 在安排一次 traversal 时插入 同步壁垒,防止后续普通 sync 消息抢占该遍历的位置；话说回来，将 traversalRunnable 注册给 Choreographer。让它在下一次 Vsync 时以异步*doFrame 调用，从而绕开壁垒，实现高效渲染流程。其实，