说说Android的UI刷新机制
应用申请buffer --> 系统服务返回buffer --> 应用绘制后提交buffer --> 系统服务将这个buffer写到屏幕的缓冲区 --> 屏幕会以一定的帧率刷新，刷新时读取这个缓冲区的图像数据，显示出来。如果这个缓冲区没有新的数据的话，就一直用老的数据。
如果屏幕只有一个缓冲区的话，屏幕会显示一部分第一帧的画面，一部分第二帧的画面。
交换缓冲区
vsync信号是屏幕控制，绘制是一样控制
第二帧并没有耗时操作，只是开始绘制太晚了，
vsync信号来时，一方面屏幕读取缓冲区数刷新界面，一方面一样开始绘制下一帧图像数据
Choreographer作用：向Choreographer发送一个消息，这个消息会在下一个vsync信号来时触发，即真正的重绘。所以UI的绘制节奏完全由Choreographer控制
requestLayout()： 主要是用来发起UI重绘
SyncBarrier：屏障
postSyncbarrier(); 将屏幕插入消息队列后，屏障后面的普通消息就不能处理了，等到屏障移除了才能被处理，但是屏障对异步消息是没有影响的(紧急消息，需要马上处理)
mChoreographer.postCallback: 往Choreographer丢了一个runnable就是异步消息，等下一个vsync信号来时会执行这个runnable
mChoreographer是ViewRootImpl一起创建的，
在不同线程调用Choreographer.getInstance()：返回不同的Choreographer对象
mTraversalScheduled确保一个vsync信号周期内只有一次requestLayout有效
下图是Choreographer类里
mCallbackQueues[callbackType].addCallbackLocked(dueTime, ...): 按照callbackType和dueTime的紧急程度，将callback插入单链表里
isRunningOnLooperThreadLocked == true：当前线程就是Choreographer的工作线程
sendMessageAtFrontOfQueue: 将消息插入队列最前面，告诉SurfaceFlinger在下一个Vsync信号来时要第一时间通知我们。
scheduleVsyncLocked：告诉SurfaceFlinger，我们要关注vsync信号
下一个vsync信号来时SurfaceFlinger会回调FrameDisplayEventReceiver. onVsync方法
timestampNanos：vsync信号时间戳
mHandler.sendMessageAtTime（msg, timestampNanos / TimeUtils.NANO_PER_MS）: 发送一个消息到Choreographer的工作线程, 并且按照timestampNanos时间戳的顺序处理消息
消息时间到后会调用run()方法
jitterNanos >= mFrameIntervalNanos: 绘制时间超过一个周期
view请求requestLayout --> 往choreographer的队列里发送一个类型为CALLBACK_TRAVERSAL的消息 --> requestNextVsync想SurfaceFlinger请求下一个VSync信号 --> surfaceFlinger 在下一个信号来时postSyncEvent 告诉choreographer --> choreographer处理CALLBACK_TRAVERSAL消息执行performTraversal
1. 丢帧一般是什么原因引起的？
一般是主线程有耗时操作，耽误了view的绘制
2. Android刷新频率60帧/秒，每隔16ms调onDraw绘制一次？
刷新频率其实是VSync信号发生的频率，但不是每次VSync信号都会去绘制，需要应用端主动发起重绘，这样才会向surfaceFlinger
请求接收vysnc信号，等下次vysnc信号来时才会去执行onDraw。
3. onDraw完之后屏幕会马上刷新吗？
会等到下次vysnc信号来时才会刷新
4. 如果界面没有重绘，还会每隔16ms刷新屏幕吗？
没有重绘，应用不会收到vysnc信号，屏幕还是会以60帧/秒的频率刷新，只不过一直用的是旧数据。
5. 如果在屏幕快要刷新的时候才去绘制会丢帧吗？
代码里发起的view重绘不会马上执行，的等到下次vysnc信号来时才开始重绘，什么时候发起绘制操作都没有关系。
