佈局渲染流程

佈局渲染流程

1，以前一篇文章講解了CPU和GPU的工做原理，不懂的能夠去參考參考。

2，60fps刷新頻率的由來。

• 12fps：因爲人的眼睛，在每秒約10到12幀之上，人的眼睛看到的畫面的幀率認爲是連貫的。
• 24fps：有聲電影的拍攝及播放均爲24幀，對於通常人而言，能夠接受了。
• 30fps：早起的高動態的電子遊戲，幀率少於30幀，會顯得不連貫。那是由於沒有動態模糊，使流暢度下降。
• 60fps: 當人和手機交互時，如觸摸和反饋，在60幀如下，是人能夠感覺到變化的，60幀以上是感受不到變化的。
• 當畫面低於60幀時，會感受到畫面的卡頓或者遲滯現象。

android系統每隔16ms會發出vsync信號（1000ms/60=16.66ms），觸發對UI進行渲染，若是每次都成功，這樣就能達到流暢的畫面所須要的60幀。也就是意味着渲染的大部分操做都必須在16ms內完成。

3，卡頓原理分析

當這一幀畫面渲染時間超過16ms的時候，垂直同步機制會讓顯示器硬件等待GPU完成柵格化渲染操做。 這樣這一幀畫面就會多等待16ms，甚至更多時間，就會形成畫面停頓。 以下圖：

4,16ms時間在幹什麼

• 第一件事：將UI對象轉換爲一系列的多邊形對象和紋理。
• 第二件事：CPU傳遞處理數據到GPU。
• 因此咱們要儘可能的減小這兩件事的時間，也就是減小UI對象轉換和數據之間的傳遞。

5，如何減小這兩部分時間，以致於在16ms內完成。

• cpu減小xml轉換對象的時間。
• GPU減小重複繪製時間。

6，什麼是過分繪製。

GPU的繪製，就像刷牆同樣，一層一層的覆蓋，16ms繪製一次，這樣無用的層，在底部還在繪製，形成浪費。

7，GPU過分繪製的幾種狀況

• 1，在自定義控件中，onDraw方法作了過多的重複繪製。
• 2，佈局層次太深，重複性太強，用戶看不到的區域GPU也會渲染，致使耗時增長。

8,過分繪製查看工具

在手機的開發這選項裏面，有GPU調式選項。咱們是須要儘可能減小紅色

• 藍色：表明過分繪製一次（無過分繪製）。
• 淡綠：表明過分繪製兩次。
• 淡紅：過分繪製三次。
• 深紅：過分繪製四次。

9，安卓系統有沒有給咱們作優化呢。

CPU轉移到GPU是一件很麻煩的事情，所幸的是OpenGl ES能夠把那些須要渲染的紋理Hold在GPU Memory裏面，在下次須要渲染的時候直接進行操做，因此若是你更新了GPU所hold住的紋理內容，那麼以前保存的狀態就丟失了。 在android裏面那些由主題所提供的的資源，例如Bitmaps,Drawables都是一塊兒打包到統一的Texture紋理當中，而後再傳遞到GPU裏面，這意味着每次你須要使用這些資源的時候，都是直接從紋理裏面進行獲取渲染的。固然隨着UI組件的愈來愈豐富，有了更多的演變的形態。例如顯示圖片的時候，須要先通過GPU的計算加載到內存中，而後傳遞給GPU進行渲染，而後傳遞給GPU進行渲染。文字的顯示比較複雜，須要先通過CPU換算成紋理，而後交給GPU進行渲染，返回當CPU繪製單個字符的時候，再從新引用通過渲染的內容。動畫則存在一個更加複雜的操做流程。 爲了可以使得App流暢，咱們須要在每幀16ms之內處理完全部的CPU與GPU的計算，繪製，渲染等等操做。

10，佈局優化原則

• 1，減小沒必要要嵌套。
• 2，使用merger避免與父容器重疊。

注意：

• 1，減小過分繪製，其實就是減小CPU的計算時間。
• 2，調用Invalidate()重繪View時，在7.0以前（不包含7.0），調用Invalidate()時，將會從新調用onMesure()，onLayout()，onDraw()方法。當在7.0以後（包含7.0），調用Invalidate()時，就只調用onDraw()方法，由於當位置變換時，onMesure()，onLayout()方法會自動調用更新，當位置變換的時候，是在先CPU裏面更新，而後再發送給GPU更新。當位置不變，只是顏色改變時，就只是在GPU裏面更新。