屏幕刷新

帧率：GPU显卡生成帧的速率；
屏幕刷新率：硬件设备刷新屏幕的频率；

概述

屏幕刷新实际上就是view周期性的绘制到屏幕上的过程，Android系统每16ms（一般的安卓手机的FPS（每秒的帧数）是60）会请求一次VSync（垂直同步）信号，进行一次屏幕刷新。

屏幕刷新的入口：ViewRootImpl的scheduleTraversals方法，其中会通过Handler向主消息队列里面插入一个同步屏障，通过编舞者Choreographer向其中队列加入一个回调，其中封装了回调类型，一个TraversRunnable对象等，同时会通过native方法请求并等待下一个垂直同步信号的来临。

当请求到ASync信号之后会调用FrameDisplayEventReceiver的OnVsync方法，这个对象是一个Runnable,其中会向主线程发送一个异步消息并将自身实例传入。这个异步消息被取出时会调用它的Run方法，会将编舞者Choreographer中的回调取出并调用其中TraversalRunnable对象的run方法，它会先将主消息队列里面的同步屏障移除，最后调用ViewRootImpl的performTraversals方法（这就是绘制屏幕的入口）通知所有的子view进行,measure,layout,draw等方法进行重绘。
参考及详情见：https://blog.csdn.net/qq_43935080/article/details/107288309

屏幕撕裂

如果只有一块缓存，在没有加锁的情况下，容易出现：在屏幕更新的时候，如果显卡输出的帧率很高，在A帧上半部分数据刚刚更新完之后，B帧数据就到来了，如果没有采用同步锁的机制，则认为帧来了就用，再继续刷新下半部分的时候，由于只有一块缓存，A被B覆盖，下半部分绘制用的数据就是B帧，最后上半部分是A，下半部分是B，这就是屏幕撕裂。

屏幕撕裂

VSync+双缓存

如果是只多增加一块缓存区域，显卡绘制成功之后先写入BackBuffer,不影响当前正在展示得FrameBuffer，这就是双缓冲；但是BackBuffer里面得东西肯定是会显示的，会被“复制”到FrameBuffer,如果A帧还没有画完，BackBuffer如果不加予干预，直接“拷贝”到FrameBuffer同样也会出现撕裂。

如果仅仅是单缓存加锁的话，GPU显卡会被挂，效率就低了；

Vsync：从左到右水平扫描，从上到下垂直扫描，垂直扫描完成则整个屏幕刷新完成，这便是告诉外界可以绘制下一帧的时机；在这里VSync给出信号，通知GPU给FrameBuffer传数据，完成后屏幕便可以刷新。

VSync强制帧率和显示器刷新频率同步。

如果当前帧没绘制完，即使下一帧准备好了，也禁止使用下一帧，直到显示器绘制完当前帧，等下次刷新的时候，才会用下一帧。如：如果显示器的刷新频率是60HZ显示器，开了垂直同步后，显示帧率就会被锁60，即使显卡输出高，也没用。

双缓冲进阶：三缓冲

双缓冲Surface只会提供两个Buffer，一个Buffer被DisPlay占用（SurfaceFlinger用完后不会释放当前的Buffer，只会释放旧的Buffer,直观的想一下，如果新Buffer生成受阻，那么肯定要保留一个备份给SF用，才能不阻碍合成显示，就必定要一直占用一个Buffer，新的Buffer来了才释放老的），另一个被GPU处理占用，所以，CPU就无法获取到Buffer处理当前UI，在Jank的阶段空空等待。一般出现这种场景都是连续的：比如复杂视觉效果每一帧可能需要20ms（CPU 8ms +GPU 12ms），GPU可能会一直超负荷，CPU跟GPU一直抢Buffer，这样带来的问题就是滚雪球似的掉帧，一直浪费，完全没有利用CPU与GPU并行处理的效率，成了串行处理;

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

如上图所示，虽然即使每帧需要20ms（CPU 8ms +GPU 12ms），但是由于多加了一个Buffer，实现了CPU跟GPU并行，便可以做到了只在开始掉一帧，后续却不掉帧，双缓冲充分利用16ms做到低延时，三缓冲保障了其稳定性，为什么4缓冲没必要呢？因为三个既可保证并行，四个徒增资源浪费。

双缓冲保证低延时，三缓冲保证稳定性，双缓冲不在16ms中间开始，有足够时间绘制 三缓冲增加其韧性。

总结

屏幕刷新的三个步骤：
1，CPU计算屏幕数据，计算好之后交给GPU；
2，GPU对屏幕数据进行渲染，渲染好之后放到buffer里面存起来；
3，display负责把buffer里的数据呈现到屏幕上。

其实也就是CPU/GPU准备好数据，存入buffer，然后display每隔一段时间从buffer里面取出数据，然后显示出来；display读取的频率是固定的，比如每16ms读取一次，但是CPU/GPU写数据是完全没规律的。

对于Android来说，CPU计算屏幕数据指的也就是View树的绘制过程，也就是Activity对于的视图树从根布局DecorView开始层层遍历每个View，分别执行测量，布局，绘制三个操作的过程；

Android每隔16ms刷新一次屏幕其实就是：底层以固定的频率，如16ms将buffer里面的数据显示出来；以固定的频率来切换每一帧的画面。

每一帧的画面是App绘制视图树（View树计算得来的），这个工作交给CPU处理，取决于我们写的代码：布局复不复杂，层次深不深，同一帧内刷新的View数量多不多。

CPU绘制视图树来计算下一帧画面数据的工作是在屏幕刷新新信号来的时候开始的，当这个工作处理完毕之后，也就是下一帧的画面数据已经计算完毕，不会马上显示到屏幕上，而是等待下一个屏幕刷新信号来的时候再交由底层将计算完毕的屏幕显示出来；

当我们的App界面不需要刷新的时候（用户无操作，界面无动画），app就接收不到屏幕刷新信号，所以就不会让CPU再去绘制视图树计算画面数据工作，但是底层依然会以16.6ms切换下一帧的画面，只是这个下一帧的画面一直是相同的内容。

消息队列的同步障碍

作用
提高异步消息优先级，让消息队列优先取出UI刷新的异步消息交给主线程的Handler执行，提高UI流畅度