垂直同步（V-Sync）原理：开启与关闭对卡顿的影响

聊双缓冲，绕不开垂直同步。很多同学觉得「开了 V-Sync 画面就稳了」，或者「关了 V-Sync 帧率就上去了」。说实话，这两种想法都只对了一半。

垂直同步到底是什么？说白了，它就是一个协调机制——让 GPU 渲染完一帧后，等显示器把当前帧完整扫完，再开始送下一帧。这个「等」的动作，就是 V-Sync 的核心。

显示器的刷新节奏

先看显示器怎么工作。以 60Hz 屏幕为例，它每秒从上到下扫描 60 次。每次扫描叫一个 VBlank 周期（垂直消隐期）。

• 扫描阶段：电子枪从左到右、从上到下逐行刷新像素
• VBlank 阶段：扫描完最后一行的像素后，电子枪回到左上角，准备下一帧

这个 VBlank 窗口，就是交换缓冲区的唯一安全时机。如果在扫描中途交换缓冲区，就会出现撕裂——上半部分是旧帧，下半部分是新帧。

开启 V-Sync 时的行为

我习惯把 V-Sync 开启后的流程画成一张图，这样更直观：

看到没？帧1在 8ms 就渲染完了，但 VBlank 窗口在 16ms 才到。中间这 8ms，GPU 是空转等待的。这就是 V-Sync 的第一个代价：引入额外延迟。

关闭 V-Sync 时的行为

关了 V-Sync，GPU 就不管显示器了。渲染完一帧，直接往 Front Buffer 里写。这时候如果显示器正在扫描，就会读到半新半旧的数据——撕裂就出现了。

但关 V-Sync 还有个隐藏问题：帧率波动加剧。GPU 不再被 VBlank 窗口「卡住」，渲染速度完全取决于场景复杂度。复杂场景 40fps，简单场景 120fps，这种剧烈波动反而让眼睛更累。

为什么 V-Sync 不能解决所有卡顿

这是本章的重点。我见过太多人以为「开了 V-Sync 就不卡了」，结果该卡还是卡。为什么？

V-Sync 只解决一个问题：撕裂。它不解决以下问题：

卡顿类型	V-Sync 能解决吗	根本原因
画面撕裂	✅ 完全解决	缓冲区交换时机不对齐
帧率抖动	❌ 不能	渲染耗时波动，V-Sync 只对齐交换时机
输入延迟	❌ 反而加重	等待 VBlank 引入额外延迟
掉帧（Frame Drop）	❌ 不能	渲染超时导致错过 VBlank，直接丢帧
微卡顿（Micro Stutter）	❌ 不能	渲染耗时在 VBlank 边界附近反复横跳

你看，V-Sync 能解决的只有撕裂。其他问题，它要么无能为力，要么反而加重。

V-Sync 的三种工作模式

现代图形 API 提供了更细粒度的控制。我整理了一张对比表：

模式	行为	适用场景
立即交换	渲染完直接交换，无视 VBlank	竞技游戏、低延迟要求
垂直同步（标准）	等待 VBlank 再交换，消除撕裂	普通游戏、视频播放
自适应 V-Sync	帧率高于刷新率时开启 V-Sync，低于时关闭	帧率波动大的场景

自适应 V-Sync 是我个人比较推荐的方式。它试图在「撕裂」和「延迟」之间找平衡——帧率高时锁住避免撕裂，帧率低时放开避免卡顿。

V-Sync 与双缓冲的交互

双缓冲 + V-Sync 的组合，有个经典问题：当渲染耗时刚好超过 VBlank 周期时，会发生什么？

假设显示器是 60Hz（16.67ms 一帧），渲染一帧需要 18ms：

1. 帧1 开始渲染，耗时 18ms
2. 第 16.67ms 时 VBlank 到来，但帧1 还没渲染完
3. V-Sync 强制等待下一个 VBlank（再等 16.67ms）
4. 帧1 在 18ms 时完成，但只能等到 33.33ms 才交换
5. 实际帧率从 60fps 直接掉到 30fps

这就是著名的 「60 掉 30」现象。渲染耗时只多了 1.33ms，帧率却直接腰斩。你想想看，这合理吗？

嗯，这一章我们先把 V-Sync 的原理和局限讲清楚。后面几章会深入双缓冲的具体实现，以及如何绕过 V-Sync 的坑。