一、手機界面UI渲染顯示流程 二、16ms原則 三、造成卡頓的原因 四、過度繪製介紹、檢測工具、如何避免造成過度繪製造成的卡頓 ...
文章內容概要
一、手機界面UI渲染顯示流程
二、16ms原則
三、造成卡頓的原因
四、過度繪製介紹、檢測工具、如何避免造成過度繪製造成的卡頓
一.手機界面UI渲染顯示流程
大家都知道CPU（中央處理器）主要負責數學和邏輯運算，在很早前，CPU還負責圖像的顯示操作，但是這樣會大大的降低CPU的運算性能，所以GPU應運而生，GPU主要負責圖像的渲染與顯示，至此，CPU只需要給GPU發出指令，GPU再將我們寫好的頁面柵格化渲染顯示出來，以一個button為例!
<Button>屬性設置【Width = “100dp”；Height = “100dp”】-->通過LayoutInflater將xml映射成對象載入到記憶體-->檢測<Button>包含的屬性信息-->CPU經過計算-->將<Button>處理為多維向量圖形→CPU將圖形交給GPU→GPU進行圖形繪製（柵格化：將圖片等矢量資源,轉化為一格格像素點的像素圖,顯示到屏幕上）（哪個位置是什麼顏色的像素點，最終將圖形鋪滿。註：手機屏幕由無數個像素點堆積而成）。
總結來說就是CPU將UI對象計算成成多維圖形（多邊形、紋理），再通過OPENGL進行處理，處理完之後再交給GPU進行柵格化渲染並交給顯示器進行顯示。
二.16ms原則
由於人眼的特殊構造，對於60fps以下的幀率畫面，會給人一種卡頓的現象，所以就出現了16ms原則（1000ms/60fps = 16ms），即要保證頁面16ms刷新一次。
Android系統每隔16ms發出vsync信號，觸發對UI進行渲染，1s內大約刷新屏幕60次，顯示60幀的數據。
fps：畫面每秒鐘傳輸的幀率，幀率越高，畫面越流程，反之越卡頓
三.造成卡頓的原因
上面我們講到了16ms原則，那麼16ms原則對我們的UI產生了什麼樣的影響呢？
因為16ms原則，我們顯示器將頁面顯示出來分兩種情況：
1.上述步驟在16ms內完成，true→顯示器直接顯示。
2.上述步驟在16ms內沒有完成（可能由於CPU計算的時間過長或者由於GPU的渲染時間過長，最終導致整個流程下來超過了16ms），false-->垂直同步等待下一幀完成。
解釋一下垂直同步機制：比如說第一幀在16ms內渲染完成，並且顯示出來了，第二幀在上述的處理流程中超過了16ms，在16ms內沒有完成，那麼，屏幕就不會顯示第二幀的數據，依舊只顯示第一幀的數據，接下來處理第三幀，第三幀的數據在16ms內處理完了上述的流程，那麼結果就是屏幕會將第二幀的數據和第三幀的數據一起顯示出來（如果在某一處出現了丟幀的情況，大概率會影響到後面的繪製也會出現丟幀的情況），如果計算器cpu的計算能力和gpu的渲染能力很差，就會出現我們說的UI卡頓的現象。（用LOL舉一個例子，比如我們1-10幀都沒有在16ms內完成（打團中，UI過於複雜），第11幀在16ms內完成（打完團，回家泡泉水），這時候就會把1-11幀的數據都顯示出來，這時候給人的感覺就是花里胡哨的閃現出一堆技能）
看了上面的解釋，是不是有一種明朗的感覺了，總的來說就是幀率過低，垂直同步機制的限制下，我們前面幾幀的畫面渲染不出來，直到某一幀我們的幀率正常了，這時候就會把前面的幾幀一起渲染出來，這樣就造成了我們所說的視覺上卡頓的現象了。
四.過度繪製介紹、檢測工具、如何避免造成過度繪製造成的卡頓
既然我們知道了造成卡頓的原因了，那麼，我們應該去如何檢測和避免呢?這裡就要介紹一下過度繪製了！
1.什麼是過度繪製
前面我們說到了手機屏幕是由無數個像素點堆積而成的，一個像素點被我們重覆多次的渲染，就是過度繪製
2.過度繪製檢測工具
開發者選項-->調試gpu過度繪製-->顯示過度繪製區域
藍色 – 1次過度繪製– 這部分的像素點只在屏幕上繪製了兩次。
綠色 – 2次過度繪製 – 這部分的像素點只在屏幕上繪製了三次。
粉色 – 3次過度繪製 – 這部分的像素點只在屏幕上繪製了四次。
紅色 – 4次過度繪製 – 這部分的像素點只在屏幕上繪製了五次。 我們的目標是儘量減少紅色，看到更多的藍色！！！ 以輕易貸為例：
3.如何避免過度繪製
1)避免UI層級嵌套的過深
2)減少不必要的背景設置（根節點背景是否可以不要、系統主題背景是否可以不要等等）
3)使用merge標簽減少佈局嵌套層次
4)使用ConstraintLayout替代常見嵌套佈局，減少佈局層次
5)在自定義view的時候，使用Canvas的clipRect和clipPath方法限制View的繪製區域（覆蓋區域不需要繪製）
