使用dumpsys gfxinfo 測UI性能(適用于Android6.0以后)

原文地址:https://developer.android.com/training/testing/performance.html

使用dumpsys gfxinfo 測UI性能


dumpsys是一款運(yùn)行在設(shè)備上的Android工具骡技,將 gfxinfo命令傳遞給dumpsys可在logcat中提供輸出杭抠,其中包含各階段發(fā)生的動畫以及幀相關(guān)的性能信息矮慕。

> adb shell dumpsys gfxinfo < PACKAGE_NAME >

該命令可用于搜集幀的耗時數(shù)據(jù)。運(yùn)行該命令后查描,可以等到如下的 結(jié)果:

Applications Graphics Acceleration Info:
Uptime: 102809662 Realtime: 196891968

** Graphics info for pid 31148 [com.android.settings] **

Stats since: 102794621664587ns
Total frames rendered: 105
Janky frames: 2 (1.90%)
50th percentile: 5ms
90th percentile: 7ms
95th percentile: 9ms
99th percentile: 19ms
Number Missed Vsync: 0
Number High input latency: 0
Number Slow UI thread: 2
Number Slow bitmap uploads: 0
Number Slow issue draw commands: 1
HISTOGRAM: 5ms=78 6ms=16 7ms=4 8ms=1 9ms=2 10ms=0 11ms=0 12ms=0 13ms=2 14ms=0 15ms=0 16ms=0 17ms=0 18ms=0 19ms=1 20ms=0 21ms=0 22ms=0 23ms=0 24ms=0 25ms=0 26ms=0 27ms=0 
...
...

這里將逐一解釋以上重點信息:

  • Graphics info for pid 31148 [com.android.settings]: 表明當(dāng)前dump的為設(shè)置界面的幀信息,pid為31148
  • Total frames rendered: 105 本次dump搜集了105幀的信息
  • Janky frames: 2 (1.90%) 105幀中有2幀的耗時超過了16ms柏卤,卡頓概率為1.9%
  • Number Missed Vsync: 0 垂直同步失敗的幀
  • Number High input latency: 0 處理input時間超時的幀數(shù)
  • Number Slow UI thread: 2 因UI線程上的工作導(dǎo)致超時的幀數(shù)
  • Number Slow bitmap uploads: 0 因bitmap的加載耗時的幀數(shù)
  • Number Slow issue draw commands: 1 因繪制導(dǎo)致耗時的幀數(shù)
  • HISTOGRAM: 5ms=78 6ms=16 7ms=4 ... 直方圖數(shù)據(jù)冬三,表面耗時為0-5ms的幀數(shù)為78,耗時為5-6ms的幀數(shù)為16缘缚,同理類推勾笆。

那么以上這些數(shù)據(jù)是怎么統(tǒng)計得到的呢,這時候就要引入framestat了桥滨,framestat其實是每一個frame的相信信息窝爪,記錄這不同階段下的時間戳。也就是更精準(zhǔn)的幀的時間戳信息齐媒。

精確的幀時間信息

在Android 6.0以后為gfxinfo 提供了一個新的參數(shù)framestats酸舍,其作用可以從最近的幀中提供非常詳細(xì)的幀信息,以便您可以更準(zhǔn)確地跟蹤和調(diào)試問題里初。

> adb shell dumpsys gfxinfo < PACKAGE_NAME > framestats

此命令將應(yīng)用程序生成的最后120幀信息打印出啃勉,其中包含納秒時間戳。以下是來自adb dumpsys gfxinfo <PACKAGE_NAME>的示例原始輸出framestats:

0 双妨,27965466202353 淮阐,27965466202353 叮阅,27965449758000 ,27965461202353 泣特,27965467153286 浩姥,27965471442505 ,27965471925682 状您,27965474025318 勒叠,27965474588547 ,27965474860786 膏孟,27965475078599 眯分,27965479796151 ,27965480589068 柒桑,0 弊决,27965482993342 ,27965482993342 魁淳,27965465835000 飘诗,27965477993342 ,27965483807401 界逛,27965486875630 昆稿,
27965487288443 ,27965489520682 息拜,27965490184380 溉潭,27965490568703 ,27965491408078 该溯,27965496119641 岛抄,27965496619641 ,0 狈茉,27965499784331 夫椭,27965499784331 ,27965481404000 氯庆,27965494784331 蹭秋,27965500785318 ,27965503736099 堤撵,27965504201151 仁讨,27965506776568 ,27965507298443 实昨,27965507515005 洞豁,27965508405474 ,27965513495318 ,27965514061984 丈挟,

0,27965516575320,27965516575320,27965497155000,27965511575320,27965517697349,27965521276151,27965521734797,27965524350474,27965524884536,27965525160578,27965526020891,27965531371203,27965532114484,

此輸出的每一行代表應(yīng)用程序生成的一幀刁卜。每一行的列數(shù)都相同,每列對應(yīng)描述幀在不同的時間段的耗時情況曙咽。下一節(jié)將詳細(xì)介紹這種格式蛔趴,包括每列代表的內(nèi)容。

Framestats數(shù)據(jù)格式

由于數(shù)據(jù)塊以CSV格式輸出例朱,因此將其粘貼到您選擇的電子表格工具中非常簡單孝情,或者通過腳本進(jìn)行收集和分析。下表說明了輸出數(shù)據(jù)列的格式洒嗤。所有的時間戳都是納秒箫荡。

  • FLAGS

    • FLAGS列為'0'的行可以通過從FRAME_COMPLETED列中減去INTENDED_VSYNC列計算其總幀時間。
    • 如果非零烁竭,則該行應(yīng)該被忽略菲茬,因為該幀的預(yù)期布局和繪制時間超過16ms吉挣,為異常幀派撕。
  • INTENDED_VSYNC

    • 幀的的預(yù)期起點。如果此值與VSYNC不同睬魂,是由于 UI 線程中的工作使其無法及時響應(yīng)垂直同步信號所造成的终吼。
  • VSYNC

    • 花費在vsync監(jiān)聽器和幀繪制的時間(Choreographer frame回調(diào),動畫氯哮,View.getDrawingTime()等)
    • 要了解有關(guān)VSYNC的更多信息以及它如何影響應(yīng)用程序际跪,請查看 Understanding VSYNC視頻。
  • OLDEST_INPUT_EVENT

    • 輸入隊列中最舊輸入事件的時間戳喉钢,如果沒有輸入事件姆打,則輸入Long.MAX_VALUE。
    • 此值主要用于平臺工作肠虽,對應(yīng)用程序開發(fā)人員的用處有限幔戏。
  • NEWEST_INPUT_EVENT

    • 輸入隊列中最新輸入事件的時間戳,如果幀沒有輸入事件税课,則為0闲延。
    • 此值主要用于平臺工作,對應(yīng)用程序開發(fā)人員的用處有限韩玩。
    • 然而垒玲,通過查看(FRAME_COMPLETED - NEWEST_INPUT_EVENT),可以大致了解應(yīng)用程序添加的延遲時間找颓。
  • HANDLE_INPUT_START

    • 將輸入事件分派給應(yīng)用程序的時間戳合愈。
    • 通過查看這段時間和ANIMATION_START之間的時間,可以測量應(yīng)用程序處理輸入事件的時間。
    • 如果這個數(shù)字很高(> 2ms)佛析,這表明程序花費了非常長的時間來處理輸入事件妇汗,例如View.onTouchEvent(),也就是說此工作需要優(yōu)化说莫,或者分發(fā)到不同的線程杨箭。請注意,某些情況下這是可以接受的储狭,例如發(fā)起新活動或類似活動的點擊事件互婿,并且此數(shù)字很大。
  • ANIMATION_START

    • 運(yùn)行Choreographer注冊動畫的時間戳辽狈。
    • 通過查看這段時間和PERFORM_TRANVERSALS_START之間的時間慈参,可以確定評估運(yùn)行的所有動畫器(ObjectAnimator,ViewPropertyAnimator和常用轉(zhuǎn)換器)需要多長時間刮萌。
    • 如果此數(shù)字很高(> 2ms)驮配,請檢查您的應(yīng)用是否編寫了自定義動畫以確保它們適用于動畫。
    • 要詳細(xì)了解Choreographer着茸,請查看For Butter or Worse 視頻壮锻。
  • PERFORM_TRAVERSALS_START

    • PERFORM_TRAVERSALS_STAR-DRAW_START,則可以提取布局和度量階段完成的時間涮阔。(注意猜绣,在滾動或動畫期間,你會希望這應(yīng)該接近于零..)
    • 要詳細(xì)了解渲染管道的度量和布局階段敬特,請查看 Invalidations掰邢,Layouts和Performance視頻
  • DRAW_START

    • performTraversals的繪制階段開始的時間。這是錄制任何無效視圖的顯示列表的起點伟阔。
    • 這和SYNC_START之間的時間是在樹中所有無效視圖上調(diào)用View.draw()所花費的時間辣之。
    • 有關(guān)繪圖模型的更多信息,請參閱硬件加速 失效皱炉,布局和性能視頻
  • SYNC_QUEUED

    • 同步請求發(fā)送到RenderThread的時間怀估。
    • 這標(biāo)志著開始同步階段的消息被發(fā)送到RenderThread的時刻。如果此時間和SYNC_START之間的時間很長(> 0.1ms左右)娃承,則意味著RenderThread忙于處理不同的幀奏夫。在內(nèi)部,這被用來區(qū)分幀做了太多的工作历筝,超過了16ms的預(yù)算酗昼,由于前一幀超過了16ms的預(yù)算,幀被停止了梳猪。
  • SYNC_START

    • 繪圖的同步階段開始的時間麻削。
    • 如果此時間與ISSUE_DRAW_COMMANDS_START之間的時間很長(> 0.4ms左右)蒸痹,則通常表示有許多新的位圖必須上傳到GPU。
    • 要了解有關(guān)同步階段的更多信息呛哟,請查看 Profile GPU Rendering視頻
  • ISSUE_DRAW_COMMANDS_START

    • 硬件渲染器開始向GPU發(fā)出繪圖命令的時間叠荠。
    • 這段時間和FRAME_COMPLETED之間的時間間隔顯示了應(yīng)用程序正在生產(chǎn)多少GPU。像這樣出現(xiàn)太多透支或低效率渲染效果的問題扫责。
  • SWAP_BUFFERS

    • eglSwapBuffers被調(diào)用的時間榛鼎。
  • FRAME_COMPLETED

    • 幀的完整時間”罟拢花在這個幀上的總時間可以通過FRAME_COMPLETED - INTENDED_VSYNC來計算者娱。

你可以用不同的方式使用這些數(shù)據(jù)。例如下面的直方圖苏揣,顯示不同幀時間的分布(FRAME_COMPLETED - INTENDED_VSYNC)黄鳍,如下圖所示。

1.PNG

這張圖一目了然地告訴我們平匈,大多數(shù)的幀耗時都遠(yuǎn)低于16ms(用紅色表示)框沟,但幾幀明顯超過了16ms。隨著時間的推移增炭,我們可以查看此直方圖中的變化忍燥,以查看批量變化或新創(chuàng)建的異常值。您還可以根據(jù)數(shù)據(jù)中的許多時間戳來繪制出輸入延遲弟跑,布局花費的時間或其他類似的感興趣度量灾前。

幀耗時數(shù)據(jù)的 獲取

如果在開發(fā)者選項中的CPU呈現(xiàn)模式分析中選擇adb shell dumpsys gfxinfo防症,則adb shell dumpsys gfxinfo命令將輸出最近120幀的時間信息孟辑,并將其分成幾個不同的類別,可以直觀的顯示各部分的快慢蔫敲。

與上面的framestats類似饲嗽,將它粘貼到您選擇的電子表格工具中非常簡單,或者通過腳本進(jìn)行收集和解析奈嘿。下圖顯示了應(yīng)用程序生成的幀每個階段的詳細(xì)耗時貌虾。

2.PNG

運(yùn)行g(shù)fxinfo,復(fù)制輸出裙犹,將其粘貼到電子表格應(yīng)用程序中尽狠,并將數(shù)據(jù)繪制為直方圖的結(jié)果。

每個垂直條代表一幀動畫; 其高度表示計算該動畫幀所用的毫秒數(shù)叶圃。條形圖中的每個彩色段表示渲染管道的不同階段袄膏,以便您可以看到應(yīng)用程序的哪些部分可能會造成瓶頸。有關(guān)了解渲染管道的詳細(xì)信息以及如何優(yōu)化渲染管道掺冠,請參閱 Invalidations Layouts和Performance視頻沉馆。

關(guān)于如何控制framestats的搜集

framestats信息和frame耗時信息通常為2s收集一次(一次120幀,一幀16ms,耗時約2s)斥黑。為了精確控制時間窗口揖盘,例如,將數(shù)據(jù)限制為特定的動畫 锌奴,您可以重置所有計數(shù)器兽狭,并重新收集的數(shù)據(jù)。

> adb shell dumpsys gfxinfo < PACKAGE_NAME > reset

同樣 也適用于需要捕獲小于2s的數(shù)據(jù)鹿蜀。

診斷性能

dumpsys是能發(fā)現(xiàn)問題或者判斷問題的嚴(yán)重性椭符,但無法定位真正的原因。如果要定位原因耻姥,應(yīng)當(dāng)配合systrace工具使用销钝,請參照systrace工具。

其他資源

有關(guān)Android渲染管道如何工作的更多信息琐簇,您可以在其中找到的常見問題以及如何解決這些問題蒸健,以下某些資源可能對您有用:

自動化UI性能測試


用戶界面性能測試的一種方法是簡單地讓人工測試人員在目標(biāo)應(yīng)用上執(zhí)行一組用戶操作,并且可以直觀地查找是否出現(xiàn)問題丈秩,或者使用工具驅(qū)動方法花費大量時間來查找它盯捌。但是這種手動方法充滿了危險 - 人類感知幀速率變化的能力差別很大,這也是耗時蘑秽,乏味和容易出錯的饺著。

更有效的方法是從自動UI測試中記錄和分析關(guān)鍵性能指標(biāo)。Android 6.0包含新的日志記錄功能肠牲,可以輕松確定應(yīng)用程序動畫中jank的數(shù)量和嚴(yán)重程度幼衰,并可用于構(gòu)建嚴(yán)格的流程以確定當(dāng)前的性能并跟蹤未來的性能目標(biāo)。

要了解有關(guān)Android性能測試的更多信息缀雳,請參閱 自動化性能測試代碼實驗室渡嚣。在此代碼中,您將學(xué)習(xí)如何編寫和執(zhí)行自動化測試肥印,并查看結(jié)果以了解如何提高應(yīng)用性能识椰。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市深碱,隨后出現(xiàn)的幾起案子腹鹉,更是在濱河造成了極大的恐慌,老刑警劉巖莹痢,帶你破解...
    沈念sama閱讀 216,544評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件种蘸,死亡現(xiàn)場離奇詭異墓赴,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī)航瞭,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,430評論 3 392
  • 文/潘曉璐 我一進(jìn)店門诫硕,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人刊侯,你說我怎么就攤上這事章办。” “怎么了滨彻?”我有些...
    開封第一講書人閱讀 162,764評論 0 353
  • 文/不壞的土叔 我叫張陵藕届,是天一觀的道長。 經(jīng)常有香客問我亭饵,道長休偶,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 58,193評論 1 292
  • 正文 為了忘掉前任辜羊,我火速辦了婚禮踏兜,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘八秃。我一直安慰自己碱妆,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 67,216評論 6 388
  • 文/花漫 我一把揭開白布昔驱。 她就那樣靜靜地躺著疹尾,像睡著了一般。 火紅的嫁衣襯著肌膚如雪骤肛。 梳的紋絲不亂的頭發(fā)上纳本,一...
    開封第一講書人閱讀 51,182評論 1 299
  • 那天,我揣著相機(jī)與錄音萌衬,去河邊找鬼饮醇。 笑死,一個胖子當(dāng)著我的面吹牛秕豫,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播观蓄,決...
    沈念sama閱讀 40,063評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼混移,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了侮穿?” 一聲冷哼從身側(cè)響起歌径,我...
    開封第一講書人閱讀 38,917評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎亲茅,沒想到半個月后回铛,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體狗准,經(jīng)...
    沈念sama閱讀 45,329評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,543評論 2 332
  • 正文 我和宋清朗相戀三年茵肃,在試婚紗的時候發(fā)現(xiàn)自己被綠了腔长。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,722評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡验残,死狀恐怖捞附,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情您没,我是刑警寧澤鸟召,帶...
    沈念sama閱讀 35,425評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站氨鹏,受9級特大地震影響欧募,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜仆抵,卻給世界環(huán)境...
    茶點故事閱讀 41,019評論 3 326
  • 文/蒙蒙 一槽片、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧肢础,春花似錦还栓、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,671評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至慨蛙,卻和暖如春辽聊,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背期贫。 一陣腳步聲響...
    開封第一講書人閱讀 32,825評論 1 269
  • 我被黑心中介騙來泰國打工跟匆, 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人通砍。 一個月前我還...
    沈念sama閱讀 47,729評論 2 368
  • 正文 我出身青樓玛臂,卻偏偏與公主長得像,于是被迫代替她去往敵國和親封孙。 傳聞我的和親對象是個殘疾皇子迹冤,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,614評論 2 353

推薦閱讀更多精彩內(nèi)容