聲明：原創文章，轉載請註明出處https://www.jianshu.com/p/8a296b75d95f
APP卡頓對用戶體驗有很大的影響，今天就來總結下Android應用卡頓相關內容。
要想知道應用卡頓是怎麼產生的，我們首先得了解下手機屏幕的畫面是怎麼產生的，也就是Android的屏幕刷新機制。
Android 屏幕刷新機制
一級緩存
如上圖所示，當需要顯示一幀畫面時，CPU會先計算相關數據，然後再通過GPU渲染，GPU渲染完之後會把這幀畫面存入一個緩存中，CPU和GPU向緩存中存入畫面的速率也叫幀率，幀率是變化的，比如APP中一個列表，當列表靜止不動幀率就是0，如果滑動起來幀率就會變化。接着我們的屏幕會以一定的頻率來從緩存中取數據，這個速率也叫做屏幕刷新率。這個刷新率是固定的，一般爲60hz，當然現在也有90hz甚至120hz的屏幕。另外屏幕從緩存中取數據也不是瞬間取完的，它是有一個掃描的過程，也就是一個像素點一個像素點的去緩存中去取，取的順序是逐行地從左到右逐個像素點掃描。不過這也帶來了一個問題，就是可能會在屏幕取數據取到一半的時候，這時緩存中數據更新了，但是屏幕並不知道，會接着從緩存中取，當然接下來取到的數據其實的更新後的新的一幀，這樣屏幕就同時顯示了兩幀畫面，我們叫這種現象爲畫面撕裂，如下圖所示：
二級緩存
爲了解決這個問題，可以增加一個緩存，如下：
可以看到上面有兩個緩存，Back Buffer和Frame Buffer，每次CPU、GPU產生的幀數據都存入Back Buffer，而屏幕每次都是從Frame Buffer中取，然後需要更新畫面的時候，就交換Back Buffer和Frame Buffer兩個緩存中的數據。那麼這個交換兩個緩存的時間如何確定呢，我們知道屏幕顯示一幀是逐個像素點顯示，是需要時間，而取完一幀的最後一個點到顯示下幀第一個，這個時間段正好可以作爲切換這兩個緩存的時間點，此時會發出 VSync 信號，即垂直同步信號。但是CPU和GPU計算畫面的時間點不是確定的，也就是畫面的產生和刷新是不同步的，這樣就會有一個問題
上圖我們可以看到，第一幀在垂直同步信號到來之前已經計算好了，所以當垂直同步信號到來的時候成功顯示，但是當第二個垂直同步信號來的時候第二幀的畫面還沒計算完，所以會再次顯示第一幀，也就出現卡頓，我們也叫這種爲掉幀，顯然掉幀不是少了一幀而是多了一幀。有啥辦法可以解決？上圖可以看到第二幀的計算是在第一個VSync和第二個VSync中間纔開始計算的，那麼能不能在第一個VSync來了之後立馬開始計算爲第二幀的顯示做準備，這樣就有足夠的時間來準備這幀畫面。答案是肯定的，從Android 4.1開始Google對這一問題進行了優化，就是每當同步信號過來的時候就開始爲下一幀做準備，如下圖：
但是有的時候我們一幀的計算非常耗時，時間超出了兩個VSync的間隔，如下：
可以看到GPU在渲染B幀的時候太耗時了，再下次VSync到來的時候還沒渲染好，這時就會重複顯示上幀的內容即畫面A，這樣就又出現卡頓，直到下個Vsync信號到來纔會顯示B幀。
三級緩存
上面我們可以看到，當一個VSync到來的時候，GPU還在計算，但是CPU其實已經計算完了，那麼爲什麼這時CPU不參加計算下一幀的畫面呢？這樣就可以節省很多時間。原因是CPU和GPU是公用的一個緩存，也就是上面提到的Back Buffer，所以爲了解決這個問題，Android 又爲CPU增加了一個獨立的緩存。
上面可以看到第一個垂直同步信號到來的時候，GPU還在計算畫面，但是CPU已經空閒了，所以已經開始計算下一幀了，這樣就提高了時間利用率。
卡頓產生的原因
瞭解了Android屏幕的刷新機制，來總結下卡頓產生的原因，從上面我們也能知道，卡頓的本質就是一幀的展示時間大於了兩個垂直同步信號的時間間隔。下面簡單概括下一幀的畫面是爲啥變慢的，先從系統層面來看下，有以下幾個原因：
SrufaceFlinger主線程耗時
後臺活動進程太多導致系統繁忙
主線程調度不到，處於Runnable狀態
System鎖
Layer過多導致SurfaceFlinger Layer Compute耗時
從應用層角度有以幾個原因：
主線程執行時間長
主線程Binder耗時
Webview性能不足
幀率與刷新率不匹配
卡頓檢測
往往造成卡頓的代碼是很隱蔽的，所以對卡頓代碼的檢測和定位就顯得尤爲重要。當然對卡頓的檢測需要藉助一些分析工具，下面簡單羅列了幾種分析工具：
使用dumpsys gfxinfo
使用Perfetto
使用LayoutInspector檢測佈局層次
使用BlockCanary
dumpsys gfxinfo
這是一個adb命令，可以大致顯示當前應用的一些顯示數據，命令如下：
adb shell dumpsys gfxinfo 應用完整包名
部分顯示內容如下
Stats since: 2136261710504255ns
Total frames rendered: 1 // 本次蒐集了一幀的信息
Janky frames: 1 (100.00%) // 卡頓的幀數爲1，佔比100%
50th percentile: 34ms
90th percentile: 34ms
95th percentile: 34ms
99th percentile: 34ms
Number Missed Vsync: 0 // 垂直同步失敗的幀
Number High input latency: 0 // 處理input超時的幀
Number Slow UI thread: 0 //因UI線程超時導致卡頓的幀
Number Slow bitmap uploads: 0 // 因bitmap的加載耗時的幀數
Number Slow issue draw commands: 1 // 因繪製導致耗時的幀數
Number Frame deadline missed: 1
perffeto
perffeto是一個網頁版的性能分析工具，地址是https://ui.perfetto.dev/#!/，分析時需要上傳性能跟蹤文件，當然這個文件可以通過Android手機自帶的一個系統應用追蹤錄製生成。打開這個系統應用的方式是開發者模式->調試->系統跟蹤，然後打開跟蹤可調式的應用開關，這樣你手機的上方快捷操作欄就會多出一個錄製跟蹤記錄的快捷開關，點擊後就會進行性能追蹤錄製，再次點擊就會停止錄製，並且會在通知欄中產生一個完成錄製的提示，點擊就可以分享錄製的跟蹤文件。
接下來簡單演示下，創建一個默認空項目，然後在MainActivity中的onResume方法中加入3秒的sleep，如下：
override fun onResume() {
super.onResume()
Thread.sleep(3000)
}
接下來我們點擊快捷欄的錄製按鈕，然後在手機上運行該demo，大概過個10秒左右點擊停止錄製，然後生成跟蹤文件，我們把這個跟蹤上傳至上面的perffeto分析地址，然後會得到這樣的分析結果：
可以看到上面這些五顏六色的可以理解成一個個事件，橫座標是時間，方塊長度越長說明越耗時，接下來我們找到我們剛剛寫的demo
可以看到我們這個demo中，有一個明顯很長的事件，上面也可以看到事件的名字就是我們剛纔寫的onResume，可以看上面的時間軸剛好也是3秒，這樣我們也就定位出問題所在了。
LayoutInspector
佈局如果嵌套太多也會影響畫面的渲染產生卡頓，所以可以藉助LayoutInspector工具來查看佈局的層級結構，這個是Android Studio內置的
如上圖所示，左側會顯示該佈局的層級結構。
BlockCanary
BlockCanary是一個非侵入式的三方庫，它是模仿的LeakCanary。當某處有延遲時，就會在通知欄提示。他的原理是基於handler機制，對handler還不是很瞭解的可以參考之前的這篇文章Android 帶你徹底理解跨線程通信之Handler機制，我們知道Android主線程中所有的事件都是通過handler處理的，而系統在handler每次處理消息的前後都預留了日誌輸出的接口，那麼我們可以在預留的接口中增加時間記錄，然後計算事件處理前後的時間差，如果大於某一閾值就產生告警提示開發者，這也就是BlockCanary的思路。
卡頓優化
在上面我們已經瞭解了卡頓產生的原因就是一幀的渲染大於規定的時間，那麼優化的主要思路就是減少耗時，當然上面我們也說了一些耗時的代碼往往是很隱蔽的，這就需要我們使用上面提到的卡頓檢測和定位的工具，這也是卡頓優化的關鍵。此外我們還是簡單羅列下優化的一些方向：
佈局優化：佈局的過多嵌套會影響渲染效率
減少主線程耗時：這個不多說了
減少過渡繪製：界面的過渡繪製也會影響耗時
列表優化 ：比如某一個item更新，只需要更新這個item不需要整個列表全部更新
對象分配和回收優化：因爲Java垃圾回收會暫停線程，所以要避免頻繁的創建對象銷燬對象，減小垃圾回收頻次。