App與SurfaceFlinger是不同的進程，它們之間傳遞VSync的話涉及到進程間通信，而且VSync頻率很高，App很多，所以VSync的分發(fā)效率要很高才行。Linux進程間通信方式總共就那么幾種，Android選擇了Domain Socket，應(yīng)該是因為其高效、簡單、且有序吧，并將其封裝成了更易用的BitTube。

VSync-app/sf

Android繪制、顯示各個環(huán)節(jié)均是由VSync驅(qū)動，具體來說就是App的每一幀的繪制是從收到VSync信號（VSync-app）開始的，SurfaceFlinger合成當前圖層也是從收到VSync信號（VSync-sf）開始的。為了避免浪費，VSync的分發(fā)是按需的，即只有用戶需要（requestNextVsync）的時候，DisplayVSync才會給它發(fā)送VSync。

Vsync相關(guān)類簡介

首先來介紹一些vsync相關(guān)的類，基本上所有vsync相關(guān)方法，都是實現(xiàn)在這三個類當中的（以下代碼均為Anrdoid T版本源碼）。

VsyncTracker：其實際上是創(chuàng)建了一個VSyncPredictor對象，這個對象的作用是基于之前的VSync信號時間戳來預(yù)測未來VSync時間戳。也就是基于HWVsync來訓(xùn)練Vsync模型。從而能夠在HWVsync關(guān)閉的情況下依然能夠預(yù)測未來的VSync時間。

VsyncDispatcher：顧名思義，這個類是用來分發(fā)Vsync信號的。實際上最終創(chuàng)建了一個VSyncDispatchTimerQueue對象，負責(zé)分發(fā)vsync callback事件，需要接收Vsync事件的模塊可以通過registerCallback向其中注冊回調(diào)，當有Vsync事件發(fā)生時就會遍歷已注冊的回調(diào)分發(fā)Vsync。

VSyncController：最終方法的實現(xiàn)是在一個VSyncReactor對象中，從代碼中看，這個對象的主要作用是負責(zé)傳遞HWVsync，presentFence信號。

sf申請vsync

當sf需要請求刷新時，會調(diào)用MessageQueue中的scheduleFrame函數(shù)

進而直接調(diào)用到VSyncCallbackRegistration中的schedule函數(shù)，進一步再到VSyncDispatchTimerQueue中的schedule函數(shù)。

這其中rearmTimerSkippingUpdateFor是一個比較關(guān)鍵的函數(shù)，這個函數(shù)會拿到下次觸發(fā)vsync的時間戳，并通過setTimer函數(shù)向定時器設(shè)置這個時間戳，等到定時器被喚醒時，觸發(fā)callback以發(fā)送vsync。

下面我們來看callback是怎么被層層觸發(fā)的。

當定時器到來時，首先回調(diào)的是VSyncDispatchTimerQueue中的timerCallback函數(shù)

它持有的結(jié)構(gòu)體Invocation中持有一個VSyncDispatchTimerQueueEntry對象，進一步追下去，可以知道這個mCallback最終調(diào)到的是MessageQueue中的VsyncCallback函數(shù)。

最后的這個紅框的部分，就是我們通常在trace里看到的vsync-sf跳變的地方啦！

app申請vsync

相比于sf的申請，app的申請就顯得要復(fù)雜一些。app通常是通過調(diào)用requestNextVsync這個binder接口來進行vsync的申請。

這個接口會調(diào)用到eventthread中的requestNextVsync函數(shù)，此函數(shù)會通過mCondition發(fā)送廣播。

當threadMain監(jiān)聽到廣播后，便會繼續(xù)執(zhí)行循環(huán)。

eventThread會執(zhí)行什么呢，關(guān)鍵性的函數(shù)就是dispSyncSource中的setVSyncEnabled函數(shù)，當傳入?yún)?shù)為true時，會調(diào)用到CallbackRepeater中的start函數(shù)。

繼續(xù)往下看，會調(diào)用到VSyncCallbackRegistration中的Schedule函數(shù)，進一步到VSyncDispatchTimerQueue中的schedule函數(shù)。

下面的流程和sf申請vsync基本就是大同小異了，它回調(diào)的地方是這里

調(diào)用CallbackRepeater中的callback；

最終調(diào)用到DispSyncSource中的onVsyncCallback，這也就是我們在trace中看到的vsync-app跳變的地方啦。

相比于vsync-sf，vsync-app還多了一個向申請方發(fā)送vsync的過程。繼續(xù)往下看，調(diào)用到了EventThread中的onVSyncEvent，其會把VsyncEvent保存到mPendingEvents中。

那么這些event在哪里分發(fā)呢？答案是還在threadMain中，這個dispatchEvent函數(shù)就是用來負責(zé)向每個consumer分發(fā)vsync的。

說到這里，大家肯定會有一個疑問，為什么vsync-app和vsync-sf都是由同一個定時器觸發(fā)的，但是最終回調(diào)的位置確不一樣呢？

答案是，這兩種vsync本身注冊回調(diào)的位置就不一樣。

vsync-sf是在messagequeue中注冊的

而vsync-app是在callbackRepeater中注冊的。

這也是google在Android T上才做出來的改動，究其原因，應(yīng)該是谷歌認為應(yīng)該簡化vsync-sf在內(nèi)部的傳遞流程，反正也是只給sf自己用的。