為什麼用戶感覺畫面卡頓
所謂卡頓，即顯示的流暢程度不夠，被用戶所感知。正常情況下以機器刷新率每秒60幀標準的話，我們就需要在16ms內完成每一幀的計算繪製操作，當由於系統或應用本身的問題，畫面不能再16ms內完成顯示，導致大量丟幀，用戶感覺畫面卡頓。
為什麼會造成卡頓
- 主線程處理了較多非繪製任務
這個很好理解，通常主線程即UI線程，主要用於處理UI任務，但由於開發人員沒有處理好UI線程和子線程的任務分配工作，或主線程的不當使用，導致UI任務得不到執行，造成畫面幀生成過少或不及時導致丟幀，形成卡頓。
- 頁面佈局不合理
一般系統計算出顯示出一幀，經過了諸多過程，代碼級別上為onMeasure, onLayout, onDraw過程，當其中某個過程耗時較多時，就可能被用戶感知卡頓，本文主要講述如何優化頁面佈局。
過度繪製
Android在幕繪製上對每個像素點繪製 的次數進行統計，根據繪製的次數定義過度繪製等級，通常繪製一次為最佳，次數越多，系統消耗越大，耗時也就越大。
打開調試：設置——開發者選項——調試GPU過度繪製——顯示過度繪製區域。
系統繪製層級取決於當前應用界面佈局的畫面層級，優秀的佈局應保持在2X（綠色）以下。
- 更好的容器選擇-ConstraintLayout
一般情況LinearLayout只能在一個方向上連續排列的控件，可能會造成嵌套層級過多，而RelateLayout雖然靈活，但其設計上較為複雜，在Measure和Layout時性能稍微遜色，活用ConstraintLayout（約束佈局） 相對集成了既有RelateLayout的約束排布又兼容了LinearLayout的定向排布和權重，大大減少使用多餘Layout層級。
- 掌握自定義佈局技巧
自定義View，幾個簡單化排布的view，直接在同一個View裡面計算並繪製，
例如：
“分辨率”這條Button，我們可以直接把後面的“1080P”字同樣畫在Button裡面，這種情況還可以複用自定義Button。較少嵌套一層Layout。
- 使用merge標籤，減少佈局深度
只針對有include layout的使用merge標籤，merge標籤作用是對被標籤的layout做抵消作用，實際的父佈局就是再上一層的父layout。只能用於根佈局，直接較少一層深度
- 高效佔位符ViewStub
延遲初始化View，標籤ViewStub, xml被解析時遇到ViewStub標籤的並不會創建對象初始化，只有在要使用該View時，主動去調用ViewStub.inflate()才會創建生成View對象。使用的場景情況和需要使用到一個新界面直接inflate一個出來再add進去顯示一樣。
- 善用動態佈局加載，加快應用啟動速度
應用啟動時間，取決於第一次加載、初始化時間長短，不要一個佈局裡面放上很多界面層級，然後通過set界面的隱藏和顯示來達到目的，建議是使用藉助fragment（View替換的形式）或者windowmanager addview或者是父View 動態addview的方式。做到初始界面佈局精簡不繁雜。
- 採用局部刷新方式，減小刷新面積
相對需要不停的刷新的子view界面，像跑馬燈，時間變化條等，可選用寫死佈局子view寬度高度的方式（MeasureSpec.EXACTLY）來減少父view的全layout刷新，還有可以使用invalidate（int l,int t,int r,int b）刷新固定區域。
- 少一層背景，少一層繪製
Android自帶的一些主題時，默認添加一個純色的背景，可以通過android:windowbackground="null"和getWindow().setBackgroundDrawable(null);取消該背景。在佈局中為一些不需要設置背景的容器的color屬性設置@android:color/transparent。
- 圖片優化，避免大背景圖片
使用背景圖時，可以嘗試使用工具將其大小進行優化，減少載入內存的時間，其次儘量使用滿足分辨率的圖片，因為Android的分辨率適配機制，可能會將不符合分辨率的圖片進行拉伸壓縮處理，儘量減少這些不必要的耗時。
