应用跳转歌曲播放页转场卡顿性能优化工具使用案例

• 场景导入
• 目标规则
• 使用性能检测工具检测性能问题
• 使用性能分析工具进一步分析性能问题根因
• 优化方案及优化收益

场景导入

某应用首页点击最下方播放圆盘跳转到歌曲播放页用肉眼观测有明显的抖动卡顿。如果不通过性能工具集进行分析，开发者需要：1、复现问题；2、抓取trace；3、分析trace找出丢帧问题点。操作步骤多，耗时较长。

本场景通过采用静态检查工具进行问题发现、定位及修改。

目标规则

Code Linter目标检测规则：

转场卡顿相关的检测规则，推荐@performance/hp-arkui-suggest-use-effectkit-blur，建议使用effectKit.createEffect实现模糊效果，通用丢帧场景下，建议优先修改：@performance/hp-arkui-suggest-use-effectkit-blur。

使用性能检测工具检测性能问题

使用Code Linter检测性能问题

已打开的代码编辑器窗口单击右键点击Code Linter，或在工程管理窗口中鼠标选中单个或多个工程文件/目录，右键选择Code Linter \> Full Linter执行代码全量检查，参考指导：代码Code Linter检查。

将扫描结果导出，在RuleName列过滤hp-arkui-suggest-use-effectkit-blur，找到对应的源文件。

通过“Source File”列可以看到具体的页面文件，确定扫描出来的文件均是歌曲播放页相关的代码文件。

通过查看具体的代码分析发现：

1）应用的背景网络图片资源获取到之前会对默认本地背景图做模糊处理；

2）网络图片资源获取到之后会重新再做一次模糊处理。当前对于背景图模糊的实现方式是采用一张全屏的Image通过blur属性来实现实时模糊处理，这样每次送显前都会重新创建纹理，不适用于大图资源模糊处理。

使用性能分析工具进一步分析性能问题根因

为了进一步确认导致页面转场出现抖动的原因，通过profiler打开应用体检结果提供的trace分析，可以看出在高刷新率（120Hz）的情况下，页面转场的过程中，系统图形渲染进程一帧耗时达到了11.5ms，这就会出现页面抖动。主要耗时在H:onCreateTexture函数，耗时占比超过了60%，引起该函数耗时长的原因正是因为模糊处理导致，因此确认code linter扫描结果就是页面转场抖动的直接原因。

优化方案及优化收益

根据code linter扫描结果中提供的赋能套件链接跳转到使用effectKit.createEffect实现模糊效果的指导：代码Code Linter检查，结合应用代码逻辑采用了3点优化方案：

1. 单个歌曲ListItem内两次模糊处理降为一次，用来占位的模糊背景图直接引用事先处理好的UX图。
2. 获取到网络背景图后，采用effectKit来实现模糊效果。
3. 只在可视区做模糊处理，非可视区不做模糊处理。

优化后RSUniRenderThread处理耗时平均在5ms以下，转场过程中无丢帧，无页面抖动，达到S标，且优化前和优化后的内存占用没有差异。