屏幕缓存
Android 4.1 以前一直沿用double-buffer 双缓冲技术，也就是两块显示 Buffer，back buffer用于CPU/GPU下一帧的绘制准备，另一块 frame buffer 则用于屏幕显示，当back buffer准备就绪后，它们才进行交换。
但是如果我们的准备时间太久，有可能因为 主线程耗时阻塞，xml 布局文件层次过多冗余臃肿，绘制操作不当（onDraw中频繁创建对象） ，导致back buffer 缓冲数据迟迟没有准备好，那么屏幕上就会一直显示 frame buffer ，造成卡顿视觉。
双缓存
1、当CPU / GPC 准备B Buffer 内容时间过长，导致第一个VSYNC信号到来时不能交付 back Buffer ，那么屏幕上显示的还是之前的那块 PRE Buffer ， 并且 B Buffer 内容准备完成后，还需要等待下一个 VSYNC 信号才能交付。
2、因为在第二个 VSYNC 信号到来时，两块 Buffer 都已经被占用（一块用来显示 ，一块被 B Buffer 准备工作持有），所以当下一次绘制内容也存在延迟的情况也会造成连锁卡顿。（同一帧画面显示 2 次及以上）
三级缓存
解决上面问题的办法就是引入第三块 Buffer ， 在渲染 B 超时而且 Buffer A 又用于屏幕显示时，可以用第三块 Buffer 来进行C 的准备工作，这样便减少了后面的一次 Jank 发生
系统大部分情况下都会使用两个Buffer 来完成显示，只有在某一帧的处理时间超过 2 次 VSYNC 信号周期才会使用第三块 Buffer。
VSYNC
由于人眼与大脑之间的协作一般情况无法感知超过60FPS的画面更新。如果所看到画面的帧率高于12帧的时候，就会认为是连贯的，达到24帧便是流畅的体验，这也就是胶片电影的播放速度（24FPS）
对于屏幕显示，游戏体验来说，如果能整体平稳的达到60FPS，画面每秒更新60次，也就是16.67ms刷新一次，绝大部分人视觉体验都会觉得非常流畅如丝般顺滑。
vsync
Android没16毫秒会产生信号，然后分发给App进程和SurfaceFlinger进程用于绘制图像和合成图像
Vsync信号生成机制
Vsync分发流程
他是在surface-flinger进程中
HWComposer硬件生成信号
VsyncThread软件生成信号线程
sleep方式生成信号
DispSyncThread 分发工作线程线程
app-EventThread
app分发线程 用于绘制图像 响应在APP进程Choreographer线程
sf-EventThread
分发给Surfaceflinger 用于合成图像 响应是在surface-flinger主线程
Vsync分发流程
Vsync分发
有信号就是往发送的fd里面写数据，APP和surfaceflinger会收到这个时间
应用请求Vsync信号流程
网友评论