在整个Android视图绘制渲染流程中，Vsync信号都扮演着非常重要的作用，那么本篇文章就简单捋一下Vsync信号处理流程。在此之前先来回顾一下SurfaceFlinger的启动流程。
一、SurfaceFlinger的启动流程：
SurfaceFlinger自身拥有独立进程，由init进程启动。对应如下：
frameworks/native/services/surfaceflinger/surfaceflinger.rc
service surfaceflinger /system/bin/surfaceflinger
class core animation
user system
group graphics drmrpc readproc
onrestart restart zygote //挂掉后会重启Zygote
writepid /dev/stune/foreground/tasks
…
然后执行main_surfaceflinger对应main函数
frameworks/native/services/surfaceflinger/main_surfaceflinger.cpp
72int main(int, char**) {
...
// 限制binder线程池中线程数最多不超过4，加上主线程一共5个。
ProcessState::self()->setThreadPoolMaxThreadCount(4);
// 启动线程池
sp<ProcessState> ps(ProcessState::self());
ps->startThreadPool();
// 创建SurfaceFlinger, 执行SF::onFirstRef 最终调用MessageQueue.cpp ::init()方法创建Handler和Looper
sp<SurfaceFlinger> flinger = DisplayUtils::getInstance()->getSFInstance();
...
// 客户端连接前的一系列初始化 包括,初始化DispSyncSource 以及EventThread.其中EventThread有两个：mEventThread对应app , mSFEventThread对应SurfaceFlinger.并初始化显示设备。
flinger->init();
...
// surfaceFlinger执行主线程run方法，waitForEvent等待消息，接受invalidate消息并开始对应工作流。
flinger->run();
return 0;
}
事实上到这里，从主线上看SurfaceFlinger进程就已经启动了。
二、SurfaceFlinger处理Vsync信号：
Vsync信号的产生有两种来源，一种是硬件，一种是软件模拟，因为目前基本都是硬件产生的。硬件源就是HWComposer，它属于HAL,硬件抽象层的类，主要就是把硬件Vsync信号传递到上层来。
Vsync分发流程(android m的代码流程，Android p上对比了下 大流程是基本一致的，局部重构不影响大局)：
Vsync信号主要作用：同步应用层的视图绘制任务 和 Native层视图合成任务。下面通过一幅图来简单描述下整个过程：
Vsync产生：HWComposer作为硬件vsync信号。
Vsync处理：周期性唤醒DipsSyncThread产生虚拟化Vsync信号。
Vsync注册与回调：EventThread负责注册app和surfaceFinger的vsync请求和分发DipsSyncThread产生的虚拟化vsync信号到app和SurfaceFlinger。
总结一个vsync信号原则就是app和SurfaceFlinger按需请求，按请求分发。
三、app和SurfaceFlinger的vsync请求和接收过程
app的注册和回调都是通过Choreographer，它主要负责input 、animation和traversals.
App端
- 请求vsync-app:
Choreographer postCallback 发起vsync请求，最终调用FrameDisplayEventReceiver#scheduleVsync，然后进入native层，执行DisplayEventReceiver::requestNextVsync()，最终通过一个BpDisplayEventConnection来发起requestNextVsync操作。
这个过简单理解为客户端和底层建立了一个connection连接，通过这个connection向EventThread注册一个callback.
- 接收vsync-app:
DipsSyncThread周期性转发vsync给EventThread上注册的callback，经过层层回调，app端最终通过FrameDisplayEventReceiver#onVsync来接收回调，但并不是立即执行，而是通过Handler.sendMessageAtTime加入消息池等待调度。调度到了执行其run方法，走doFrame回调流程。
SurfaceFlinger
- 请求vsync-sf:
触发请求vsync位置在SurfaceFlinger.cpp中的两个方法：
//事务变化(如增加window window大小变化等)
void SurfaceFlinger::signalTransaction() {
mEventQueue.invalidate();
}
// layer发生变化,主要发生在queuebuffer的时候
void SurfaceFlinger::signalLayerUpdate() {
mEventQueue.invalidate();
}
另外还有个refresh方法，表示需要刷新屏幕 ,一般为处理完事务发现需要重新绘制的时候触发。
void SurfaceFlinger::signalRefresh() {
mEventQueue.refresh();
}
而MessageQueue执行invalidate最终还是建立connection连接向EventThread注册一个callback。
void MessageQueue::invalidate() {
mEvents->requestNextVsync();
}
触发点比较分散，但是总结一点就是：页面变化引起重绘的地方就会触发vsync请求。
- 接收vsync-sf:
EventThread传递Invalidate消息给SurfaceFlinger主线程run方法waitForEvent来执行。
Android系统Vsync信号生成、分发包括端的注册和接收整个过程还是非常复杂的，本篇文章并没有对整个细节进行详细分析，只是捋了下主要矛盾，对于整个Vsync信号处理流程有了一个宏观的了解。
参考：
https://www.cnblogs.com/hushpa/p/6579570.html
https://blog.csdn.net/a372048518/article/details/77871474
https://www.cnblogs.com/liusiluandzhangkun/p/9196187.html
https://blog.csdn.net/u012439416/article/details/79735081
