往期推文全新看点（文中附带全新鸿蒙5.0全栈学习笔录）

✏️ 鸿蒙（HarmonyOS）北向开发知识点记录~

✏️ 鸿蒙（OpenHarmony）南向开发保姆级知识点汇总~

✏️ 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？

✏️ 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~

✏️ 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？

✏️ 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？

✏️ 记录一场鸿蒙开发岗位面试经历~

✏️ 持续更新中……

---

屏幕显示原理：

屏幕显示是通过类似逐行扫描而把图像显示到屏幕上，而其在底层则是通过一个帧缓存区映射到屏幕显示器上的。也就是通过CPU对图像的数据进行处理，交给显示处理器，显示处理器再处理成图像数据存储到帧缓冲区等待视频控制器的信号，将帧缓冲区的内容同步到显示器。

异常场景：

• 图像撕裂：

假设显示器的刷新率是60Hz，但是显卡每秒能够画120张图片。显卡每一秒往帧缓存器放120张图片，但是显示器每秒只能拿走60张，两者之间又没有沟通，显示器不知道显卡很强，显卡也不知道显示器速度太慢，一直往帧缓存器里写，等它写满了帧缓存器，就用新的图片从头覆盖，于是，显示器还没来得及拿走的图片，就被显卡重新覆盖掉了。结果就是，画面呈现到一半，下面的跟上面的画面完全对不上。

• 跳帧：

如果显卡速度更快那么下一帧的图像还没来得及显示，下下一帧的数据就覆盖上来了，中间这帧就跳过了。

• 图像缺失：

如果显卡帧率小于显示器刷新率，那每次在屏幕上看到的可能不是完整的图形，每次看到的图形比上次更完整一些。

• 掉帧：

当GPU渲染速度小于屏幕刷新速度时，则屏幕将会继续绘制上一帧画面，这样就会导致画面掉帧（也就是卡顿）的现象。

优化方案：

针对图像撕裂，跳帧问题HarmonyOS采用与业界对标的垂直同步信号（Vsync信号）解决，原理是让显卡适应显示器的刷新率，如果显示器刷新来不及，就让显卡等一等。

针对图像缺失，画面闪烁问题，又在Vsync信号的基础上，增加了双缓冲机制。 但是双缓冲机制会导致频繁掉帧，CPU资源浪费等问题。

针对频繁掉帧现象又引进了三缓冲机制，大大降低掉帧概率并提高CPU效率。

• Vsync 信号：

Vsync 信号一般是由硬件（屏幕）产生的，每个 Vsync 信号之间的时间，就是每一帧生产 / 消费的间隙。

为了把显示器的显示和系统视频控制器同步，显示器会用硬件时钟产生一系列定时信号。当扫描到换行时，显示器会发出一个水平同步信号HSync。当一帧画面绘制完成后，扫描回复到原位，再准备绘制下一帧前，显示器会发出一个垂直同步信号VSync。显示器通常以VSync信号的频率来刷新。此时CPU计算好画面数据并提交到GPU，GPU渲染完成后将渲染结果放入帧缓冲区，随后视频控制器就会按照VSync信号逐行读取帧缓冲区的数据，然后在显示器上显示。

• 双缓冲机制：

GPU 开辟A、B两个缓冲区，并对缓冲区进行同步加锁处理，执行流程就是当A缓冲区拿到第一帧数据，就给A缓冲区加上一把锁，屏幕控制器从A拿到数据并逐行扫描完成，A帧缓冲区解锁，并把屏幕控制器指向B缓冲区，B缓冲区加锁并逐行扫描显示，在屏幕控制器扫描B缓冲区的时候，A缓冲区拿到GPU传过来的新数据，以此类推。

通过上述图片可以看出，双缓冲区+垂直同步会解决图像显示不全的问题，但是A图像本来应该显示一帧，但是由于GPU与CPU处理速度太慢导致了A的这一帧显示了两次，从而导致B晚一帧显示出来，这就导致了新问题掉帧，掉帧并不是丢失图片，而是屏幕重复渲染了同一帧数据。

另外也可以看出来期间存在CPU资源浪费，双缓冲只会提供两个Buffer，B被GPU处理占用，A正在用显示，那么在第二个16ms里面，CPU就无法获取到Buffer处理UI更新，在Jank的阶段空空等待。而且，一般出现这种场景都是连续的：比如复杂视觉效果，那么GPU可能会一直超负荷，CPU一直跟GPU抢Buffer，这样带来的问题就是滚雪球似的掉帧，一直浪费，完全没有利用CPU与GPU并行处理的效率，成了串行处理。为了解决该问题提出了三缓冲概念。

• 三缓冲机制：

多增加一个Buffer给CPU用，让它提前忙起来，这样就能做到三方都有Buffer可用，CPU不用跟GPU争一个Buffer，真正实现并行处理。

如上图所示，虽然即使每帧需要的时间都超出了预期，但是由于多加了一个Buffer，实现了CPU跟GPU并行，便可以做到了只在开始掉一帧，后续却不掉帧，双缓冲充分利用16.67ms（一般60hz的刷新率，对应每隔16.667ms就会刷新一次）做到低延时，并保障了其稳定性。