FAQ06306]如何使用Ftrace初步分析界面卡顿问题

【Discription】

当遇到手机launch界面滑动卡顿问题，在JB2的版本上需要使用到Ftrace对各个进程进行初步分析。下面简单介绍下如何使用Ftrace，以及初步分析用Ftrace生成的trace.html文件，初步判断哪个地方当出现卡顿的时候哪个进程比较耗时已经耗时的函数。

 

【Analysis】

需要确保手机在user mode下进行录取，因为eng版本的话log太多，本身就会造成一些卡顿情况，确认手机是否是user mode还是eng mode是可以通过以下命令进行查阅：

adb shell getprop  ro.build.type 

或是

adb shell

cat /proc/bootprof

 

 

如何在user load上如何开启ftrace，请查看MediaTek On-Line上面的FAQ07827

可以使用谷歌原生的Ftrace分析软件。按照以下步骤进行：

1. 在KK之前的版本，打开手机 “设置” -- “开发者选项” -- “应用跟踪”，勾选上全部或是相关进程选项。KK的版本下面会介绍。

2.双击打开ftrace_all_in_one里面的01-catch.bat，按照提示按任意键开始，然后开始模拟你认为卡顿的操作，但卡顿发生之后，按照提示按任意键结束，待01-catch.bat运行完后自动会退出。

3.双击打开02-parse.bat，结束后会自动生成trace.html

4.上传trace.html 给mtk分析或是自行进行初步分析

PS: 如果是KK版本，由于没有“设置” -- “开发者选项” -- “应用跟踪”，所以按照如下表格

 

 

 

如果要打开               am + wm + graphics + view + input + hwui  这个几个选项

对应上面的表格 1000000 | 100000 | 10 | 1000 | 100 |  100000000000 = 0x86E

需要使用如下命令：

adb shell setprop debug.atrace.tags.enableflags 0x86E

adb shell stop
adb shell start

下面是对一个简单例子（某公司自行开发新增场景桌面的功能应用卡的问题）的分析，手上拿到了发生卡顿时候的trace.html,通过谷歌的开发的chrome软件打开后.如下所示:

 

从以上分析可以得出,在1s到2s之内触发surfaceflinger进行图片叠加的次数比较少,但是surfaceflinger执行的时间比较快,不是造成卡顿的原因,而追查下去发现应用sencetechnology所使用的draw时间相对较长时间，一次draw的时间都超过了150ms，属于draw时间慢导致的卡顿。

【solution】

通过以上trace.html 可以得知，当前卡顿发生的原因需要追查为何上层应用draw一个frame需要花超过150ms的时间，通过进一步分析得知draw慢的原因是因为该应用使用了非常多而且非常大size图片导致。