卡頓原因千千萬，定位也是真的難。安卓系統(tǒng)APP造成卡頓的問題不好定位，有時判斷不好，甚至破壞了原本的運行程序，這是很大的問題。這篇文章介紹一款性能檢測工具——友盟 U-APM平臺，以及談一談導(dǎo)致卡頓的原因有哪些!

卡頓檢測工具——友盟U-APM性能檢測平臺

U-APM是友盟根據(jù)性能問題研發(fā)出的一款性能檢測工具，通過友盟的接入，我們就可以使用實時、精準(zhǔn)、全面的應(yīng)用崩潰、ANR、自定義異常等捕獲能力， 以及卡頓檢測、啟動分析、內(nèi)存分析、網(wǎng)絡(luò)分析等性能監(jiān)測能力，U-APM卡頓分析支持卡頓趨勢的查看、卡頓列表的篩選、卡頓模塊的計算、卡頓分布的篩選、卡頓詳情頁面的展示，通過U-APM提供的監(jiān)控SDK 捕獲所監(jiān)控App主線程消息執(zhí)行超時的情況，幫助開發(fā)者查找App卡頓問題。說完卡頓問題的定位檢測，我們來探討引起安卓App卡頓的原因有哪些?

第一、SurfaceFlinger 主線程耗時

SurfaceFlinger 負責(zé) Surface 的合成 , 一旦 SurfaceFlinger 主線程調(diào)用超時 , 就會產(chǎn)生掉幀 .

SurfaceFlinger 主線程耗時會也會導(dǎo)致 hwc service 和 crtc 不能及時完成, 也會阻塞應(yīng)用的 binder 調(diào)用, 如 dequeueBuffer \ queueBuffer 等.

第二、屏下光感截圖導(dǎo)致 SurfaceFlinger 渲染不及時

有的 Android 機型使用了屏下光感 , 屏下光感的實現(xiàn)方法也會影響 SurfaceFlinger 主線程的運行 . 屏下指紋需要頻繁截圖 , 來區(qū)分光線和屏幕的變化 , 進行對應(yīng)的亮度變化, 但是其主線程截圖的方法會導(dǎo)致 SurfaceFlinger 主線程被截圖操作所耽誤, 從而導(dǎo)致卡頓

第三、HWC Service 執(zhí)行耗時

hwc Service 耗時也會導(dǎo)致 SurfaceFlinger 下一幀不會做合成操作, 導(dǎo)致應(yīng)用的 dequeueBuffer 和 setTransationState 方法被阻塞, 導(dǎo)致卡頓

第四、CRTC 執(zhí)行耗時

crtc 執(zhí)行耗時的結(jié)果就是 SurfaceFlinger 下一幀不會做合成操作, 導(dǎo)致應(yīng)用的 dequeueBuffer 和 setTransationState 方法被阻塞, 導(dǎo)致卡頓

第五、CPU 調(diào)度問題

重要任務(wù)跑小核性能不足導(dǎo)致卡頓，RenderThread 跑小核，cpu 頻率對性能的影響：

優(yōu)先級低未能及時獲取 cpu 時間片導(dǎo)致卡頓

在調(diào)度器看來的低優(yōu)先級任務(wù) , 在用戶這里未必是低優(yōu)先級任務(wù) , 他可能正在和 App 的主線程交互 , 或者正在和 system_server 進行交互

被 RT 進程搶占

App 主線程或者渲染線程被 RT 進程搶占也會導(dǎo)致系統(tǒng)卡頓或者響應(yīng)慢 , Google 也意識到了這個問題 , 也在嘗試在應(yīng)用啟動的時候 , 把 App 主線程和渲染線程的優(yōu)先級也設(shè)置為 RT , 不過這個屬性一直沒開 , 因為會導(dǎo)致應(yīng)用啟動速度變慢.

大小核調(diào)度導(dǎo)致

大小核調(diào)度的問題通常表現(xiàn)在該跑在大核的任務(wù)跑到了小核 , 或者該在小核運行的任務(wù)卻持續(xù)跑到大核 ,或者錯誤的被綁定在了某一個核心上。

第六、觸發(fā) Thermal 導(dǎo)致限頻

觸發(fā) Thermal 發(fā)熱限頻也有可能導(dǎo)致卡頓 , 這算是一種硬件級別的保護 , 如果手機已經(jīng)過熱 , 此時如果不進行干涉 , 那么可能會導(dǎo)致用戶手機太燙而無法持續(xù)使用手機. 一般這個時候都會對系統(tǒng)的資源進行一些限制 , 比如降低 cpu\gpu 的最高頻率之類的 , 這么做的話 , 勢必也會對流暢性造成影響.

第七、后臺活動進程太多導(dǎo)致系統(tǒng)繁忙

后臺進程活動太多,會導(dǎo)致系統(tǒng)非常繁忙, cpu \ io \ memory 等資源都會被占用, 這時候很容易出現(xiàn)卡頓問題 , 這也是系統(tǒng)這邊經(jīng)常會碰到的問題

1、CPU 繁忙

dumpsys cpuinfo 可以查看一段時間內(nèi) cpu 的使用情況

主線程調(diào)度不到 , 處于 Runnable 狀態(tài)，當(dāng)線程為 Runnable 狀態(tài)的時候 , 調(diào)度器如果遲遲不能對齊進行調(diào)度 , 那么就會產(chǎn)生長時間的 Runnable 線程狀態(tài) , 導(dǎo)致錯過 Vsync 而產(chǎn)生流暢性問題.

2、Runnable

無關(guān)進程活躍耗時

無關(guān)進程通常是人為定義的 , 指的是與當(dāng)前前臺 App 運行無關(guān)的進程 , 這些活躍進程勢必會對 App 主線程的調(diào)度產(chǎn)生影響 , 不管這些無關(guān)進程是系統(tǒng)的還是 App 自身的 , 或者是其他三方 App 的。

3、cpu 被占用

原因同上 , 當(dāng)后臺任務(wù)過多的時候 , cpu 資源就會異常緊缺 ,在系統(tǒng)低內(nèi)存的時候 , HeapTask 和 kswapD 幾乎占滿了整個 cpu , 在瘋狂地向系統(tǒng)申請內(nèi)存。

4、SystemServer 鎖

system_server 的 AMS 鎖和 WMS 鎖, 在系統(tǒng)異常的情況下, 會變得非常嚴重, 許多系統(tǒng)的關(guān)鍵任務(wù)都被阻塞, 等待鎖的釋放, 這時候如果有 App 發(fā)來的 Binder 請求帶鎖, 那么也會進入等待狀態(tài), 這時候 App 就會產(chǎn)生性能問題; 如果此時做 Window 動畫 , 那么 system_server 的這些鎖也會導(dǎo)致窗口動畫卡頓。

以上文章是關(guān)于安卓系統(tǒng)APP卡頓原因的詳細分析，關(guān)于APP卡頓的解決方案我們下次再談，本文還介紹了一款應(yīng)用性能檢測工具——友盟 U-APM，另外，U-APM還具有其他的功能值得我們進行研究，感興趣的小伙伴可以登錄官網(wǎng)體驗。