Android 每隔16ms發出一個VSYNC訊號，觸發CPU跟GPU進行介面渲染，計算跟繪製，讓介面的幀率在1秒內達到60fps，使視覺效果達到自然流暢。如果一個在16ms內不能完成介面的渲染，計算跟繪製，就會產生丟幀的現象，丟幀就會造成應用卡頓現象。

一、引起應用卡頓的原因

1.過度繪製。過度繪製就是在同一幀情況下對同一塊畫素區域進行重複繪製。這樣會加重GPU跟CPU的渲染壓力，導致渲染時間過長。
2.佈局巢狀過多。佈局巢狀過多過於複雜也會導致CPU跟GPU的渲染，計算，繪製壓力。
3.動畫執行次數過多。
4.執行耗時操作。檔案讀寫，資料操作，較大資料初始化等較為耗時的操作阻塞執行緒。
5.頻繁GC。執行GC的時候，所有操作都需要暫停，等到GC結束後，才能繼續執行操作。這樣就可能會阻塞CPU跟GPU的渲染，計算跟繪製。

二、卡頓的分析步驟思路

分析卡頓主要使用可以檢測UI卡頓的工具來分析，知道了可能引起卡頓的原因後，就可以針對每一點使用相應的工具來檢測分析。我們按順序從第一點開始。

1、檢視過度繪製情況—除錯GPU過度繪製

開啟手機的“除錯GPU過度繪製”功能分析UI的繪製情況
在手機的設定->開發選項->除錯GPU過度繪製 開啟除錯功能。開啟後就可以看到UI的繪製情況了。
可以使用此功能初步檢視UI的繪製情況，然後進行相應的優化。

藍色，淡綠，淡紅，深紅代表了4種不同程度的繪製情況，其中藍色表示只繪製一次，最為理想，深紅表示繪製4次以上，效能最差，最為忌諱。對紅色以上部分進行重點優化：

• 減少背景重疊，儘量在子View設定背景，不要在根View設定背景，防止子View有了背景，根View也有了背景，造成重疊。
• 減少佈局的巢狀，減少佈局層級。
• 去除Activity的預設背景色。
• 在自定義View的onDraw或者自定義ViewGroup的drawChild方法中使用Canvas的clipRect()方法繪製指定區域。

2、檢視佈局巢狀情況—HierarchyViewer

在Android studio的導航欄的Tools->Android->Android Devices Monitor， 選擇Window -> Hierarchy View。

3、檢視執行耗時情況—systrace + traceview

Systrace 檢視UI繪製的幀率情

Systrace 可以用來分析由於丟失幀而導致的UI卡頓問題。當出現丟幀時，會以 Alert 提示並給出優化的提示。
Systrace會自動分析資訊，將效能問題直接以alerts的方式高亮顯示。

1、生成 trace 檔案
啟動Systrace：Android Studio，Tools–android–Android Device Monitor，再點選DDMS的Systrace圖示。

啟動之後，生成trace.html 檔案，在Chorme瀏覽器中開啟進行分析：

2、分析問題
F圓圈表示一幀（Frame）,有綠，黃，紅三種狀態，渲染時間依次遞增。
正常繪製是1秒60幀，大約一幀16.6毫秒，在這個值以下是正常顏色綠色，如果超過它就會變成紅色、黃色。一般紅色就是有問題的，要優化的地方。。單點選後可檢視Frame詳細資訊，根據Alert提示解決問題。
點選某個單獨的 Frame，按下m鍵可以看到該 Frame 的執行時間。並且通過alerts提示該展現問題，以及建議如何處理。

在左下角我們可以看到 “Scheduling delay”這條Alert提示裡。
Scheduling delay（排程延遲）的意思就是一個執行緒在處理一塊運算的時候，在很長一段時間都沒有被分配到CPU上面做運算，從而導致這個執行緒在很長一段時間都沒有完成工作。
2、程式碼控制開始和結束
以上方式不能在程式碼中控制Trace執行的開始和結束，那有沒有辦法呢？答案是肯定的。
Android定義了一個Trace類，這個 Trace 類就是用來做資料採集的。我們可以用這個類來自定義Trace Label ，解決在程式碼中控制開始和結束。可以在程式碼中插入如下程式碼來分析某個特定的過程：

//生成的trace檔案中，會在跟蹤的程式碼段執行對應時間軸區間打上一個tag標記
Trace.beginSection("Trace begin");  
...
//Trace的begin與end必須在同一執行緒之中執行
Trace.endSection(); 

Traceview分析函式執行時間

使用systrace分析之後，並不能定位到具體的程式碼，這時就可以使用 Traceview 來定位具體的程式碼了。
Traceview可以清晰地看到每個方法的執行耗時和呼叫次數，然後定位具體的卡頓程式碼。

1、生成 trace 檔案

• 使用程式碼
• 使用DDMS

1.1 使用程式碼生成 trace 檔案

Debug.startMethodTracing(String tracePath);
//...
Debug.stopMethodTracing();

1.2 使用DDMS生成 trace 檔案
在Android studio的導航欄的Tools->Android->Android Devices Monitor選擇DDMS,然後點選Start Method Profiling，即可開始：

然後操作我們需要檢測的介面，過一會之後，再點選這個按鈕，即可停止。DDMS就會自動開啟如下介面：

Name:名稱
Incl Cpu Time ：方法及其呼叫方法總共佔用CPU的時間。
Excl Cpu Time ：方法本身佔用CPU的時間。
Incl Real Time ：方法及其呼叫方法真實執行時間。
Excl Real Time ：方法本身真實執行時間。
Calls+Recur Calls/Total：方法被呼叫次數以及遞迴呼叫次數佔總呼叫次數的百分比
Cpu Time/Calls：方法執行的平均佔用CPU時間。
Real Time/Calls：方法執行的平均真實執行時間。

2、定位問題
使用Traceview，一般可以定位兩類函式：

• 執行時間比較長。
  點選 TraceView 中的 Incl Real Tim，按照方法執行時間從高到低排序
• 執行時間斷，但是呼叫次數過於頻繁的。
  點選 TraceView 中的 Calls + Recur Calls/Total ，按照呼叫次數從高到底排序

我們可以對相關屬性進行排序，加上 Find 搜尋，從而定位執行時間較長的或者呼叫過於頻繁的函式並進行優化。

4、檢視GC情況—Memory Monitor

由於GC導致UI卡頓，這種情況一般可能是由於記憶體抖動，頻繁GC造成的。
可以使用 Allocation Tracker 來檢視是否有記憶體抖動情況， Allocation Tracker可以檢視程式碼中分配的物件型別、大小情況。

在 Android studio 中的 Android Monitor -> Memory Monitor 可以檢視應用的記憶體使用情況，以及實時的GC情況。
點選 Memory Monitor -> Start Allocation Tracker 按鈕開啟追蹤記憶體情況：

等程式執行幾秒後，再按一下結束追蹤，會開啟如下分析介面：

三、效能監控元件 Blockcanary

Blockcanary 是檢測UI卡頓利器