Andriod中Vsync的背景

Android的顯示系統(tǒng)一直使用雙緩沖和VSync來防止屏幕畫面發(fā)生撕裂現(xiàn)象，這也是其他系統(tǒng)的常規(guī)操作。Android的不同之處是將VSync運用到繪制系統(tǒng)中，作為黃油計劃（Project Butter）的一部分，用以提升系統(tǒng)的流暢度。

VSync：

Android中VSync的作用是統(tǒng)一系統(tǒng)繪制與顯示節(jié)奏（Apps和SurfaceFlinger），大家各司其職，確保在VSync來的時候干活，這樣系統(tǒng)理論上就絲滑了。

如下圖，在沒有VSync的情況下，系統(tǒng)渲染的節(jié)奏與屏幕刷新的節(jié)奏不一致，如果某一幀系統(tǒng)渲染的比較晚，那么就會出現(xiàn)屏幕兩次刷新都顯示同一份內(nèi)容的情況，也就是Jank（掉幀）。

有了VSync的話，系統(tǒng)會在VSync到來時進行繪制，與屏幕的刷新節(jié)奏保持一致，這樣就大大降低了jank的概率。

那么問題來了，怎么讓Apps根據(jù)VSync的節(jié)奏來進行繪制呢？App依賴系統(tǒng)的繪制系統(tǒng)，所以必須讓繪制系統(tǒng)聽命令才行，這就是Choreographer出現(xiàn)的原因。

Choreographer：

Choreographer（編舞者）的作用在源碼的注釋中已經(jīng)寫得很明白，是用來接收定時脈沖信號來控制繪制的模塊。也就是說，有了Choreographer，apps就能夠根據(jù)Vsync信號來進行周期性的繪制工作。

以上兩者配合就基本上完成了Android中VSync的改造，但是還有一個造成Jank的原因也是不容忽視的，這就是雙buffer機制帶來的jank風險。

Triple Buffer：

如下圖，理想情況下的雙buffer是沒有問題的，這個理想狀態(tài)是指繪制工作（可以粗略地理解為一幀CPU和GPU執(zhí)行的總耗時）在一個VSync周期內(nèi)完成，這樣的情況下，不會發(fā)生jank。

遺憾的是，事情的發(fā)展不會總是按我們的預期來進行的，如果繪制時長超過了一個VSync周期，那么就必然會發(fā)生jank。如下圖所示，有兩幀的繪制超過了一個VSync周期，那么就會發(fā)生兩次Jank。

三Buffer機制實際上就是在上述backbuffer和frontbuffer的基礎上，再添加一塊buffer進行輪轉(zhuǎn)。在這樣的情況下，同樣假設有兩幀的繪制就是大于一個VSync周期，那么只會造成一次Jank。

三buffer機制雖然能降低jank的概率，但是也會帶來Touch響應慢和內(nèi)存消耗高的負面影響，只不過相對于它帶來的效果，這些負面影響被忽略了。