前言

正在带妹子上分的我，团战又卡了，我该怎么向妹子解释？在线等。

“卡”的意思

不管是端游还是手游，我们都会时不时遇到“卡”的时候，一般这个卡有两种含义：

• 掉帧

0-2.gif

• 画面撕裂

3.png

那么问题来了，这些情况到底是什么原因导致的？又该怎么解决？

掉帧

首先，要知道帧是什么，帧率又是什么。

帧，就是影像动画中最小单位的单幅影像画面，相当于电影胶片上的每一格镜头。 一帧就是一幅静止的画面，连续的帧就形成动画，如电视图象等。

帧率（每秒帧数），简单地说，就是在1秒钟时间里传输的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次，通常用fps（Frames Per Second）表示

这下大家应该知道了，帧就是一个静止画面，很多个帧一起就组成了视频、电影、游戏画面。

而帧率就是我们游戏常见到的fps，指一秒钟绘制出现的帧数，单位为“赫兹”（Hz）。

这里简单科普下，一般要求连贯性的话，帧数至少要高于每秒约10至12帧的时候，人眼才会认为是连贯的，此现象叫做“视觉暂留现象”，是由人眼的生物构造决定的。通过这个现象，早期的无声电影通过手摇驱动，将画面快速播放，就能让人感觉在播放完整连续的视频。

按照我们的认知，这个帧率一般是越大越连贯，就越不卡。但同时，带来的消耗也就越多，比如电影需要更多的胶卷，电脑需要更好的硬件支持。所以电影一般通用的帧率为24Hz，而电脑、手机一般帧率为60Hz，这样就能保证正常条件下能让人舒服得观看和使用。

那掉帧的意思就很明显了，本来游戏的fps为60，突然降到了20，也就是一秒只有20帧了，那能不卡吗？

那么，掉帧原因到底是啥呢？

其实原因大家都知道，不信你继续看...

硬件原因

“我这个手机玩游戏卡死了”

“你那啥破手机啊，赶快换一个～”

这个对话应该时常发生，所以大家也都清楚，硬件的好坏一定程度上决定了玩游戏“卡不卡”，配置高的硬件玩游戏就能保证游戏的流畅。

软件原因

“你这啥App啊，做的啥游戏啊，这么卡，我这手机配置这么高，就玩你这个卡”

“额，可能是游戏优化没做好，”

第二个原因，就是因为游戏/软件自身的优化就没做好，图片弄的很大，布局嵌套太深，那么帧 的计算和渲染就更耗时间，就会有可能导致掉帧。

网络原因

“不行了，太卡了，我这ping都快1000了，怎么玩啊”

“快换流量啊，团战要输了，少个人怎么打”

对了，第三个原因就是网络原因，这也是最常发生的原因了，网络的波动会影响 画面 的传输，所以就会掉帧。

屏幕刷新机制

上述三个原因，其实都涉及到屏幕刷新的基本机制。

在典型的显示系统中，不管是手机还是电脑，一般都涉及到三个部分：

• CPU，中央处理器。用于计算数据，信息处理。
• GPU，图形处理器。用于处理图像图形，也就是俗称的显卡。
• display，显示屏幕。用于展示画面，也就是我们的手机屏幕、电脑显示器。

整个显示过程就是：

• CPU计算屏幕需要的数据，然后交给GPU。
• GPU对图像进行处理绘制，然后存到缓存区。
• display再从这个缓存区读取数据，显示出来。

每一帧都是重复这个工作，也就是1秒中需要60次这样循环操作，每次操作需要的时间就约等于16.6ms。也就是我们常说的Android系统中，会每隔16.6ms刷新一次屏幕。

关于屏幕刷新机制，有一张很经典的图片：

image

可以看到，16.6ms一到，系统就发送了VSync信号，然后屏幕会从缓存区获取了新的一帧图像并显示出来，与此同时，CPU也开始了下一帧数据的计算，然后计算好交给GPU，最后放到缓存区，等待下一次VSync信号。

VSync信号是啥呢？我们暂且按下不表，待会再说，可以先理解它为一种同步刷新信号，同步CPU和屏幕。当信号来的时候，屏幕开始切换画面，CPU开始下一帧计算。

为了方便理解，我做了个小动画：

g1.gif

通过上面的解释，我们知道了一帧显示的时间是16.6ms，在这个时间内，CPU和GPU必须把数据处理好并放到缓存区（buffer）中。

如果在某次的16.6ms中，CPU和GPU没有绘制好下一帧数据，那么display就无法更新下一帧数据了，这就是掉帧。

所以才有了以上三个原因会导致掉帧，再来回顾下：

• 1、硬件原因。硬件比较差也就是CPU和GPU计算不给力，导致一帧的数据没准备好，所以掉帧。
• 2、软件原因。在硬件够用的情况下，App或者游戏的一帧数据计算繁杂，嵌套太多或者图太大，也会导致下一帧数据不能在16.6ms中被准备好，导致掉帧。
• 3、网络原因。在硬件软件都正常情况下，由于网络波动，CPU的计算数据都没有从网络上获取到，那么肯定会导致CPU数据的准备延迟，最终导致掉帧。

那么掉帧之后，屏幕刷新机制会怎么处理后续的帧呢？

• 如果是游戏的话，因为即时性比较重要，所以丢失的帧就不会再去管了，而是直接准备当前时间应该显示的内容，最终显示到屏幕。所以这种情况掉的帧就真的掉了。
• 如果是应用的话，可能对数据的完整性比较重要，所以如果第2帧掉了，那么屏幕就继续显示第1帧，而CPU和GPU继续准备第2帧的数据，如果能在下一个16.6ms内完成第2帧数据，那么屏幕就会接着显示第二帧了。比如有时候手机卡的时候，我们去操作App，操作会延迟，就是掉帧了。这种情况帧并不是真的掉了，而是延迟了。

画面撕裂

接下来就看看画面撕裂，为什么一帧中会出现两帧的画面呢？

首先理解一个概念：「逐行扫描」

「逐行扫描」就是说，显示器显示画面并不是“蹭”一下就打出一张画面来，而是从上到下一行一行显示出来的，只不过是显示得比较快所以肉眼看不出来而已。

之前说了屏幕的数据是从缓存区Buffer中取的，如果在屏幕取数据并逐行扫描显示画面的过程中，Buffer中的数据变了，那么就有可能导致画面撕裂。

最明显的例子就是：显卡的fps是180，而显示器的fps是60。也就是显卡一秒钟能产生180张画面，而显示器一秒钟只能读取60张画面。

那么显示器从Buffer中读取数据逐行扫描的过程中，本来需要1/60 秒显示完一张画面，但是在1/180的时间点，显卡就把下一张画面的数据存到Buffer了，结果显示器的下半截就显示的是第二张画面的内容了。也就造成了画面撕裂。

再来个动画解释下：

g2.gif

所以为了防止这种状况，一般显示系统会加入一个双缓存+垂直同步的概念：

• 首先，开启垂直同步，就会将GPU的fps限制为和显示器的fps一样。

系统会在显示器绘制完一帧之后发送一个垂直同步信号，然后CPU和GPU就准备下一帧的内容，等待显示器下一帧绘制完，又会发送一个垂直同步信号。如此反复，就限制了显卡的fps，按照显示器的标准来绘制图像。

这个垂直同步信号就叫做 VSync信号。

玩游戏的朋友应该都知道，很多游戏内设置页都有 垂直同步 的开启选项，为的就是将显卡的fps和显示器的fps适配，防止画面撕裂。

• 其次，通过双缓存保证一帧数据的连贯性。

1、缓存区backBuffer用于CPU/GPU图形处理
2、缓存区frameBuffer用于显示器显示

这样分工明确之后，屏幕只会读取framebuffer的内容，是一帧完整的画面。而CPU/GPU计算的新一帧内容会放到backbuffer中，不会影响到framebuffer的内容。

只有当屏幕绘制完一帧内容之后，才会将CPU/GPU计算好的新一帧内容也就是backbuffer内容和framebuffer进行交换。

这样就保证了一帧数据的完整连贯。

这里的交换其实就是交换内存地址，两块缓存区A和B，A在第一次充当framebuffer的角色，B充当backbuffer的角色。屏幕完成一帧绘制之后，将AB内存地址置换。
当新的一轮VSync信号来的时候，A就充当了backbuffer的角色，而B就变成了framebuffer的角色。

小结：当屏幕扫描完第1帧画面之后，系统发送VSync信号，这时会发生三件事：

• 1、交换两个缓存区（framebuffer、backbuffer）内容。
• 2、显示器开始显示第2帧内容，也就是交换后的framebuffer内容。
• 3、CPU/GPU开始计算处理第三帧的内容，并在处理好内容后放到backbuffer中。

再来个动画：

g3.gif

Android Project Butter（黄油计划）

问题都解决了吗？并没有。

加入VSync信号之后，掉帧问题变得更严重了：

4.png

可以发现，加入了VSync信号后，虽然统一了CPU处理的时间点，但是掉帧问题可能会被再一次放大，从掉一帧直接变成掉两帧。因为中间的16.6ms被浪费了。

怎么办呢？在保留VSync信号的同时有可能最大利用上CPU/GPU吗？

三缓存来了：

1、缓存区backBuffer用于CPU/GPU图形处理
2、缓存区TripleBuffer用于CPU/GPU图形处理
3、缓存区frameBuffer用于显示器显示

刚才说的情况导致的原因就是因为在第二个VSync信号来的时候，因为backBuffer被GPU占用，所以CPU无法去开始新一帧的计算。
加入了第三个缓存区，那么在第二个VSync信号来的时候，CPU就可以利用TripleBuffer开始新一帧的计算，而无视正在被GPU占用的backBuffer。

你可以理解为 CPU、GPU、Display每个人都有一个缓存区，这样三个就能同时做自己的事而互不影响，最大化利用每个模块。

三缓存和上面说到的Vsync同步信号都是 Android 4.1 发布的一个Project Butter（黄油计划）中提出的，为的是就是让Android能让黄油/奶油般顺滑。

最后贴个三缓存机制下的刷新机制图：

5.png

小结

今天了解了Android系统的刷新机制，虽然没有代码，但是面试中也是常常被问到的，再次总结下：

1、为了解决画面撕裂问题，引入了垂直同步信号VSync信号和双缓存。

• 每次VSync信号到达的时候，屏幕进行画面切换，CPU/GPU开始准备下一帧内容。
• CPU/GPU每次准备好数据后，放到一个单独的缓存区backBuffer，当屏幕准备好之后，将backBuffer数据和frameBuffer数据交换，屏幕只读取frameBuffer缓存区的数据，保证了数据的完整连续性。

2、为了解决VSync信号下CPU/GPU无法最大化利用的问题，引入了三缓存。

当VSync信号来的时候，即使GPU还没处理好上一帧数据，backBuffer还不空闲，但是CPU也可以利用第三个缓存区正常开始处理下一帧的数据，最大化利用CPU/GPU，保证垂直同步机制的同时不浪费资源。

3、掉帧的根本原因是因为在一帧时间内（一般为16.6ms），CPU/GPU无法把下一帧的数据准备好。

即使引用了三缓存和垂直同步，但是掉帧的情况该发生还是会发生，我们作为App软件开发者，能做的就是尽可能优化布局，减少嵌套，减少CPU/GPU计算画面数据的时间，让每一帧时间内正常准备好下一帧图像数据。

至于刷新机制在Android源码中到底是怎么实现的呢？这就涉及到Choreographer类的解析。

参考

屏幕刷新机制
为什么【垂直同步】技术往往不被玩家推崇
Android Project Butter分析
FrameBuffer初探

拜拜

感谢大家的阅读，有一起学习的小伙伴可以关注下我的公众号——码上积木❤️❤️
每天一个知识点，建立完整知识体系架构。
这里有一群很好的Android小伙伴，欢迎大家加入～