VSync的虛擬化

由上面的介紹可以知道，VSync其實(shí)起源于顯示屏，但是想想如果每個(gè)App和SurfaceFlinger都去從硬件驅(qū)動(dòng)中直接監(jiān)聽VSync，那未免有點(diǎn)太復(fù)雜了，而且耦合性太高，不行。那怎么辦呢？

因此，最好是有一個(gè)模塊去專門跟驅(qū)動(dòng)溝通，再由它將VSync信號(hào)廣播給大家，就像一個(gè)hub一樣。但是VSync頻率這么高，每次從kernel到userspace的消耗也不少，而且VSync是周期性的，很容易猜，所以沒(méi)必要一直從kernel監(jiān)聽，但是系統(tǒng)是一直需要VSync來(lái)控制繪制合成的，所以有必要搞一個(gè)虛擬的VSync來(lái)模擬硬件VSync了。大概架構(gòu)如下圖：

其中SurfaceFlinger中的DisplayVSync（Android S后改名為VsyncController）就是虛擬的VSync源，其需要兩個(gè)參數(shù)來(lái)保證與硬件VSync的同步性，第一是參考點(diǎn)，第二就是周期。這些都可以開啟硬件VSync同步解決。

VSync的同步

VSync虛擬化的實(shí)質(zhì)就是在軟件層面模擬硬件VSync，既然是軟件模擬，那么就會(huì)存在誤差，如果誤差比較大，那么就需要開啟硬件VSync同步來(lái)進(jìn)行校準(zhǔn)。那么就存在兩個(gè)問(wèn)題，怎么發(fā)現(xiàn)自己誤差比較大？以及怎么來(lái)同步？

首先是如何發(fā)現(xiàn)誤差比較大？答案是通過(guò)fence機(jī)制。SurfaceFlinger在每一幀交給HWC的時(shí)候，同時(shí)都會(huì)從HWC那里得到此幀的PresentFence，它是在此幀開始刷新至屏幕的時(shí)候signal的。那驅(qū)動(dòng)什么時(shí)候開始刷新一幀至屏幕呢，答案是屏幕VSync來(lái)的時(shí)候。所以這下就能串起來(lái)了。根據(jù)PresentFence的signal時(shí)間就可以知道真實(shí)的VSync時(shí)間，那么之后的事情就簡(jiǎn)單了。

在HWComposer：：presentAndGetReleaseFences中獲取PresentFence，

獲取到fence之后就會(huì)對(duì)齊進(jìn)行監(jiān)測(cè)

一旦不準(zhǔn)就開硬件VSync來(lái)進(jìn)行校準(zhǔn)，通常情況下接收六次硬件VSync就可以完成校準(zhǔn)動(dòng)作。