首先介绍一下自己。 电脑水本，考研与我无缘。 以前在帝都某公司的算法部实习。 公司是大公司吧。 但是，我个人喜欢开发，大二的时候写了一个APP，主要使用各种各样的框架。
二、显示系统的基础知识在典型的显示系统中一般包括CPU、GPU、Display三部分，CPU负责帧数据的计算，并将计算出的数据传递给GPU，GPU呈现图形数据
2.1基本概念屏幕刷新频率秒期间屏幕被更新的次数(每秒显示多少帧图像)、单位Hz (赫兹)、常见的60 Hz )。刷新频率取决于硬件的固定参数(不变)。
逐行扫描显示器不是一次在屏幕上显示屏幕，而是从左到右，从上到下逐行扫描，按顺序显示整个屏幕上的每一个像素点，但这个过程人眼无法识别变化以60 Hz刷新率屏幕为例，该过程为1000/60 16ms。
帧率(framerate )表示http://www.Sina.com/，单位fps。 例如，在电影界采用24帧的速度，可以使画面顺利移动。 安卓系统采用了更为流动的60 fps。 也就是说，GPU每秒绘制最多60帧的屏幕。 帧速率是动态变化的。 例如，当屏幕静止时，GPU没有绘制操作。 画面正在刷新的是buffer的数据。 也就是说，这是GPU最后操作的帧数据。
33558www.Sina.com/(tearing )一个屏幕中的数据来自两个不同的帧，导致屏幕撕裂，如下图所示
2.2双缓存器2.2.1画面断裂原因画面刷新频率固定，如每16.6ms从缓存器中取数据显示一帧，理想情况下帧率与刷新频率一致。 也就是说，每当绘制结束时显示一帧。 但是，由于CPU/GPU无法控制数据的写入，错误中有完全不显示而被改写的数据。 这意味着错误中的数据可能来自不同的帧，当屏幕刷新时，此时不知道错误的状态，因此从错误中捕获的帧不是完整的帧，屏幕会被撕裂。
简单来说，Display在显示过程中，buffer内的数据会被CPU/GPU修正，画面会被撕裂。
2.2.2双缓存如何解决画面裂缝？ 答案是使用双缓存。
由于绘制图像和导入屏幕使用的是相同的错误，因此刷新屏幕时可能会导入不完整的帧。
3358www.Sina.com/使绘图和显示器具有各自的缓冲区。 GPU总是将完成的1帧图像数据写入GPU 在一秒内绘制操作的帧数，但显示器使用画面撕裂，画面刷新后显示成帧缓冲器，如下图所示：
2.2.3 VSync问题又来了。 什么时候进行两个buffer的交换？
如果Back buffer在完成一帧的数据后进行，此时如果屏幕上没有完全显示前一帧的内容，则一定会出现问题。 在画面处理完一帧的数据之前，这似乎无法执行。
扫描屏幕后，设备必须再次返回到第一行并进入下一个循环。 此时，存在一个称为verticalblankinginterval(VBI )的间隙。 那个时候是进行缓冲交换的最佳时间。 此时屏幕尚未更新，因此也可以避免在交换过程中出现屏幕修整。
双缓存(垂直同步)是VerticalSynchronization的缩写，利用VBI时代出现的vertical sync pulse )垂直同步脉冲)使得双缓冲器能够在最佳时间点被交换另外，交换是指各自的存储器地址，该操作被认为会瞬间完成。
所以，V-sync这个概念并不是谷歌首创的，在早期的PC领域已经出现了。
三、安卓屏幕更新机制3.1安卓4.1之前的问题具体在于安卓。 在安卓4.1之前，屏幕更新也遵循上面介绍的双缓存VSync机制。 下图：
按时间顺序看，如下。
Display显示第0帧的数据。 此时，CPU和GPU渲染第一帧的画面。 然后，在Display显示下一帧之前完成。 Display将在第0帧显示完成后，即第一个VSync后更换缓存。 然后，正常显示，第一帧之后的第二帧开始处理。 在第二个VSync早点到来之前不开始处理。 当第二个VSync到来时，第二帧中的数据尚未准备好，因此未更换缓存，而显示的仍然是第一帧。 此情况由Android开发组命名为" Jank "，Back Buffer第2帧的数据准备就绪后，不会立即显示，而是等待进行缓存交换后再显示下一个VSync。 所以总的来说
，就是屏幕平白无故地多显示了一次第1帧。原因是 第2帧的CPU/GPU计算 没能在VSync信号到来前完成 。
我们知道，双缓存的交换 是在Vsyn到来时进行，交换后屏幕会取Frame buffer内的新数据，而实际 此时的Back buffer 就可以供GPU准备下一帧数据了。 如果 Vsyn到来时 CPU/GPU就开始操作的话，是有完整的16.6ms的，这样应该会基本避免jank的出现了（除非CPU/GPU计算超过了16.6ms）。 那如何让 CPU/GPU计算在 Vsyn到来时进行呢？
3.2 drawing with VSync为了优化显示性能，Google在Android 4.1系统中对Android Display系统进行了重构，实现了Project Butter（黄油工程）：系统在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知（16ms触发一次），CPU和GPU 才立刻开始计算然后把数据写入buffer。如下图：
CPU/GPU根据VSYNC信号同步处理数据，可以让CPU/GPU有完整的16ms时间来处理数据，减少了jank。
一句话总结，VSync同步使得CPU/GPU充分利用了16.6ms时间，减少jank。
问题又来了，如果界面比较复杂，CPU/GPU的处理时间较长 超过了16.6ms呢？如下图：
在第二个时间段内，但却因 GPU 还在处理 B 帧，缓存没能交换，导致 A 帧被重复显示。而B完成后，又因为缺乏VSync pulse信号，它只能等待下一个signal的来临。于是在这一过程中，有一大段时间是被浪费的。当下一个VSync出现时，CPU/GPU马上执行操作（A帧），且缓存交换，相应的显示屏对应的就是B。这时看起来就是正常的。只不过由于执行时间仍然超过16ms，导致下一次应该执行的缓冲区交换又被推迟了——如此循环反复，便出现了越来越多的“Jank”。为什么 CPU 不能在第二个 16ms 处理绘制工作呢？
原因是只有两个 buffer，Back buffer正在被GPU用来处理B帧的数据， Frame buffer的内容用于Display的显示，这样两个buffer都被占用，CPU 则无法准备下一帧的数据。 那么，如果再提供一个buffer，CPU、GPU 和显示设备都能使用各自的buffer工作，互不影响。
3.3 三缓存三缓存就是在双缓冲机制基础上增加了一个 Graphic Buffer 缓冲区，这样可以最大限度的利用空闲时间，带来的坏处是多使用的一个 Graphic Buffer 所占用的内存。
第一个Jank，是不可避免的。但是在第二个 16ms 时间段，CPU/GPU 使用 第三个 Buffer 完成C帧的计算，虽然还是会多显示一次 A 帧，但后续显示就比较顺畅了，有效避免 Jank 的进一步加剧。
注意在第3段中，A帧的计算已完成，但是在第4个vsync来的时候才显示，如果是双缓冲，那在第三个vynsc就可以显示了。
三缓冲有效利用了等待vysnc的时间，减少了jank，但是带来了延迟。 所以，是不是 Buffer 越多越好呢？这个是否定的，Buffer 正常还是两个，当出现 Jank 后三个足以。
以上就是Android屏幕刷新的原理了。
最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识，这里放上相关的我搜集整理的24套腾讯、字节跳动、阿里、百度2020-2021面试真题解析，我把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包知识脉络 + 诸多细节。
还有 高级架构技术进阶脑图、Android开发面试专题资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。
点击：
《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
转存中…(img-sVwNNfyM-1615465327824)]
点击：
《Android架构视频+BAT面试专题PDF+学习笔记》即可免费获取~
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。