2、单缓冲的痛点：屏幕撕裂与闪烁的根源分析

上一章我们聊了双缓冲的基本概念。但有个问题我一直想先讲清楚——为什么非得用双缓冲？单缓冲到底哪里不行？

说实话，我刚入行做嵌入式GUI时，也觉得双缓冲是“杀鸡用牛刀”。那时候项目赶进度，我直接在单缓冲上画界面，结果被测试同事追着骂了三天。嗯，从那以后，我再也不敢小看这个“小问题”了。

2.1 单缓冲的工作机制

先看看单缓冲是怎么跑的。说白了，整个系统只有一块显存（Frame Buffer），CPU/GPU往里面写数据，显示控制器同时从里面读数据往屏幕上刷。

我画了一张流程图，帮你直观理解这个过程：

2.2 屏幕撕裂（Tearing）—— 半张新图，半张旧图

撕裂是怎么来的？我举个例子你就明白了。

假设屏幕正在从上往下刷新第 N 帧。刷新到一半时，CPU 已经把第 N+1 帧的数据写进了显存。这时候显示控制器读到的是——上半截是旧帧，下半截是新帧。一屏画面被“撕”成了两半。

撕裂的严重程度取决于几个因素：

因素	影响	典型场景
绘制速度 vs 刷新速度	绘制越快，撕裂概率越高	DMA2D 加速绘制时
画面变化幅度	变化越大，撕裂越明显	视频播放、动画切换
刷新率	刷新率越低，撕裂窗口越长	30Hz 刷新率下尤其严重
绘制区域	全屏重绘比局部重绘更容易撕裂	页面切换、滑动列表

2.3 屏幕闪烁（Flicker）—— 亮暗交替的视觉疲劳

闪烁和撕裂是两码事，但很多人混为一谈。

闪烁的根源在于：显存内容在刷新周期内被多次修改。显示控制器每扫一行就读一次显存。如果你在它扫到一半时改了显存，那这一帧里就会出现“亮一下、暗一下”的交替条纹。

我做过一个实验：在 320×240 的屏幕上，用单缓冲逐行绘制一个渐变矩形。结果屏幕像波浪一样闪动，看一分钟眼睛就酸了。

2.4 单缓冲的三大痛点总结

我把单缓冲的问题归纳成三点，你对照一下自己的项目：

1. 读写冲突——CPU 和显示控制器同时操作同一块内存，没有隔离机制。
2. 帧不完整——显示控制器可能读到“半成品”帧，导致画面撕裂。
3. 多次写入——复杂场景下需要多次修改显存，导致同一帧内亮度波动。

2.5 一个真实的避坑案例

我曾经接手过一个智能家居面板项目。上一任工程师用单缓冲 + 定时器刷新，结果客户投诉说“屏幕一闪一闪的，像坏了一样”。

我排查后发现：

• 主循环里每 20ms 刷新一次全屏
• 显示控制器刷新率是 50Hz（20ms 一帧）
• 两者周期几乎完全重合，每次刷新都撞车

解决方案其实不复杂——要么把刷新率错开，要么上双缓冲。但当时硬件已经定型，只能靠软件调整。我最后用了“垂直同步等待 + 局部刷新”的组合拳，勉强压住了问题。

但说实话，这只是治标不治本。真正彻底的解法，就是下一章要讲的双缓冲。

2.6 什么时候可以继续用单缓冲？

也不是所有场景都必须上双缓冲。我列了几个“可以凑合用单缓冲”的情况：

场景	原因	风险
静态界面（不变化）	显存只写一次，没有冲突	低
极低刷新率（1~5fps）	绘制和刷新错开概率大	中
小尺寸屏幕（128×64）	刷新时间极短，冲突窗口小	低
非实时系统（无动画）	用户不关注流畅度	低