目录
前言
正在带妹子上分的我，团战又卡了，我该怎么向妹子解释？在线等。
一、“卡”的意思
不管是端游还是手游，我们都会时不时遇到“卡”的时候，一般这个卡有两种含义：
1、掉帧
2、画面撕裂
那么问题来了，这些情况到底是什么原因导致的？又该怎么解决？
二、掉帧
首先，要知道帧是什么，帧率又是什么。
- 帧，就是影像动画中最小单位的单幅影像画面，相当于电影胶片上的每一格镜头。一帧就是一幅静止的画面，连续的帧就形成动画，如电视图图像等。
- 帧率（每秒帧数），简单地说，就是在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刷新一次屏幕。
关于屏幕刷新机制，有一张很经典的图片：
可以看到，16.6ms 一到，系统就发送了 VSync 信号，然后屏幕会从缓存区获取了新的一帧图像并显示出来，与此同时，CPU 也开始了下一帧数据的计算，然后计算好交给 GPU，最后放到缓存区，等待下一次 VSync 信号。
VSync 信号是啥呢？我们暂且按下不表，待会再说，可以先理解它为一种同步刷新信号，同步 CPU 和屏幕。当信号来的时候，屏幕开始切换画面，CPU 开始下一帧计算。
为了方便理解，可以看下面的动画：
通过上面的解释，我们知道了一帧显示的时间是 16.6ms，在这个时间内，CPU 和 GPU 必须把数据处理好并放到缓存区（buffer）中。
如果在某次的 16.6ms 中，CPU 和 GPU 没有绘制好下一帧数据，那么 display 就无法更新下一帧数据了，这就是掉帧。
所以才有了以上三个原因会导致掉帧，再来回顾下：
- 硬件原因。硬件比较差也就是 CPU 和 GPU 计算不给力，导致一帧的数据没准备好，所以掉帧。
- 软件原因。在硬件够用的情况下，App 或者游戏的一帧数据计算繁杂，嵌套太多或者图太大，也会导致下一帧数据不能在16.6ms 中被准备好，导致掉帧。
- 网络原因。在硬件软件都正常情况下，由于网络波动，CPU 的计算数据都没有从网络上获取到，那么肯定会导致 CPU 数据的准备延迟，最终导致掉帧。
那么掉帧之后，屏幕刷新机制会怎么处理后续的帧呢？
- 如果是游戏的话，因为即时性比较重要，所以丢失的帧就不会再去管了，而是直接准备当前时间应该显示的内容，最终显示到屏幕。所以这种情况掉的帧就真的掉了。
- 如果是应用的话，可能对数据的完整性比较重要，所以如果第2 帧掉了，那么屏幕就继续显示第 1 帧，而 CPU 和 GPU 继续准备第 2 帧的数据，如果能在下一个 16.6ms 内完成第 2 帧数据，那么屏幕就会接着显示第 2 帧了。比如手机卡的时候，我们去操作 App，操作会延迟，就是掉帧了。这种情况帧并不是真的掉了，而是延迟了。
画面撕裂
接下来就看看画面撕裂，为什么一帧中会出现两帧的画面呢？
首先理解一个概念：「逐行扫描」。
「逐行扫描」就是说，显示器显示画面并不是“蹭”一下就打出一张画面来，而是从上到下一行一行显示出来的，只不过是显示得比较快所以肉眼看不出来而已。
之前说了屏幕的数据是从缓存区 Buffer中 取的，如果在屏幕取数据并逐行扫描显示画面的过程中，Buffer 中的数据变了，那么就有可能导致画面撕裂。
最明显的例子就是：显卡的 fps 是 180，而显示器的 fps 是 60。也就是显卡一秒钟能产生 180 张画面，而显示器一秒钟只能读取 60 张画面。那么显示器从 Buffer 中读取数据逐行扫描的过程中，本来需要 1/60 秒显示完一张画面，但是在 1/180 的时间点，显卡就把下一张画面的数据存到 Buffer 了，结果显示器的下半截就显示的是第二张画面的内容了。也就造成了画面撕裂。
再来个动画解释下：
所以为了防止这种状况，一般显示系统会加入一个双缓存 + 垂直同步的概念：
首先，开启垂直同步，就会将 GPU 的 fps 限制为和显示器的 fps 一样。
系统会在显示器绘制完一帧之后发送一个垂直同步信号，然后 CPU和 GPU 就准备下一帧的内容，等待显示器下一帧绘制完，又会发送一个垂直同步信号。如此反复，就限制了显卡的 fps，按照显示器的标准来绘制图像。
这个垂直同步信号就叫做 VSync 信号。
玩游戏的朋友应该都知道，很多游戏内设置页都有【垂直同步】的开启选项，为的就是将显卡的 fps 和显示器的 fps 适配，防止画面撕裂。
其次，通过双缓存保证一帧数据的连贯性。
1、缓存区 backBuffer 用于 CPU/GPU 图形处理。
2、缓存区 frameBuffer 用于显示器显示。
这样分工明确之后，屏幕只会读取 framebuffer 的内容，是一帧完整的画面。而 CPU/GPU 计算的新一帧内容会放到 backbuffer 中，不会影响到 framebuffer 的内容。
只有当屏幕绘制完一帧内容之后，才会将 CPU/GPU 计算好的新一帧内容也就是 backbuffer 内容和 framebuffer 进行交换。
这样就保证了一帧数据的完整连贯。
小结下就是：当屏幕扫描完第 1 帧画面之后，系统发送 VSync 信号，这时会发生三件事：
1、交换两个缓存区（framebuffer、backbuffer）内容。
2、显示器开始显示第 2 帧内容，也就是交换后的 framebuffer 内容。
3、CPU/GPU 开始计算处理第 3 帧的内容，并在处理好内容后放到 backbuffer 中。
再来个动画：
Android Project Butter（黄油计划）
问题都解决了吗？并没有。
加入VSync信号之后，掉帧问题变得更严重了：
可以发现，加入了 VSync 信号后，虽然统一了 CPU 处理的时间点，但是掉帧问题可能会被再一次放大，从掉一帧直接变成后续一直掉帧。因为第二个的 16.6ms 被浪费了，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 能像黄油/奶油般顺滑。
最后贴个三缓存机制下的刷新机制图：
小结
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 的逻辑。