前言

近期在研究關于 Android 卡頓性能監控，分別驗證了兩種相對有效的監測方案：

• Looper 字符串匹配方案
• Choreographer 幀率檢測方案

這兩種方案都可以監控到應用的卡頓現象，但兩種方案的適用場景卻不太一樣，第一種匹配字符串方案能夠準確得在發生卡頓時拿到堆棧信息，但有一定的性能損耗，不適用于線上監控；第二種監測幀率的方案不一定能準確堆棧，可能會拿到無關的系統堆棧，對定位問題沒有太大幫助，但能夠計算出掉幀率。下面我詳細介紹一下這兩種方案的實現原理和監控效果。

Looper 字符串匹配方案

這個方案相信大家使用過開源項目 BlockCanary 應該比較熟悉，具體實現如下：

設置自定義 Printer，根據 Tag 標記來判斷是否發生卡頓。

我們可以看看 Looper 的源碼：

通過這段源碼我們大概可以如果設置了 Printer，在消息分發前和后都會打印一句 Tag 用來表示事件分發的開始和結束，所以我們可以通過 Looper 打印的 Tag 的時間間隔來判斷是否發生卡頓，這個就是這個方案的原理。

通過上面的代碼，那就會清楚通過判斷 Tag 來設置標記，用于記錄字符串打印的開始和結束，那么我們怎么利用這些標記來拿到我們想要的信息呢？ 我們會實現一個定時器,這個定時器的作用就是定時去 dump 線程堆棧，通過標記我們可以判斷兩次打 tag 的間隔是否超過我們設定的閾值，如果超過閾值，我們會去dump當前所有的 Java 線程堆棧，然后進行數據上報。

具體實現：

制造一個卡頓場景，然后上報：

這種方案可以準確的拿到用戶問題堆棧，但前面說了會有一定的性能損耗，主要存在與字符串拼接可能會產生比較多的臨時對象，會導致內存會頻繁 GC，所以這一套方案比較適用于測試階段使用。

Choreographer幀率檢測方案

這個方案是 API 16 以上才支持，具體實現如下：

這個方案的原理主要是通過 Choreographer 類設置它的 FrameCallback，我們可以在每一幀被渲染的時候記錄下它開始渲染的時間，這樣在下一幀被處理時，我們不僅可以判斷上一幀在渲染過程中是否出現掉幀，而整個過程都是實時處理的。

自定義 FrameCallback 實現：

我們知道在 Android 中系統會發生一個 VSYNC 同步信號來通知界面進行重繪、渲染，每一次同步的周期為16.6ms，代表一幀的刷新頻率，一次界面渲染會回調 doFrame 方法，如果兩次 doFrame 之間的間隔大于16.6ms說明發生了卡頓，我們可以保存兩次 doFrame 時間進行相減然后除以刷新頻率，這樣算出來的結果就是兩次 doFrame 的掉幀數，通過這個掉幀數就能判斷出界面卡頓的嚴重程度，能夠幫助我們定位問題。

可以看一下我們打印出來的效果：

第一個紅框是 Choreographer 打印出來的 log，這個 log 在源碼也可以找到：

總結

上面已經對兩種卡頓性能監測方案的實現原理和測試效果進行了闡述，第一種方案比較適合在發布前進行測試或者小范圍灰度測試然后定位問題，第二種方案適合監控線上環境的 app 的掉幀情況來計算 app 在某些場景的流暢度然后有針對性的做性能優化。如果其他同學對上面的有任何疑問或者有更好的實現方案可以留言進行交流。

騰訊優測?utest.21kunpeng.com

騰訊優測是騰訊旗下的移動云測試平臺，擁有50余名測試領域專家，300余人專業測試團隊，10余年終端測試服務經驗，提供兼容性測試、自動化測試、云真機，設備分享等多種服務方式，不僅支持標準能力輸出，也可提供定制化測試解決方案，幫助企業打造完備的DevOps測試體系，以及具有互聯網思維的質量團隊。

即日起至2020年2月29日，騰訊優測為新老用戶免費提供價值1000元遠程真機租用時長券。

總結

以上是生活随笔為你收集整理的sourcetree 卡顿_Android卡顿性能监测方案对比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。