企业官网建设流程全解析

这算是我Handler源码系列里的第三篇。前两篇把Looper的循环机制和MessageQueue的存储结构翻了个底朝天，当时就有读者追问：你说队列里的Message都是按时间排序的，那为什么有时候主线程明明不卡，我postDelayed的某个回调却拖了快一个帧周期才执行？甚至在某些极端的绘制场景下，普通消息会被一连串“插队”的消息压制很久。这个问题问到点子上了，答案就在今天要讲的同步屏障（SyncBarrier）。

先给结论：同步屏障是MessageQueue里一种特殊的消息，它本身没有回调目标（target为null），作用是在队列中“拉起一条隔离线”。一旦这条线存在于队首，next()方法就会跳过它后面的所有同步消息，只放行异步消息。这个设计最核心的场景，就是保障UI绘制、输入分发这些跟“下一帧”强相关的高优任务，不被主线程上积压的普通任务拖延。

这篇文章适合两类人：一是面试复习Handler机制、想搞懂消息优先级实现细节的人；二是真正在排查掉帧或消息调度问题时，想知道“为什么普通消息会被系统消息挤掉”的开发者。我会从设计动机讲到源码实现，再给出实战排查经验和避坑建议。

1. 为什么消息队列需要一扇“快速门”

1.1 从掉帧现象说起

先说个现象。你在主线程执行一个耗时操作，比如把一张图片做高斯模糊，耗时80ms。这80ms里，主线程的Looper还在一直转，但它被你的同步代码占住了，消息队列里的消息只能排队等着。这很容易理解，Looper只有一个，队列再长也架不住干活的人去忙别的事了。

但如果把这个场景换一下：你手里同时有几百条普通消息（业务埋点、数据库写入、网络回调），它们不耗时，每条只有1ms，加起来却要几百毫秒才排完。如果在这几百条消息中间插进来一个“必须马上执行”的绘制任务，比如系统要渲染下一帧，它会怎样？按普通队列的规则，它得老老实实排到队尾，跟几百条消息一起等待。结果就是掉帧、动画卡顿、触摸响应变慢。

问题不在消息本身的耗时，而在调度顺序。普通的优先级队列在这个场景下不够用，因为这里的“优先级”不是靠时间排序能体现的——绘制任务的执行时间可能比队尾的某条消息还要靠后，但它的紧急程度远超队列里的任何一条同步消息。

1.2 同步消息与异步消息的本质区别

Handler机制里，我们平时通过handler.post()、handler.sendMessage()发送的消息，默认都是同步消息，代码里对应的标记是FLAG_ASYNCHRONOUS为false。而通过new Handler(looper, callback, true)这种带第三个参数为true的构造方式创建的Handler，它发出的消息会被标记为FLAG_ASYNCHRONOUS，这就是异步消息。

注意这里的“异步”不是说你开了子线程去发，而是指消息本身携带了一个flag，告诉MessageQueue：“我的紧急程度高，遇到同步屏障时可以直接通行。”真正的异步执行靠的还是线程调度，这个flag只是调度层的一个标记。

同步屏障不会拦截异步消息，只会拦截同步消息。所以你可以把队列想象成一条双向通道：屏障出现后，同步消息全部原地等待，异步消息照常从左边的快速通道通过。

1.3 屏障机制的设计初衷

系统为什么非要用“屏障+异步消息”这套组合，而不是直接提供两个优先级队列？关键原因是顺序保证。Android的消息队列必须保证绝大多数业务消息按时间顺序执行，不能因为优先级机制把正常的业务顺序打乱。同步屏障是一种临时性、可撤销的“暂停同步消息”机制，它不是把消息从队列里移走，而是让它们在原地等候，等屏障移除后继续按原来的顺序出队。

打个比方：一个安检通道，普通旅客都在排队，突然来了一批紧急转运的医疗物资，工作人员临时拉了一条隔离线，让普通旅客暂时等一等，只放行这批物资；物资通过后，隔离线撤掉，旅客们按原来的顺序继续安检。同步屏障就是那条隔离线，异步消息就是医疗物资，普通同步消息就是旅客。

这样的设计既不影响正常消息的相对顺序，又能临时给高优任务开绿灯。并且，屏障是可以多次嵌套的，后面会看到系统里屏障是经常进出队列的。

2. 源码拆解：屏障消息是怎么“插队”又“收队”的

2.1 插入屏障：postSyncBarrier的完整逻辑

同步屏障的插入入口是MessageQueue.postSyncBarrier()。这里需要先说明，这个方法是@UnsupportedAppUsage注解标注的，系统内部大量使用，但普通应用不建议直接反射调用。它的核心逻辑是把一个没有target的Message按时间插入消息队列：

private int postSyncBarrier(long when) { synchronized (this) { final int token = mNextBarrierToken++; final Message msg = Message.obtain(); msg.markInUse(); msg.when = when; msg.arg1 = token; Message prev = null; Message p = mMessages; if (when != 0) { while (p != null && p.when <= when) { prev = p; p = p.next; } } if (prev != null) { msg.next = p; prev.next = msg; } else { msg.next = p; mMessages = msg; } return token; } }

这段代码有几个关键点：

• Message.obtain()拿到一个空消息，注意这里没有给msg.target赋值。这就是屏障消息最重要的特征：target为null。在next()方法里，只要看到msg.target == null，就认定这是屏障消息。
• token是每次插入屏障时自增的，用于后续removeSyncBarrier(token)精确移除。它可以理解成屏障的ID。
• 插入位置仍然遵循时间排序，屏障也有自己的when时间，所以它不会永远排在队首，而是按时间插到合适位置。大多数情况下系统插入屏障时when=0或者取当前时间，所以它会跑到队首附近。

2.2 next()取出消息时的屏障分支

MessageQueue的核心取消息逻辑在next()方法里，这里有一段专门处理屏障的分支，是理解整个机制的重中之重：

Message next() { ... for (;;) { synchronized (this) { // 尝试取队首消息 Message prevMsg = null; Message msg = mMessages; if (msg != null && msg.target == null) { // 遇到同步屏障，立即跳到后面的逻辑： // 跳过所有同步消息，只找异步消息 do { prevMsg = msg; msg = msg.next; } while (msg != null && !msg.isAsynchronous()); } if (msg != null) { // 如果拿到异步消息，检查时间是否到 if (now < msg.when) { // 时间未到，继续阻塞等待 } else { // 时间已到，从链表中取出这条消息 ... return msg; } } else { // 屏障后面没有异步消息，或者队列已经空了， // 进入idle状态，阻塞等待新消息 } } ... } }

注意这个do-while循环的条件：它从屏障的后一个节点开始遍历，只要节点不是异步消息就继续往后找，直到找到第一条isAsynchronous() == true的消息。这意味着队列里排在屏障之后的同步消息，无论它们的时间有多早、紧急程度有多高，都只能在这个循环里被跳过，不能出队。

如果这个循环走完了，一整个消息链表里只有同步消息，那么msg最终为null，next()会进入idle阻塞状态。这里有个容易误解的点：屏障并不会导致主线程崩溃或者Looper退出，它只是让next()暂时取不到可执行的同步消息，于是线程进入阻塞，等待异步消息或者屏障被移除后再唤醒。

2.3 撤掉屏障：removeSyncBarrier的匹配逻辑

屏障不能一直存在，否则同步消息会被永久堵住。移除屏障的入口是removeSyncBarrier(int token)：

void removeSyncBarrier(int token) { synchronized (this) { Message prev = null; Message p = mMessages; // 遍历找到 target == null 且 arg1 == token 的屏障消息 while (p != null && (p.target != null || p.arg1 != token)) { prev = p; p = p.next; } if (p == null) { // 没有找到，说明屏障已经被移除或token不对 return; } ... if (prev != null) { prev.next = p.next; // 从链表中摘除屏障 } else { mMessages = p.next; } // 如果这是队列中最后一个屏障，需要唤醒可能阻塞的 next() if (p.next != null) { mMessages = p.next; } else { mMessages = null; } ... } }

这里真正重要的是“用token精确匹配”：因为屏障消息没有target，队列里可能同时存在多个屏障（比如系统在View绘制和Input分发时各自插屏障），必须用arg1里存的token区分。移除后，如果链表里还存在其他屏障，next()依然会继续跳过同步消息；只有所有屏障都被移除，同步消息才能恢复正常出队。

源码里移除屏障后还做了和mBlocked有关的状态处理：如果当时next()正在阻塞等待，而且这个屏障是最后一个屏障，需要调用nativeWake唤醒执行线程，让next()重新取一次消息。如果屏障后面没有其他屏障但也没有消息，也会走唤醒逻辑，确保后续新post的消息能被及时取到。

2.4 三个细节串起来理解

把插入、取出、移除三个环节放到一条时间线里看：

1. 系统调用postSyncBarrier()插入屏障，返回token。
2. next()看到队首是屏障，跳过所有同步消息，只找异步消息。
3. 异步消息执行完毕，系统调用removeSyncBarrier(token)移除屏障。
4. 队列恢复原样，同步消息继续按时间出队。

这个“屏障生效期间，正好是异步消息集中执行的时间窗口”，就是整个机制的关键。屏障不是常驻的，它只在一段很短的高优任务窗口期内存在；但这段时间足以让队列里的异步任务优先跑掉。

还有一个细节值得留意：屏障消息是有when时间的，它也会参与时间排序。如果某个同步消息的时间比屏障更早，它依然排在屏障前面，不会被拦截。这个细节在理解“为什么有些同步消息可以绕过屏障”时很重要——严格来说，屏障只拦截它后面的同步消息，它前面的消息在插入时就已经排好了。

3. 真正驱动同步屏障的幕后角色

3.1 Choreographer和它的FrameHandler

同步屏障最典型的使用场景，就是Android系统里的帧调度器——Choreographer。它的职责是接收VSync信号，调度doFrame回调，最终触发View的遍历、测量、布局和绘制。如果这些算子被普通同步消息插队，渲染就会滞后。

Choreographer内部有个FrameHandler，它的构造方式很特殊：

private final class FrameHandler extends Handler { public FrameHandler(Looper looper) { super(looper, null, true); // 第三个参数传 true，表示这是一个异步 Handler } }

这个true很关键。它意味着所有通过这个Handler发出的消息，都会被标记为FLAG_ASYNCHRONOUS。也就是说，VSync回调、doFrame消息、输入批处理消息，通通都是异步消息。它们在消息队列里拥有“越过同步屏障”的特权。

3.2 scheduleTraversals的完整链路

再来看看ViewRootImpl是怎么把绘制任务送到队列里的。当你调用requestLayout()的时候，最终会走上ViewRootImpl.scheduleTraversals()：

void scheduleTraversals() { if (!mTraversalScheduled) { mTraversalScheduled = true; // 先插入一个同步屏障 mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); // 再把实际的遍历任务post到Choreographer mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); ... } }

这里有个非常清晰的配合：先postSyncBarrier()建立一个屏障，再通过mChoreographer发送异步的遍历回调。屏障保证接下来的同步消息全部暂停，而postCallback派发出去的异步消息能够立刻被next()取出，进而触发doFrame、performTraversals。执行完成后，屏障会被unscheduleTraversals()等方法移除，同步消息再继续跑。

这套机制保证了主线程再忙，绘制任务也能在每一帧的调度窗口里优先执行，而不是被业务代码的普通消息挤到帧尾。

3.3 async Handler在系统里的其他应用

除了Choreographer，系统里还有一些地方也用异步Handler。比如AsyncTask内部的InternalHandler：

private static class InternalHandler extends Handler { public InternalHandler() { super(Looper.getMainLooper(), null, true); } }

它负责在任务完成后把结果回调到主线程的onPostExecute。这个回调被标记为异步，是为了在屏障存在时依然能及时把任务结果交回UI线程。类似的还有InputEventReceiver等处理输入事件的逻辑，输入事件必须赶在下一帧VSync之前处理完，所以也走异步通道。

可见，系统里凡是跟“下一帧必须及时响应”相关的逻辑，几乎都会走异步Handler + 同步屏障的组合。这既是性能优化手段，也是一种调度约定。

3.4 同步屏障的适用边界

但要注意，同步屏障并不是万能的“抢线程”机制。它只影响MessageQueue里的出队顺序，不影响线程正在执行的那个消息。如果主线程当前正在执行一个长任务（比如一个耗时1秒的耗时运算），屏障插得再早，也得等当前任务执行完，Looper才有机会进入next()去取异步消息。

所以同步屏障解决的是“队列里积压了很多同步消息”的问题，不是“主线程正在忙”的问题。后者靠的是消息调度框架的线程调度，跟屏障是两码事。理解这个边界，能避免很多排查误区——你会看到有些地方明明用了异步Handler，掉帧却没有改善，原因就是耗时任务本身占住了主线程，屏障机制无能为力。

4. 常见问题排查与实战避坑

4.1 高危场景：手动插入屏障后忘了移除

如果你在业务代码里反射调用postSyncBarrier()，或者在某些框架里看到类似的逻辑，一定要高度警惕泄漏问题。屏障一旦插入，如果不调用removeSyncBarrier(token)移除，队列里的同步消息会一直无法出队，表现起来就是主线程消息全部“冻结”：UI还停留在你插入屏障那一刻的界面，点击无响应，但Looper线程并没有死，只是next()在同步消息的位置上反复跳过，找不到可执行消息后就进入阻塞。

这种问题非常难排查，因为崩溃日志里通常什么都没有，就是卡死。从系统上线经验看，这类泄漏往往出现在高并发场景：一个任务在回调A里插屏障，但在回调B里忘了移除，或者屏障插入的token和移除的token对不上。建议的做法是：生产代码里绝对不要手动创建同步屏障，把这件事交给系统框架。自己写消息调度时，用高优先级的HandlerThread或者协程调度就够了，没必要碰这个底层机制。

4.2 为什么屏障不加快消息处理速度

有人会问：既然同步屏障能让高优消息“插队”，那我是不是能用它来让某个业务任务尽快执行？答案是不能。

屏障的语义是“让异步消息优先于同步消息执行”，但它并没有提升CPU的处理速度。它只调整了出队顺序。如果你把一个任务的Handler改成异步Handler，但这个任务本身依然走主线程Looper，那只能保证它在队列里站到更靠前的位置，无法保证它在主线程当前正在执行的长任务中“抢时间”。想提升这类任务的响应速度，应该考虑更换线程模型，而不是依赖屏障机制。

这个认知对排查问题很有帮助。遇到“异步消息还是慢”的情况，先确认主线程有没有耗时任务，再看队列里有没有多个嵌套屏障。基本上一查一个准。

4.3 如何自己验证同步屏障的存在

如果你不满足于纸上谈兵，想亲手验证一下屏障机制，可以用一个比较安全的实验方式。这需要你在调试机型上做，别在生产环境里跑：

1. 写一个普通的测试Activity，主线程连续发送10条延迟不同的同步消息，每条都打Log。
2. 在发送完这批消息后，用反射调用Looper.getMainLooper().getQueue().postSyncBarrier()，拿到返回的token。
3. 观察Log：第10条消息发出后，后续的同步消息回调全部不再打印，主线程好像“睡着”了。
4. 再用反射调用removeSyncBarrier(token)，观察同步消息又开始陆续打印。

这个实验能直观体会到“屏障把同步消息堵住了”的过程。做完后记得把反射代码删掉，尤其是removeSyncBarrier的token要确保被调用，不然测试页面会一直卡死。要是想更精细地看屏障在队列里的位置，可以在next()方法里打Log，但那样就要自己编译源码或者用调试器看变量，成本会更高一些。

4.4 把源码读串起来的建议

到这里，同步屏障这条线基本就讲透了。如果你想把这套机制彻底变成自己的东西，我建议按下面的顺序自己读一遍源码：

先是Looper.loop()，看线程是怎么循环取消息的；然后看MessageQueue.next()，重点理解三件事：什么时候取同步消息、什么时候跳过同步消息、什么时候阻塞。再看Message的FLAG_ASYNCHRONOUS和isAsynchronous()，搞清楚异步标记是怎么设置的。最后去看ViewRootImpl.scheduleTraversals()和Choreographer.FrameHandler，把屏障插入、异步回调发送、屏障移除这一整条链路串起来。

这四步走完，你对Handler消息机制的理解，就不再是背面试题，而是真正能应付线上问题排查的水平了。如果你在阅读时有什么卡壳的细节，建议用调试器在关键方法上打断点，一步步看队列里的Message变化，比读十遍文章都有效。

我个人很喜欢同步屏障这一点设计，因为它是“用调度顺序解决优先级问题”的经典案例。它没有引入复杂的高优队列、没有破坏消息顺序，只用一个特殊标记和一次遍历，就实现了UI任务的紧急插队。这种克制的设计，确实值得反复品味。