vsync 信号生成源码分析

vsync 信号在 SurfaceFlinger 中生成，并且有硬件、软件两种生成方式

仅通过这种高度总结的描述，我们能得到多少信息呢？具体是如何生成？是优先选硬件生成还是软件生成还是同时存在？

下面就通过源码来一探究竟，既然在 SurfaceFlinger 中生成，那先来看 SurfaceFlinger 的 init 方法：

HWComposer 是 vsync 信号实际生成的类，SurfaceFlinger 通过 setEventHandler 向 HWComposer 注册了一个回调，使 SurfaceFlinger 能够接受由 HWComposer 生成的 vsync 信号，EventHandler 中的回调方法如下：

下面来看实际生成 vsync 的 HWComposer，其构造方法关键代码如下：

逻辑十分简单，首先去加载硬件，优先使用硬件生成方式，如果硬件不支持，则用软件模拟。

硬件源生成回调 hook_vsync 方法如下：

至此 HWComposer 中的 vsync 硬件生成方式流程完毕，最后通过 mEventHandler 回调交由 SurfaceFlinger 处理。

再来看软件模拟生成方式，其通过VSyncThread类实现，VSyncThread 继承了 Thread 类，自然也继承了 Thread 类的threadLoop方法。

如果 threadLoop 方法返回 true，那当工作线程启动后，基类 Thread 会循环的调用 threadLoop 方法。

而软件模拟生成的 vsync 信号就是在 threadLoop 方法中生成的，代码如下：

如何在指定的时间点产生信号呢？如代码所示，在每次循环时采用休眠的方式主动等待至 vsync 时间点。

第一次执行时， next_vsync、mNextFakeVSync 都为 0，所以 sleep < 0 进而会重新计算 next_vsync 为 now + period，也就是基于当前时间再等一个 vsync 周期。

后续每次循环也会重新修正 vsync 信号的时间，避免回调 onVSyncReceived 方法或其他操作耗时导致 vsync 信号时间变得"越来越晚"。

最后总结一下：vsync 信号在 SurfaceFlinger 进程的 HWComposer 类中生成，优先使用硬件生成方式，如果硬件不支持则使用软件方式模拟生成。不管是硬件生成还是软件生成，最后统一通过相同的回调交由 SurfaceFlinger 处理。