4. 垂直同步（V-Sync）：V-Sync如何与双缓冲协同工作？
好，前面我们把双缓冲的机制讲透了。但有个问题一直悬着——什么时候交换缓冲区？
你想想看，如果程序在帧中间突然交换前后缓冲，用户会看到什么？对，画面撕裂。上半截是旧帧，下半截是新帧，中间一条错位的缝。
垂直同步，就是来解决这个问题的。
4.1 撕裂是怎么产生的？
先看一个我早年踩过的坑。那时候刚做渲染引擎，双缓冲跑得挺欢，帧率飙到200多。结果一测试，画面时不时闪一下，截图一看——撕裂。
原因很简单：显示器是从上往下逐行扫描的。如果扫描到一半，你把后缓冲切到前缓冲，那上半部分显示的是旧帧，下半部分是新帧。这就是撕裂。
核心矛盾：GPU渲染完一帧随时可以交换缓冲区，但显示器只在固定的时间点（垂直消隐期）才安全。
4.2 V-Sync的工作原理
V-Sync说白了就是一句话：让缓冲区交换发生在显示器完成一帧扫描之后，下一帧扫描开始之前。
这个时间窗口叫垂直消隐期（VBlank）。显示器从右下角扫完最后一根线，回到左上角开始扫下一帧，中间那几毫秒就是VBlank。
V-Sync的工作流程是这样的：
- GPU渲染完一帧，写入后缓冲
- 检查VBlank信号——显示器是否在消隐期？
- 如果在VBlank，立即交换缓冲区，显示器读取新帧
- 如果不在VBlank，GPU等待，直到下一个VBlank到来
- 显示器完成当前帧扫描，进入VBlank，交换发生
嗯，这里要注意：等待期间GPU是空闲的。这就是为什么开了V-Sync，帧率会被锁在显示器刷新率上。
4.3 双缓冲 + V-Sync的完整流程
把双缓冲和V-Sync放在一起看，整个链路就清晰了。我画了一张图，帮你把时序理清楚：
从图上你能看到：GPU在渲染下一帧的同时，显示器在读取当前帧。两者并行工作，互不干扰。只有在VBlank那个窄窗口里，才发生一次缓冲区交换。
4.4 开启V-Sync的代价
V-Sync不是银弹。我做过一个项目，美术同学疯狂堆特效，GPU负载飙到16ms一帧。显示器是60Hz，VBlank周期16.7ms。结果呢？
GPU渲染完一帧花了18ms，错过了当前VBlank。它只能等下一个——16.7ms后。于是实际帧率掉到30fps。这就是经典的帧率抖动问题。
| 场景 | 无V-Sync | 有V-Sync |
|---|---|---|
| GPU负载轻（5ms/帧） | 200fps，画面撕裂 | 60fps，画面流畅无撕裂 |
| GPU负载适中（14ms/帧） | 71fps，轻微撕裂 | 60fps，稳定流畅 |
| GPU负载重（18ms/帧） | 55fps，明显撕裂 | 30fps，卡顿感明显 |
我曾经踩过的坑：在60Hz显示器上做VR项目，开了V-Sync。GPU偶尔超载一帧，结果帧率直接腰斩到30fps。用户戴上头显，画面一卡一卡的，差点吐了。后来改用自适应同步（G-Sync/FreeSync）才解决。
4.5 三种常见的V-Sync策略
实际工程中，V-Sync不是只有开和关。我整理了几种常见策略：
- 始终开启（强制V-Sync）：帧率锁在刷新率，GPU等待VBlank。适合对画面一致性要求高的场景，比如视频播放、办公应用。
- 始终关闭（禁用V-Sync）：GPU渲染完立即交换，帧率不受限。适合竞技游戏，用户愿意牺牲画质换响应速度。
- 自适应V-Sync：帧率高于刷新率时开启V-Sync，低于时自动关闭。我比较推荐这个——既避免了撕裂，又不会在低帧率时雪上加霜。
个人习惯：做UI框架时，我一般默认开启V-Sync。UI动画通常不重，60fps足够流畅。但如果是做数据可视化大屏，我会用自适应策略——毕竟大屏上偶尔撕裂比卡顿更难看。
4.6 双缓冲 + V-Sync的工程实现要点
最后聊几个实现细节。这些是我在OpenGL和Vulkan项目里摸爬滚打总结出来的：
- 交换时机要准：用eglSwapBuffers或vkQueuePresentKHR时，驱动会自动等待VBlank。但如果你自己管理交换链，记得查询显示器的刷新率周期。
- 小心帧率锁定陷阱：如果渲染时间刚好比VBlank周期长一点点，帧率会直接腰斩。这时候可以考虑三缓冲——我们下一章会细讲。
- 移动端要谨慎：手机屏幕刷新率五花八门，60Hz、90Hz、120Hz都有。我建议用系统API查询实际刷新率，别硬编码。
- 调试技巧：用glGetSynciv查询同步对象状态，可以精确知道GPU是否在等待VBlank。这个我在排查帧率异常时经常用。
嗯，V-Sync和双缓冲的配合，说白了就是用等待换完美。你让GPU等几毫秒，用户就看不到撕裂。但代价是帧率可能下降，甚至腰斩。怎么取舍？看你的应用场景。