Android性能優化典範——GPU渲染（Profile GPU Rendering）

打開手機裏面的開發者選項，選擇Profile GPU Rendering，如下圖所示：

隨着界面的刷新，界面上會滾動顯示垂直的柱狀圖來表示每幀畫面所需要渲染的時間，柱狀圖越高表示花費的渲染時間越長。綠色的線代表16ms,我們需要確保每一幀花費的總時間都低於這條橫線，這樣才能夠避免出現卡頓的問題。

每一條柱狀線都包含三部分：
（1）藍色部分表示繪製時間或者在Java層創建和更新display list的時間。在一個View 實際被渲染前，它需要先轉換爲GPU能識別的格式。簡單來說可能就是幾個繪製命令，複雜一點，我們可能在嵌入了一條從canvas獲取的自定義路徑。這一步完成之後，輸出結果就會被系統作爲display list緩存起來。

藍色部分記錄了這一幀對所有需要更新的view完成這兩步花費的時間。當它很高的時候，說明有很多view突然無效（invalidate）了，或者是有幾個自定義view在onDraw函數中做了特別複雜的繪製邏輯。
（2）紅色部分代表執行時間，也就是Android 2D渲染引擎（OpenGL）執行display list的時間。爲了將變化繪製在屏幕上，Android需要使用OpenGL ES API來繪製這些display list信息，OpenGL最終將數據傳給了GPU，然後GPU渲染到屏幕上。View越複雜，OpenGL繪製所需要的命令也越複雜。如果紅色這一段比較高，複雜的view都可能是罪魁禍首。還有值得注意的是比較大的峯值，這說明有些view重複提交了，也就是繪製了多次，而它們可能並不需要重繪。
（3）橙色部分代表處理時間，更進一步，就是CPU告訴GPU渲染已經完成的時間。這部分是阻塞的，CPU會等待GPU知道確認收到了命令，如果這裏比較高，說明GPU做的任務太多了，通常是由於很多複雜的view繪製從而需要過多的OpenGL渲染命令去處理。
CPU 與 GPU
現代的圖形API不允許CPU直接與GPU通信，而是通過中間的一個圖形驅動層（Graphics Driver）來連接這兩部分。

圖形驅動維護了一個隊列，CPU把display list添加到隊列裏，GPU從這個隊列取出數據進行繪製。