07.显示系统：第005课_Vsync机制：第002节_Vsync框架

在上一节中，讲解了黄油计划，在android系统中，通过黄油计划的三个方法改进显示性能，增强人机交互的流畅程度，其中最重要的就是引入了Vsync机制，所有的部件都在Vsync到来的时候开始工作。下面开始讲解Vsync的框架。

首先我们自己想象一下Vsync的框架。

1.是谁产生Vsync
2.谁处理Vsync：某一个线程
3.Vsync会被拆分成两个信号，一个给应用程序使用（Vsync-APP），一个给SurfaceFlinger使用（Vsync-SF）。是谁将Vsync虚拟化。
4.Vsync-APP与Vsync-SF怎么起作用。

下面我们猜想的框架，必须能回到以上问题。为了方便理解，下面是一个框图，我们围绕着该框图进行讲解：

一般来说，我们可以是使用硬件产生Vsync信号，硬件产生信号，必须要对应的应用程序进行处理，如一个线程接收Vsync信号。如果有的硬件不能产生Vsync信号，我们可以使用软件（创建一个线程：休眠16毫秒，发出信号），让其产生Vsync。

其上的处理Vsync信号的线程为DispSyncThread，发出信号的线程为VsyncThread，无论是硬件还是软件产生Vsync信号，其最终都会唤醒DispSyncThread线程。

DispSyncThread线程有两个方面，1.休眠offsel1，唤醒等待Vsync-app的线程（EventThreadForVsync-APP）。2.休眠offsel2，唤醒等待Vsync-SF的线程（EventThreadForSF）。

Vsync是为了更多app去构造他们的新界面，所以对应着很多APP，如APP1,APP2等等，他们之间与Vsync-APP边的EventThread线程肯定存在联系的，他们之间的联系称为cinnection，EventThread一般处于休眠状态，收到信号之后，唤醒APP1，或者APP2。Vsync-SF边的EventThread线程，也存在conect。但是他只存在一个connection，其连接的为SurfaceFlinger线程。当Vsync-SF信号到来时，Vsync-SF边的EventThread线程被唤醒。

如果Vsync-APP信号来了，会唤醒所有的APP程序吗？这样太耗费资源了，当然是唤醒需要更新界面的APP，他怎么知道哪个应用程序APP需要更新界面了？当然只有应用程序自己才知道是否需要更新界面。

APP需要更新界面的时候，向EventThread提出请求。通过设置connection中的conut，当conut大于0的时候，代表需要接收Vsync-APP的信号。当所有的应用程序都不需要更新界面的时候，对应的EventThread会一直休眠，这个时候就没有必要让DispSyncThread给他发送Vsync-APP信号了。

下面我们进行一些总结
1.APP有更新界面的需要时，他需要得到Vsync-APP。
2.于是向EventThread（APP）提出请求。
3.EventThread（APP）在向DispSyncThread提出请求。
4.DispSyncThread收到Vsync信号之后，休眠第一段时间（offsel2），发送Vsync-APP信号。

应用程序在接收到Vsync-APP信号的时候，就会构造新界面，这些新构造好的界面，最终要发送给SurfaceFlinger。我们假设，仍然是APP1,APP2。他们根据Vsync-APP的节奏，构造好APP的新界面之后，会通过queueBuffer把数据发送给SurfaceFlinger，然后SurfaceFlinger就会开始合成这些界面数据，此时他就需要一个Vsync-SF信号，其connection中的conut就会大于或者等于0，然后按需进行：
1.APP把新数据发送给SurfaceFlinger
2.SurfaceFlinger有Vsync-SF需求，向EventThread（sf）发出请求，
3.EventThread（sf）再向DispSyncThread发出请求。
4.DispSyncThread收到Vsync信号，眠第一段时间（offsel2），发送EventThread（sf）信号。

现在我们回答最开始问出的四个问题;

下面是一个详细的过程，有兴趣的同学可以进行详细的分析：