性能優化(二) UI 繪製優化

性能優化系列

APP 啓動優化

UI 繪製優化

內存優化

圖片壓縮

長圖優化

電量優化

Dex 加解密

動態替換 Application

APP 穩定性之熱修復原理探索

APP 持續運行之進程保活實現

ProGuard 對代碼和資源壓縮

APK 極限壓縮

CPU 與 GPU 工做流程

介紹

CPU 的任務繁多，作邏輯計算外，還要作內存管理、顯示操做，所以 在實際運算的時候性能會大打折扣，在沒有 GPU 的時代，不能顯示覆 雜的圖形，其運算速度遠跟不上今天覆雜三維遊戲的要求。即便 CPU 的工做頻率超過 2GHz 或更高，對它繪製圖形提升也不大。這時 GPU 的設計就出來了

CPU GPU 架構分析

由圖分析 CPU GPU :

1. 黃色的 Control 爲控制器，用於協調控制整個 CPU 的運行，包括取出指令、控制其它模塊的運行等；
2. 綠色的 ALU (Arithmetic Logic Unit) 是算術邏輯單元，用於進行數學、邏輯運行；
3. 橙色的 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 毫秒的時間主要被兩件事情所佔用

1. 將 UI 對象轉換爲一系列多邊形和紋理。
2. CPU 傳遞處理數據到 GPU 。因此很明顯，咱們要縮短 這兩部分的時間，也就是說須要儘可能減小對象轉換的次數，以及上 傳數據的次數。

如何減小這 2 件事的耗時，以知足在16ms 渲染完成

1. CPU 減小 xml 轉換成對象的時間。
2. GPU 減小重複繪製的時間。

過渡繪製優化(主要減小 GPU 工做量)

簡介

​ GPU 的繪製過程，就跟刷牆同樣，一層一層的進行， 16 ms 刷一次，這樣就會形成圖層覆蓋的現象，即無用的圖層仍是繪製在底層，形成沒必要要的浪費。

GPU 過渡繪製幾種狀況

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

過渡繪製查看工具

真彩色: 沒有過渡繪製

淺藍色: 過渡繪製一次

淺綠色: 過渡繪製 二次

粉紅色: 過渡繪製 三次

大紅色: 過渡繪製 四次

工具查看

優化方案

1. 減小背景重複（非業務須要，不要設置背景）

   1. 去掉單個 activity 的主題設置，能夠在 setContentView 以前 getWindow().setBackgroupDrawable(null);

   2. 去掉全部的 activity 主題中的屬性

      <item name="android:windowBackground">@null</item>
      複製代碼

2. 使用裁剪來減小控件之間的重合部分（好比撲克牌）

   Android 7.0 以後系統作出了優化 invalidate() 不在執行測量和佈局動做。

佈局的優化(主要減小 CPU 工做量)

經常使用工具

1. UI Automator Viewer (Android / SDK / tool / bin /uiautomator.bat)

   

   uiautomatorviewer 是 android SDK 自帶的工具。經過截屏並分析 XML佈局文件的方式，爲用戶提供控件信息查看服務。該工具位於 SDK 目錄下的 tools\bin 子目錄下。能夠看到，它是經過 bat 文件啓動的。

2. 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 中最慢的；

總結

1. 自定義中 若是有出現覆蓋遮擋的視圖，能夠按照上一層的位置來進行 裁剪。
2. XML 中層次問題，能在一個平面顯示的內容，儘可能只用一個容器。
3. 儘量把相同的容器合併 merge。
4. 能複用的代碼，用 include 處理，能夠減小 GPU 重複工做。