VSync 虚拟化
为了提高UI的响应速度, Android重新设计了VSync的相应逻辑。
- 先来看下
VSync的响应:
VSync到来,SF和App同时接收到VSync, 这个时候SF肯定需要等待App端把UI绘制完毕, 然后才能进行混合输出. 这个时候SF先休眠然后再唤醒,这里肯定涉及到CPU的上下文调度, 需要消耗一定的时间。 - 做一个假设:
VSync到来,App先接收到VSync, 然后SF等待一段时间再接收到这个VSync, 如果App绘制UI比较快, 则等到SF唤醒的时候, 无需等待就可以继续工作了, 这里就避免了一次CPU的调度。 -
总结
display.png
Android 就是考虑到上面的这个假设, 设计了虚拟化的VSync.

Sync.png
DispSync接收到VSync之后, 先发给App然后过段时间再发给SF.
SF中传递线程关联方式
通过上面介绍了解到, SF 收到 HWC 传递过来的VSync, 先传递到 DispSyncThread(VSync分发线程), 然后分发给 EventThread (VSync处理线程)。

Vsync_process.png
看图中粉红色线部分:
1: EventThread (VSync处理线程)启动之后, 进入 threadLoop 循环, 调用 waitForEvent方法, 激活整个传递流程。
2: waitForEvent 调用 enableVSyncLocked。
2-1:enableVSyncLocked 第一步把 EventThread 自己设置为 DispSyncSource 的回调。
2-2:DispSyncSource通过setVSyncEnabled把自己添加到 DispSync 的回调 mEventListeners中。
PS:DispSync 和 DispSyncSource 的初始化都在SF的init中。 这里都比较简单, 画出来图就太多线了。
SF中VSync的传递

VsyncProcess.png
图中绿线部分, 接着上节传递的位置 onVSyncReceived。

Vsync_thread.png
整个流程跟着箭头走比较清晰, 其中涉及到三次跨线程交互。
前两次都是通过 Condition 进行唤醒的, 最后一次通过的是本地套接字唤醒的。
