VSync传递之 SF

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 进行唤醒的， 最后一次通过的是本地套接字唤醒的。