佈局繪製流程

CPU 與 GPU

• CPU的任務繁多，作邏輯計算外，還要作內存管理，顯示操做，所以在運行的時候性能會大大折扣，在沒有GPU的時代，不能顯示覆雜的圖形，即便GPU工做頻率超過了2GHz或者更高，對它繪製圖形提升也不大，因此GPU就設計出來了

1. 以上圖中，CPU中Control爲控制器，用於協調整個CPU的運行，包括取出指令，控制其餘模塊的運行
2. 綠色的爲ALU是算數邏輯單元，用於數據邏輯計算
3. 橙色Cache和DRAM分別爲緩存和RAM，用於存儲信息
*  CUP的控制較爲複雜，而ALU較少，所以CPU擅長處理各類複雜邏輯運算，可是不擅長數學尤爲是浮點運算
複製代碼

XML佈局顯示到屏幕流程

1. LayoutInflater方法將佈局加載進內存
2. CPU通過計算將UI對象轉換成多維圖形
3. 經過OPENGL調用GPU
4. GPU對圖形進行柵格化
5. 上述步驟若是在16ms內完成直接在顯示器上顯示，若是完不成垂直同步等待下一幀完成

爲何16ms必須完成繪畫

1. 60fps 在與手機進行交互的時候，如觸摸與反饋60幀如下的人是能夠感應出來的，60幀以上不能感受到變化
2. 當頻率地獄60幀的時候感受畫面卡頓和停滯現象
3. Android系統會每隔16ms發送VSYNC信號（1000/60=16.66ms），觸發對UI進行渲染，若是每次渲染都成功這樣就能達到流暢的畫面所須要的60fps，爲了可以實現60fps，這就意味着計算機渲染大多數操做都必須再16ms內完成

過渡繪製

1. CPU繪製過程是根據CPU發送的指令來的，他很傻，讓他畫什麼就畫什麼，16ms就畫一次，形成有些圖像被其餘圖像進行覆蓋，底下以及面上的圖像都要繪製，形成了必要的浪費

• 過渡繪製的幾種狀況
  1. 佈局層次太深，用戶看不到的區域也會被繪製
  2. 自定義View中，onDraw的方法作了過多的繪製

打開開發者選項，開啓過渡繪製

1. 藍色 過渡繪製一次 無過渡繪製
2. 淡綠 過渡繪製兩次
3. 淡紅 過渡繪製三次
4. 深紅 過渡繪製四次

這表明了4種不一樣程度Overdraw狀況，咱們的目標是儘可能減小紅色，Overdraw看到更多的藍色區域

卡頓原理

1. 將UI對象轉換成多邊形和紋理
2. CPU傳遞數據到GPU，GPU進行繪製

減小以上兩部分時間

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

總結

1. 性能優化看上去很是高大上，但其實就是細節決定成敗，須要對原理性的東西瞭解清楚，每一步都有什麼不同，針對每個步驟進行細緻化的優化，性能優化是一種思想，而不是一套具體的操做方法
2. 佈局中的背景是否有須要（主題背景）
3. 是否能夠刪除多餘佈局
4. 自定義View是否進行了裁剪
5. 佈局是否夠扁平化

謝謝你們支持

• 但願你們關注，我會不時更新
• GitHub hunimeizi