性能调试工具及其滑动丢帧案例分享

HarmonyOS

netos

2024-06-13 11:00:36

浏览

回答 1

待解决

回答 1

按赞同

按时间

小小肉蟹

（一）性能调试工具：

.deveco-studio-4.0.1.11.win
脚本抓trace，网站解析trace分析性能
avidemux

1. deveco-studio-4.0.1.11.win工具的使用：即用该IDE出的包，安装在单框架设备上，就可以快照查看性能耗时方式和代码位置。

1.1 下载IDE工具解压到本地（如D:\Tools\deveco-studio-4.0.1.200.win）：

1.2 双击devecostudio64.exe运行IDE：注意首次启动，需要配置node（node安装路径不能为空，推荐14.19.1版本）和ohpm（需要下载配置，但可以不用），本地没有的需要install下载。

1.3 IDE里面配置sdk路径（项目仍然是3.2.10.10版本）和local.properties配置。

1.4 用IDE打开单框架应用市场项目，初始化依赖，签名配置相关等以保证能正常编译打包。之后通过IDE出一个本地编译的包，安装到最新手机rom上（如rom33+）。

1.5 打开IDE底部的Insight菜单（打开后的窗口支持拖拽与IDE窗口分离）。

1.6 注意IDE右上角的设备，必须连上显示正确的手机设备型号。

1.7 点击开始快照，等到出现recording之后，开始操作手机上的单框架应用市场界面，之后停止快照。

2.脚本抓trace，网站解析trace分析性能

2.1 创建个getTrace.bat脚本，用以抓测试设备操作一段时间生成的tarce。bytrace -t 10 表示抓10s操作测试设备过程的tarce。

set ymd=%date:~0,4%%date:~5,2%%date:~8,2% 
for /f "tokens=* delims= " %%a in ("%ymd%") do set ymd=%%a 
set hms=%time:~0,2%%time:~3,2%%time:~6,2% 
for /f "tokens=* delims= " %%a in ("%hms%") do set hms=%%a 
set filename=mynewtrace_%ymd%_%hms%.ftrace 
  
hdc shell mount -o remount,rw / 
hdc shell "rm -rf /data/log/%filename%" 
hdc shell "echo 1 > /sys/kernel/tracing/events/sched/sched_qos/enable" 
::hdc shell "bytrace -t 30 -b 20480 --overwrite ace app ohos ability graphic sched freq irq sync workq pagecache binder multimodalinput zimage zmedia zcamera zaudio > /data/mynewtrace.ftrace" 
hdc shell "bytrace -t 10 -b 20480 --overwrite ability ace app ark binder disk distributeddatamgr dsoftbus freq graphic i2c idle irq mdfs memreclaim misc mmc msdp multimodalinput notification ohos pagecache regulators sched sensors sync ufs window workq zaudio zcamera zimage zmedia > /data/log/%filename%" 
hdc shell "echo 0 > /sys/kernel/tracing/events/sched/sched_qos/enable" 
hdc shell "sed -i '1,2d' /data/log/%filename%"" 
hdc file recv /data/log/%filename% . 
pause

2.2 双击允许getTrace.bat脚本，然后操作usb连接电脑的测试设备手机（如应用市场启动流程），10s后，就可以在和getTrace.bat脚本同级目录下生成一个trace文件。

2.3 通过网址，去打开和getTrace.bat脚本同级目录下生成的一个trace文件，然后解析即可

3.avidemux：用以针对应用操作界面录屏，逐帧查看渲染画面，以及查看每一帧的实际耗时。

· 3.1 下载avidemux：见附件。

· 3.2 使用：见下截图。

（二）来回上下快速滑动卡顿案例：

1.基于deveco-studio-4.0.1.11.win工具的快照分析。

（二）来回上下快速滑动卡顿案例：
1.基于deveco-studio-4.0.1.11.win工具的快照分析。

2. 操作分析快照步骤流程：

2.1 手机启动应用市场。

2.2 启动deveco-studio-4.0.1.11.win工具的Insight，选择手机设备和应用市场进程。

2.3 来回上下快速滑动应用市场首页，查看deveco-studio-4.0.1.11.win工具的FPS帧率。如下截图显示：

2.3.1 现象描述：

a. 在应用市场顶部快速来回下滑（或触底底部快速来回上滑）时，帧率在55+（接近满级60帧）。

b. 在应用市场中间部分快速来回上下滑动时，帧率在2~25帧，远低于满级60帧，体验明显感觉到卡顿。（删除hilog和客户端自身日志文件写入，可以达到45+帧左右）。

2.4 接下来重点用Frame快照分析2.3.1现象描述中的b现象：分析不同甬道，逐帧逐帧查看，存在异常帧（红色为异常卡顿帧，绿色为正常帧）就挑出来分析导致异常帧渲染超时的原因。

2.4.1 对于我们应用端来说，主要考虑App Frame甬道（先收藏）的帧情况和ArkTS Callstack甬道里面的ArkTS/JS的函数调用数据情况，其中绿色帧是正常，红色帧则异常，只需要分析红色异常帧。通过ctrl+鼠标滚动查看App Frame甬道，发现总共有196帧快照，其中在第【17，46，47，52,53，57,58，67,68，73,74，79,80,81，82,85，86，87，88,89，91,92,93，94，100,101，102,103，112,113，119，120，123,124,125,126，127,128,129，135,136，139,140,141，142，151,152,153，156,157，163,164,165，166，179,180，196】帧是红色，是异常帧。

选中App Frame甬道的第17帧（红色异常帧），查看该帧下ArkTS Callstack甬道里面ArkTS/JS的函数调用数据情况。

通过对App Frame甬道的所有红色异常帧的ArkTS Callstack甬道里面ArkTS/JS的函数调用数据情况，进行分析，结果汇总大概有如下几类：

a. 存在高频触发DownloadButton.ets\DownloadImage.ets组件中log日志的打印，写入文件，判断文件情况。所以对于应用市场首页高频使用的NormalCard卡片（里面相关组件）里面需要减少日志。【占比最重】。

b.组件代码布局不规范（如简单卡片，复杂布局，特别是flex会导致渲染计算更长）。

b1. 通过组件树查找客户端NormalCard卡的布局是否合理：如下分析组件树

1. hdc shell 
2. param set persist.ace.debug.enabled 1 
3. 重启手机，启动应用市场 
4. hdc shell 
5. aa dump -a 
6. uitest dumpLayout //生成应用市场的组件树的json文件， /data/local/tmp/layout_142600597.json 
7. 将/data/local/tmp/layout_142600597.json拷贝到电脑，搜索type=ListItem，并查找其下的children里

面的布局结构：