VSync 虛擬化

為了提高UI的響應(yīng)速度， Android重新設(shè)計了VSync的相應(yīng)邏輯。

• 先來看下VSync的響應(yīng)：
  VSync到來， SF和App同時接收到VSync， 這個時候SF肯定需要等待App端把UI繪制完畢， 然后才能進(jìn)行混合輸出. 這個時候SF先休眠然后再喚醒，這里肯定涉及到CPU的上下文調(diào)度， 需要消耗一定的時間。
• 做一個假設(shè)：
  VSync到來， App先接收到VSync， 然后SF等待一段時間再接收到這個VSync, 如果App繪制UI比較快， 則等到SF喚醒的時候， 無需等待就可以繼續(xù)工作了， 這里就避免了一次CPU的調(diào)度。

• 總結(jié)

  
  
  display.png

Android 就是考慮到上面的這個假設(shè)， 設(shè)計了虛擬化的VSync.

Sync.png

SF中傳遞線程關(guān)聯(lián)方式

通過上面介紹了解到， SF 收到 HWC 傳遞過來的VSync， 先傳遞到 DispSyncThread（VSync分發(fā)線程）， 然后分發(fā)給 EventThread （VSync處理線程）。

Vsync_process.png

看圖中粉紅色線部分：
1： EventThread （VSync處理線程）啟動之后， 進(jìn)入 threadLoop 循環(huán)， 調(diào)用 waitForEvent方法， 激活整個傳遞流程。
2： waitForEvent 調(diào)用 enableVSyncLocked。
2-1：enableVSyncLocked 第一步把 EventThread 自己設(shè)置為 DispSyncSource 的回調(diào)。
2-2：DispSyncSource通過setVSyncEnabled把自己添加到 DispSync 的回調(diào) mEventListeners中。

PS：DispSync 和 DispSyncSource 的初始化都在SF的init中。 這里都比較簡單, 畫出來圖就太多線了。

SF中VSync的傳遞

VsyncProcess.png

圖中綠線部分， 接著上節(jié)傳遞的位置 onVSyncReceived。

Vsync_thread.png

整個流程跟著箭頭走比較清晰， 其中涉及到三次跨線程交互。

前兩次都是通過 Condition 進(jìn)行喚醒的， 最后一次通過的是本地套接字喚醒的。