性能优化与调试：帧率控制、脏矩形、垂直同步与闪烁排查
双缓冲移植完了，画面也出来了。但别急着庆祝——你很可能发现：要么卡成幻灯片，要么 CPU 占用飙到 100%，要么屏幕一闪一闪像在蹦迪。
嗯，这些我都经历过。有一次给一个嵌入式设备做界面移植，双缓冲跑起来后帧率只有 12fps，用户点一下按钮要等半秒才有反应。后来一步步排查，发现是刷新策略太粗暴——每次全屏重绘，哪怕只改了一个像素。
这一章，我们就来聊聊怎么让双缓冲跑得又快又稳。
帧率控制（FPS）
帧率，说白了就是每秒能刷多少帧。人眼觉得流畅的底线一般是 30fps，60fps 就很舒服了。但帧率不是越高越好——你想想看，如果屏幕只有 60Hz，你跑 120fps 纯属浪费 CPU。
我常用的帧率控制方式有两种：
- 固定帧率循环：用定时器或 sleep 控制每帧间隔。比如 60fps，每帧 16.67ms。
- 自适应帧率：根据实际绘制耗时动态调整，适合负载波动大的场景。
下面是一个简单的固定帧率循环示例：
import time
def run_loop(target_fps=60):
frame_time = 1.0 / target_fps
while True:
start = time.time()
# 绘制一帧
render_frame()
swap_buffers()
elapsed = time.time() - start
sleep_time = frame_time - elapsed
if sleep_time > 0:
time.sleep(sleep_time)
脏矩形更新策略
全屏重绘是最简单粗暴的方式，但效率极低。脏矩形（Dirty Rect）的思路是：只重绘发生变化的那一小块区域。
举个例子：你界面上有个进度条在动，其他区域完全没变。如果全屏重绘，每次都要刷新整个 1920x1080 的画面。用脏矩形，只需要重绘进度条那几十个像素高的区域——性能差距可能是几十倍。
脏矩形的核心流程：
- 标记发生变化的最小矩形区域
- 合并相邻或重叠的脏矩形
- 只对合并后的脏矩形区域进行绘制
- 将脏矩形区域从后台缓冲区拷贝到前台
我在项目中遇到过最典型的场景：一个实时波形图，每秒更新 50 次。全屏重绘时 CPU 占用 40%，改用脏矩形后直接降到 5%。
关键点：脏矩形不是越小越好。如果脏矩形太多、太碎，合并和拷贝的开销反而会超过全屏重绘。我一般会设置一个阈值——当脏矩形面积超过屏幕面积的 60% 时，直接全屏重绘。
垂直同步（VSync）
垂直同步，很多人又爱又恨。爱它是因为能消除画面撕裂，恨它是因为会限制帧率。
画面撕裂是怎么来的？你想想看：显示器正在从上往下扫描画面，这时候你突然交换了缓冲区——上半屏还是旧画面，下半屏已经变成新画面了。结果就是一条明显的撕裂线。
VSync 的做法很简单：等显示器扫描完一帧（也就是垂直消隐期），再交换缓冲区。这样就能保证用户看到的始终是完整的画面。
| 模式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 关闭 VSync | 帧率不受限，响应快 | 画面撕裂 | 性能测试、非实时界面 |
| 开启 VSync | 无撕裂，画面平滑 | 帧率被限制在刷新率 | 视频播放、游戏 |
| 自适应 VSync | 帧率高于刷新率时开启，低于时关闭 | 实现复杂 | 高性能需求场景 |
常见闪烁问题排查
闪烁是双缓冲移植中最让人头疼的问题。明明代码逻辑没问题，画面就是一闪一闪的。我总结了几种常见原因：
- 缓冲区未清空：新帧绘制前，没有用背景色清空缓冲区。残留的旧画面和新画面叠加，造成闪烁。
- 绘制顺序混乱：先画了前景再画背景，或者绘制过程中缓冲区被意外访问。
- 交换时机不对：在显示器正在刷新时交换缓冲区，导致部分画面被覆盖。
- 多线程竞争：一个线程在绘制，另一个线程在交换，没有加锁保护。
我曾经排查过一个特别隐蔽的闪烁问题：代码里用了 memcpy 拷贝缓冲区，但源地址和目标地址有重叠——每次拷贝都会把一部分旧数据带到新画面里。折腾了两天才发现。
知识体系总览
下面这张图把本章的核心知识点串起来了。你可以把它当作调试时的检查清单：
说实话，性能优化这件事，没有银弹。每个平台、每个应用场景的瓶颈都不一样。但只要你掌握了帧率控制、脏矩形、垂直同步和闪烁排查这四把刀，大部分问题都能迎刃而解。
我个人的经验是：先跑起来，再跑快。不要一开始就追求极致性能，先把双缓冲调通，确保画面正确，然后再一步步优化。很多时候，一个脏矩形策略就能解决 80% 的性能问题。