性能優化--UI渲染性能優化
卡頓現象
渲染功能是應用程序最普遍的功能，開發任何應用程序都是這樣，一方面，設計師要求爲用戶展現可用性最高的超然體驗，另一方面，那些華麗的圖片和動畫，並不是在所有的設備上都能劉暢地運行。我們來了解一下什麼是渲染性能。
首先，我們要知道Android系統每隔16ms就重新繪製一次Activity，也就是說，我們的應用必須在16ms內完成屏幕刷新的全部邏輯操作，這樣才能達到每秒60幀，然而這個每秒幀數的參數由手機硬件所決定，現在大多數手機屏幕刷新率是60赫茲（赫茲是國際單位制中頻率的單位，它是每秒中的週期性變動重複次數的計量），也就是說我們有16ms（1000ms/60次=16.66ms）的時間去完成每幀的繪製邏輯操作，如果錯過了，比如說我們花費34ms才完成計算，那麼就會出現我們稱之爲丟幀的情況
渲染管線
Android系統的渲染管線分爲兩個關鍵組件：CPU和GPU，它們共同工作，在屏幕上繪製圖片，每個組件都有自身定義的特定流程。我們必須遵守這些特定的操作規則才能達到效果。
在CPU方面，最常見的性能問題是不必要的佈局和失效，這些內容必須在視圖層次結構中進行測量、清除並重新創建，引發這種問題通常有兩個原因：一是重建顯示列表的次數太多，二是花費太多時間作廢視圖層次並進行不必要的重繪，這兩個原因在更新顯示列表或者其他緩存GPU資源時導致CPU工作過度。
在GPU方面，最常見的問題是我們所說的過度繪製（overdraw），通常是在像素着色過程中，通過其他工具進行後期着色時浪費了GPU處理時間。
在我們的繪製渲染機制裏面比較耗時的：
1.CPU計算時間
CPU的優化，從減輕加工View對象成Polygons和Texture來下手
View Hierarchy中包涵了太多的沒有用的view，這些view根本就不會顯示在屏幕上面，
一旦觸發測量和佈局操作，就會拖累應用的性能表現。
1.如何找出裏面沒用的view呢？或者減少不必要的view嵌套。
工具：Hierarchy Viewer檢測
優化：
1）當我們的佈局是用的FrameLayout的時候，我們可以把它改成merge
可以避免自己的幀佈局和系統的ContentFrameLayout幀佈局重疊造成重複計算(measure和layout)
ViewStub：當加載的時候纔會佔用。不加載的時候就是隱藏的，僅僅佔用位置。
[hierarchyviewer]Unable to capture data for node
android.widget.LinearLayout@e6fdb11 in window com.example.android.mobileperf.render/com.example.android.mobileperf.render.ChatumLatinumActivity on device 192.168.56.101:5555
三個圓點分別代表：測量、佈局、繪製三個階段的性能表現。
1）綠色：渲染的管道階段，這個視圖的渲染速度快於至少一半的其他的視圖。
2）黃色：渲染速度比較慢的50%。
3）紅色：渲染速度非常慢。
優化思想:查看自己的佈局，層次是否很深以及渲染比較耗時，然後想辦法能否減少層級以及優化每一個View的渲染時間。
2.CPU將計算好的Polygons和Texture傳遞到GPU的時候也需要時間
OpenGL ES API允許數據上傳到GPU後可以對數據進行保存，做了緩存。
3.GPU進行格柵化
優化：儘量避免過度繪製（overdraw）
GPU如何優化：
1.背景經常容易造成過度繪製。
手機開發者選項裏面找到工具：Debug GPU overdraw
由於我們佈局設置了背景，同時用到的MaterialDesign的主題會默認給一個背景。
/解決的辦法：將主題添加的背景去掉
2.自定義控件如何處理過度繪製。
可以通過裁剪來處理。