效能優化系列
CPU 與 GPU 工作流程
介紹
CPU 的任務繁多，做邏輯計算外，還要做記憶體管理、顯示操作，因此 在實際運算的時候效能會大打折扣，在沒有 GPU 的時代，不能顯示覆 雜的圖形，其運算速度遠跟不上今天覆雜三維遊戲的要求。即使 CPU 的工作頻率超過 2GHz 或更高，對它繪製圖形提高也不大。這時 GPU 的設計就出來了
CPU GPU 架構分析
由圖分析 CPU GPU :
- 黃色的 Control 為控制器，用於協調控制整個 CPU 的執行，包括取出指令、控制其它模組的執行等；
- 綠色的 ALU (Arithmetic Logic Unit) 是算術邏輯單元，用於進行數學、邏輯執行；
- 橙色的 Cache 和 DRAM 分別為快取和 RAW，用於儲存資訊；
總結
從 CPU / GPU 結構圖可以看出，CPU 的控制器較為複雜，而 ALU 數量較少。因此 CPU 擅長各種複雜的邏輯運算，但不擅長資料尤其是浮點運算。
簡要執行流程
**柵格化概念: **柵格化是將向量圖形格式表示的影像轉換成點陣圖來交於顯示器
60 HZ 重新整理頻率由來
12 fps: 由於人類眼睛的特殊生理結構，如果所看到的畫面之幀率高於每秒約 10 - 12 幀的時候，就會認為是連貫的；
24 fps: 有聲電影的拍攝及播放幀率均為 24 幀，對一般人而言可以接受；
30 fps: 早期的高動態電子遊戲，幀率少於每秒 30 幀的話就會顯得不連貫，這是因為沒有動態模糊使流暢度降低;
60 fps: 在於手機互動過程中，如觸控和反饋 60 幀以下，肉眼是能感覺出來的。60 幀以上不能察覺變化。當低於 60 fps 時感覺畫面有卡頓現象。
Android 系統每隔 16ms 發出 VSYNC 訊號 (1000 ms / 60 = 16.66 ms) ，觸發對 UI 進行渲染， 如果每次渲染都成功這樣就能夠達到流暢的畫面所需要的 60 fps ，為了能夠實現 60 fps ，這意味著計算渲染的大多數操作都必須在 16ms 內完成
卡頓原理分析
介紹
當這一幀畫面渲染時間操過 16 ms 的時候，垂直同步機制會讓顯示器硬體等待 GPU 完成柵格化渲染操作，這樣會讓這一幀畫面，多停留了 16 ms,甚至更多，這樣就造成了使用者看起來畫面停頓。
16 毫秒的時間主要被兩件事情所佔用
- 將 UI 物件轉換為一系列多邊形和紋理。
- CPU 傳遞處理資料到 GPU 。所以很明顯，我們要縮短 這兩部分的時間，也就是說需要儘量減少物件轉換的次數，以及上 傳資料的次數。
如何減少這 2 件事的耗時，以滿足在16ms 渲染完成
- CPU 減少 xml 轉換成物件的時間。
- GPU 減少重複繪製的時間。
過渡繪製優化(主要減少 GPU 工作量)
簡介
GPU 的繪製過程，就跟刷牆一樣，一層一層的進行， 16 ms 刷一次，這樣就會造成圖層覆蓋的現象，即無用的圖層還是繪製在底層，造成不必要的浪費。
GPU 過渡繪製幾種情況
- 自定義控制元件中 onDraw 方法做了過多重複繪製。
- 佈局層次太深，重疊性太強。使用者看不到區域也會渲染，導致耗時增加。
過渡繪製檢視工具
真彩色: 沒有過渡繪製
淺藍色: 過渡繪製一次
淺綠色: 過渡繪製 二次
粉紅色: 過渡繪製 三次
大紅色: 過渡繪製 四次
工具檢視
優化方案
-
減少背景重複（非業務需要，不要設定背景）
-
去掉單個 activity 的主題設定，可以在 setContentView 之前 getWindow().setBackgroupDrawable(null);
-
去掉所有的 activity 主題中的屬性
<item name="android:windowBackground">@null</item> 複製程式碼
-
-
使用裁剪來減少控制元件之間的重合部分（比如撲克牌）
Android 7.0 之後系統做出了優化 invalidate() 不在執行測量和佈局動作。
佈局的優化(主要減少 CPU 工作量)
常用工具
-
UI Automator Viewer (Android / SDK / tool / bin /uiautomator.bat)
uiautomatorviewer 是 android SDK 自帶的工具。通過截圖並分析 XML佈局檔案的方式，為使用者提供控制元件資訊檢視服務。該工具位於 SDK 目錄下的 tools\bin 子目錄下。可以看到，它是通過 bat 檔案啟動的。
-
monitor.bat (Android/sdk/tools/monitor.bat)。
Device Monitor 視窗中 Hierarchy view；
三個點也是代表著 View 的 Measure , Layout 和 Draw 。
綠: 表示該 View 的此項效能比該 View Tree 中超過 50% 的 View 都要快；例如,代表Measure 的是綠點,意味著這個檢視的測量時間快於樹中的檢視物件的 50%。
黃: 表示該 View 的此項效能比該 View Tree 中超過 50% 的 View 都要慢；
紅: 表示該 View 的此項效能是 View Tree 中最慢的；
總結
- 自定義中 如果有出現覆蓋遮擋的檢視，可以按照上一層的位置來進行 裁剪。
- XML 中層次問題，能在一個平面顯示的內容，儘量只用一個容器。
- 儘可能把相同的容器合併 merge。
- 能複用的程式碼，用 include 處理，可以減少 GPU 重複工作。