1.App请求绘制,会注册vsync信号监听,收到SF端vsync信号后会做doFrame刷新界面。
2.主线程+渲染线程= 一帧时间,一帧处理完以后才会请求下一帧。
3. DispSync 类表示了一个基于硬件 VSync 信号的同步模型,它会根据从 HWComposer 来的硬件 VSync 信号的采样来进行同步。其它两个 EventThread 分别用了两个不同的虚拟 VSync 信号源(用 DispSyncSource 表示,其中包含了与真实 VSync 信号的偏移),这两个 VSync 信号源就是被虚拟出来分别用于控制 App UI 和 SurfaceFlinger 渲染。
4.systrace里有两个HW_VSYNC,一个叫HW_VSYNC_ON_0,其实就是记录的0 display的硬件VSYNC打开或关闭事件。另外一个叫HW_VSYNC_0,记录的是0 display的硬件VSYNC事件。HW_VSYNC_ON代表是SF这边sw_vsync不准了(不准的原因是底层的presentfence不准了),需要通过hw_vsync来校准,HW_VSYNC 代表硬件的刷新率。
5.VSYNC-sf用于控制SF合成Layer的节奏,可以理解为sf对应的DispSyncSource发出的sync信号,再触发EventThread的回调并转换成事件写入写端,最后触发读端的回调MessageQueue::cb_eventReceiver(),SF开始合成显示图层。VSYNC-app用于控制APP绘制UI的节奏,APP中和VSYNC-app打交道的类为Choreographer,Choreographer的成员属性mDisplayEventReceiver:FrameDisplayEventReceiver用于接收SF端的VSYNC-app信号,通过native层的DisplayEventReceiver,创建并注册一个Connection到SF的sf-EventThread中,native层的DisplayEventDispatcher再将Connection的读端和自己通过addFd注册到mLooper中,后续VSYNC-app信号会触发DisplayEventDispatcher的handleEvent(),继而调用到FrameDisplayEventReceiver的onVsync()。
5.刷新一帧doFrame中的doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos); input事件在scheduleConsumeBatchedInput中处理。
6.Choreographer的跳帧信息Log.i(TAG, "Skipped " + skippedFrames + " frames! "+ "The application may be doing too much work on its main thread.");这里是收到SF的vsync开始计时和doFrame开始处理这个vsync的时间太长超过30ms就会打印,说明应用主线程比较忙。