Android Vsync原理簡析

螢屏渲染原理

"現代計算機之父"馮·諾依曼提出了計算機的體系結構: 計算機由運算器，存盤器，控制器，輸入設備和輸出設備構成，每部分各司其職，它們之間通過控制信號進行互動，計算機發展到現在，已經出現了各種mini的智能設備，比如手機，就是典型的微型計算機，其中控制器/存盤器/運算器是我們看不到的，但我們知道它是真實存在的，比如記憶體8G/12G；高通、麒麟等一些名詞，其中手機的螢屏扮演了一個極其特殊的角色，他可以觸摸、滑動，這證明了它是一個"輸入設備"，同時它又能呈現畫面，證明它又是一個"輸出設備"，所以對于手機來說，螢屏即是輸入又是輸出，接下來就來追蹤一下手機螢屏是怎么輸出的，

我們都知道，計算機是基于二進制資料流來進行作業的，而且又知道，計算機五大組成部分是各司其職的，其中螢屏就是專門來"渲染"影像的，既然要顯示影像，肯定要有顯示的資料，這些資料從哪來呢？答案就是cpu(這里為了方便，把cpu、gpu、sf等統一稱為cpu)，這些資料由cpu提供，cpu經過各種運算，將資料寫入一塊記憶體中，這塊記憶體叫做幀緩沖，我們可以將幀緩沖理解為一個M*N矩陣，資料從上到下一行一行保存，顯示幕在顯示的時候，從上到下逐行掃描，依次顯示在螢屏上，我們把這樣的一屏資料叫做一幀，當一幀資料渲染完后，就開始新一輪掃描，如果CPU正好(不正好后面再說)也把下一幀資料寫入幀緩沖，那么就會顯示下一幀畫面，如此回圈，我們就看到了不斷變化的畫面，也就是影像，這個程序很簡單，但是實作起來卻很難，具體有兩點:

• 1 螢屏需要在16.7毫秒內繪制完一幀，因為根據研究，16.7ms正符合人類能覺察到卡頓的分割點，如果低于16.7ms，則可能感覺卡頓，高于16.7ms則沒必要，
• 2 CPU需要在螢屏渲染完畢后，正好把下一幀資料寫入幀緩沖，如果早了，那么螢屏上就會繪制一半上一幀的資料，一半下一幀的資料，比如:繪制到第一幀的a行時，cpu把下一幀資料送進來了，螢屏會接著從a+1行接著繪制，這樣導致前a行是第一幀的資料，后面幾行是第二幀的資料，在我們看來就是兩張圖片撕開各取一部分拼起來，這叫做撕裂，如果晚了，那么螢屏會在下一次繼續繪制上一幀，導致畫面沒有變化，這樣就會出現畫面不變的情況，在我們看起來就是卡了，也叫做卡頓，所以，CPU和螢屏的這個互動時機很重要，

這就跟我們抄作文一樣，們從上到下，從左到右，一行一行的"挪移"到另一張紙上，當我們抄完一頁，就翻到下一頁繼續抄，聰明的人抄的時候會看看，不會抄名字、性別、父母資訊啥的，但是螢屏很傻，給什么抄什么，往死里抄，不帶思考的那種，甚至在抄第一頁的程序中，你給他偷偷翻個頁，他還接著往下抄，造成不連貫的后果，螢屏不管這個，都說了各司其職，它的"職"就是抄，至于抄的不對，就是因為你翻頁了，在計算機體系中，能翻頁的，就是cpu，那最終就會怪罪于cpu"控制不力"，所以螢屏和cpu的協調溝通就極其重要，

我們來看兩個概念:

• 螢屏重繪率(Hz): 螢屏在一秒內重繪的次數，Android手機一般都是60Hz，也就是一秒重繪60次，當然也有高刷的，但是60Hz足矣，
• 幀速率(FPS): cpu在一秒內合成的幀數，比如60FPS，就是60 frame per sconds，意思就是一秒合成60幀，

如上所述，當螢屏重繪率大于幀速率的時候，會發生卡頓；螢屏重繪率小于幀速率的時候，會發生撕裂，那么怎么解決這個問題呢，我們一個一個來解決，先來看撕裂，

解決撕裂問題(VSYNC)

我們知道，撕裂是因為: cpu太快 從而導致 螢屏還沒渲染完畢 就把正在渲染的資料 給覆寫掉了，那么我們可以限制cpu的速度嗎？當然可以，但是不劃算，因為這樣就等于把cpu的長處給扼殺了，所以我們只要讓cpu的資料不覆寫掉螢屏正在渲染的資料即可，也就是說，給cpu新來的資料提供一個存放點，而不是往幀緩沖里面寫，這個存放點叫做后緩沖(BackBuffer)，相應的，幀緩沖(FrameBuffer)也叫做前緩沖，這樣，cpu新來的資料就會放在后緩沖，而螢屏則繼續從前緩沖取資料來渲染，等到后緩沖資料寫入完了，前后緩沖的資料就會交換，螢屏此時讀取的資料就是后緩沖的資料，也就是下一幀的資料，回圈往復，我們就看到了畫面，但是！還是不行，舉個列子，如果cpu非常快，前緩沖資料還沒重繪完畢，后緩沖已經寫滿，此時，就會交換資料，又發生了撕裂！那么怎么辦呢？

從圖中可以看到: 沒有vsync的情況下，cpu在任意地方開始，隨心所欲!

我們追究原因: 核心點在與資料交換的時機由誰來控制，資料交換的發生點應該是在螢屏渲染完一幀后，而不是cpu寫入一幀資料后，所以，控制資料是否交換應該由螢屏來決定，但是！計算機五大組成部分各司其職，螢屏只是輸出設備和輸入設備(因為能觸屏)，他不是控制器，如何控制資料的交換呢？當然可以，答案就是:VSYNC，

VSYNC(vertical sync): 也就是垂直同步，當螢屏渲染完一幀資料后，即將開始渲染下一幀之前，發出的一個同步信號，

cpu只要監聽VSYNC信號，接收到信號后再開始交換后緩沖和前緩沖的資料，就等價于螢屏控制了資料交換，也就解決了撕裂問題，這很明顯是設計模式中的監聽器模式，

現在我們來捋一下流程:

• 1 螢屏正在從前緩沖讀取第一幀資料并渲染，此時cpu計算完第二幀資料，放在后緩沖，等待VSYNC信號，
• 2 螢屏將第一幀資料渲染完畢，發出VSYNC信號，cpu收到VSYNC信號，將后緩沖的第二幀資料復制到前緩沖，
• 3 同時螢屏繼續繪制第二幀資料，cpu開始計算下一幀資料，回圈往復，

從圖中可以看到，有了VSYNC，cpu總是在指定的地方開始，

有人會問: 說白了，真正解決問題的是VSYNC，而不是雙緩沖，那不要雙緩沖只要VSYNC不是也可以嗎？

好，我們假設只有VSYNC，現在假設螢屏正在渲染資料，而cpu在等VSYNC信號，螢屏將資料渲染完畢后，發送VSYNC信號，cpu收到信號后，就去計算資料，計算完后才會寫入幀緩沖，那么，在cpu計算資料這段時間內，螢屏干什么呢？嗯，它接著重繪幀緩沖的資料，反正cpu還沒有將新資料計算完畢刷入幀緩沖，所以還是上一幀的資料，這樣就會卡頓，說白了，有雙緩沖的情況下，cpu使用后緩沖計算資料，螢屏使用前緩沖渲染資料，兩者可以同時作業，你計算一個我渲染一個，典型的"生產者消費者模式"，只不過使用VSYNC信號來進行資料的交換；而沒有雙緩沖的情況下，兩者需要排隊使用幀緩沖，不能同時作業，就變成了我等著你計算，你計算完了等著我渲染，VSYNC此時的作用就是進行排隊，這樣會大大增加卡頓率，所以: VSYNC真正解決了撕裂問題，而雙緩沖優化了卡頓問題，

那么，怎么解決卡頓問題呢？答曰: 無法根本解決，只能優化!

優化卡頓問題(多緩沖)

我們知道，卡頓是因為幀速率<螢屏重繪率，這是不嚴謹的，準確的說應該是因為:幀速率<60fps，因為現在螢屏重繪率基本都是60hz的，所以幀速率只要取下限60fps即可，換句話說，1秒內需要計算60個幀，也就是16.7ms就能計算完一幀，如果計算不完，那么在一個vsync信號過來后，cpu還在計算，緩沖區的資料并沒有改變，就還是老資料，螢屏就又把老資料重繪一遍，就出現了卡頓，所以，cpu要盡可能在16.7ms內把所有資料計算完準備好，以等待vsync信號過來后直接交換資料，

我們又知道，雙緩沖只是優化了卡頓問題，并沒有根本解決卡頓問題，為何呢？我們先來大致說明一下Android的螢屏繪制流程:

• 1 任何一個View都是依附于window的
• 2 一個window對應一個surface
• 3 view的measure、layout、draw等均是計算資料，這些是cpu干的事
• 4 cpu把這些事干好后，在經過一系列計算將資料轉交給gpu
• 5 gpu將資料柵格化后，就交給SurfeceFlinger(以下簡稱SF)
• 6 SF將多個surfece資料合并處理后，就放入后緩沖區
• 7 螢屏以固定頻率從前緩沖區拿出資料渲染，渲染完畢后發送VSYNC，此時前后緩沖區資料交換，螢屏繪制下一幀

上述7步是建立在開啟硬體加速的情況下的，如果沒有硬體加速，就去掉gpu部分，就可以簡單理解為cpu直接將資料轉交給sf，我們簡單整理一下資料的傳遞流程:
cpu -> gpu -> display，而且我們看到，cpu和gpu是排隊作業的，它倆和螢屏是并行作業的，好，我們來看發生卡頓(jank)的場景:

我們可以將Display那一行看作是前緩沖，將GPU和CPU兩行疊加起來看作是后緩沖(因為它倆排隊使用)，將VSYNC線隔離開的豎行看作一個幀，

我們看到，在第一幀里面，GPU墨跡了半天沒搞完，以至于在第二幀里面，Display(螢屏)顯示的還是第一幀的A資料，此時就產生了Jank(卡頓)，并且在一個vsync信號過來后，cpu什么都沒做，因為gpu占著后緩沖(那個綠色的長B塊)，所以cpu只能再等下一個vsync，在下一個vsync里面，cpu終于拿到了后緩沖的使用權，但是cpu計算時間比較長，導致了gpu時間不夠用，資料又沒算完，再次發生了卡頓，可以說，這次卡頓直接受到了第一次卡頓的影響，試想: 如果在第一次卡頓的時候，cpu也能計算資料，那么，第二次卡頓可能就不存在了，因為cpu已經在第一次卡頓的時候把藍色的A給計算完了，第二次完全可以讓gpu獨自計算(綠色的A)，就不存在因為排隊導致的時間不夠用了，但是！cpu和gpu共用后緩沖，這就導致它們只能輪流使用后緩沖，怎么解決呢？再加一個后緩沖區，讓cpu、gpu各用一塊，我們來看引入三緩沖后的效果:

我們看到，在第一次jank內，cpu使用了第三塊緩沖區，自己計算了C幀的資料，假如此時沒有三緩沖，那么cpu就只能再繼續等下一個vsync信號，也就是在圖中藍色A塊的地方，才能開始計算C幀資料，就又引發下一次卡頓，我們看到，通過引入三緩沖，雖然不能避免卡頓問題，但是卻可以大幅優化卡頓問題，尤其是避免連續卡頓，但是，三緩沖也有缺點，就是耗資源，所以系統并非一直開啟三緩沖，要想真正解決問題，還需要在cpu層對資料盡量優化，從而減小cpu和gpu的計算量，比如:View盡量扁平化，少嵌套，少在UI執行緒做耗時操作等，

Tips:

• Android 3.0引入了硬體加速(GPU)，
• Android 4.0默認開啟了硬體加速，
• Android 4.1引入了黃油計劃(VSYNC)，上層開始接收VSYNC(Choreographer)，并且加入了三緩沖.
• VSYNC不僅控制了后緩沖和前緩沖的資料交換，還控制了cpu何時開始進行繪制計算，

在這里給大家分享一波我平時學習的資料，

專案地址：

Android學習肯定不是光看書就能學會的，具體還是要自己上手寫代碼，如果有一份視頻能讓你看到全程序就好了，
所以關于視頻我也整理了一部分：
視頻包含：

1、IPC機制相關面試題視頻決議
2、專案相關視頻決議
3、性能優化相關面試題視頻決議
4、JVM從入門到著迷
5、原始碼相關試題視頻決議
6、BAT面試總結分析

Android學習三要素可以大大加快你的學習之旅

• 腦圖
• 資料
• 視頻

現在還缺一個腦圖，關于Android 的學習必然是一個體系化的程序，下面我分享一下對標騰訊T7架構師的Android學習路線圖：

以上內容全部免費分享給大家，有需要的同學可以點擊：Github自行查看，也可以點擊鏈接Android開發交流，群內獲取，