往期推文全新看点
- 鸿蒙(HarmonyOS)北向开发知识点记录~
- 鸿蒙(OpenHarmony)南向开发保姆级知识点汇总~
- 鸿蒙应用开发与鸿蒙系统开发哪个更有前景?
- 嵌入式开发适不适合做鸿蒙南向开发?看完这篇你就了解了~
- 对于大前端开发来说,转鸿蒙开发究竟是福还是祸?
- 鸿蒙岗位需求突增!移动端、PC端、IoT到底该怎么选?
- 记录一场鸿蒙开发岗位面试经历~
- 持续更新中……
概述
响应(Response)是指应用在运行中,由用户直接或间接做出一个行为请求,当程序接受了该请求,随即做出一系列运算,最终界面发生变化的过程。简单来说,即用户发出指令,程序执行,设备显示变化。
在应用生态高速发展的背景下,虽然移动设备的硬件运算性能已经达到了新的高度,但与此同时应用研发者也设计出更加多元化、智能化的产品,展现样式百花齐放,这些产品对高性能的需求与日俱增,加上同类型相近功能的产品互相竞争,用户也会对App产品质量的要求越来越高,对响应速度的要求也愈加严格。
《应用性能体验建议》 指出,应用或元服务内点击操作响应时延应<=100ms。为了保障应用操作响应及时,看护用户极致流畅体验,开发者需要分析从手势抬手到渲染上屏这段时间应用做了哪些耗时的操作,进而针对性地优化相关逻辑。
图1点击响应起止点示意图
点击响应优化就是指通过分析响应阶段、优化应用性能、加快点击后页面的响应速度,使用户可以得到流畅的操作体验。开发者优化自己应用的点击响应速度,既满足产品功能的高性能要求,增强产品同质化竞争中的优势,又能不断提升用户满意度。
仔细观察响应过程中涉及的内容,可以发现优化的目标集中在:UI界面、视觉动效、指令逻辑等。本文将围绕这些元素,结合平台的相关特性,介绍点击响应优化的具体方法:
- UI优化:从UI布局渲染角度,加快应用绘制性能,比如减少布局嵌套,减少元素渲染,缓存UI动效等。
- 按需加载优化:根据界面展示或模块加载的需要,延迟加载相关内容,从而减少对首帧页面的性能消耗。
- 并发优化:使用系统并发执行多个任务的能力,减少响应过程中任务执行的整体时间。
- IPC通信优化:针对IPC通信特点,尽量减少不必要的通信次数和数据体积,防止IPC通道影响界面响应。
- 代码逻辑优化:在相关生命周期中减少冗余、降低耗时,提升执行效率,包括善用数据结构、缓存、优化调整时序等。
- 视觉感知优化:通过交互设计的优化,利用动效动画的形式,在视觉层面提升用户响应速度的感知。
分析工具
影响点击响应性能的因素有很多,借助DevEco Studio集成的相关分析工具,可以收集大量的系统数据,自动执行重复任务,建立统一的优化标准和流程,减少个人差异和误操作的可能性,帮助开发人员更好地了解性能瓶颈和优化潜力。在分析优化的过程中,可能用到以下工具中的一个或多个。
AppAnalyzer
AppAnalyzer是DevEco Studio中提供的检测评分工具,用于测试并评价HarmonyOS应用或元服务的质量,能快速提供评估结果和改进建议,当前支持的测试类型包括兼容性、性能、UX测试和最佳实践等,其中点击操作响应是性能类型中的一项检测规则,开发者可以使用该工具检测响应性能。
使用AppAnalyzer检测点击响应
- 启动DevEco Studio,连接设备,打开应用,然后依次执行以下操作。
- 单击菜单栏Tools > AppAnalyzer。
- 在AppAnalyzer页面Module选择框选择应用/服务工程模块。
- 根据应用的类别选择Category。
- 选择Rules,可以先点击Custom,再勾选”Quick Response To In-app Clicks”,即勾选”应用内点击操作响应快”评测规则。
- 点击Start启动检测,检测过程中,手机需要保持解锁亮屏状态。
- 获得检测结果。例如下图结果,表示点击响应性能检测失败,说明评测应用达不到100ms响应标准,存在进一步优化的空间。
Profiler Frame
Profiler 是DevEco Studio提供的场景化调优工具,其中Frame可以帮助开发者深度分析性能问题,通过录制应用运行过程中的关键数据,从而识别卡顿丢帧、耗时长等问题的原因所在。
使用Frame分析响应性能
- 抓取操作trace:启动DevEco Studio,连接设备,打开应用,然后依次执行以下操作。
- 启动Profiler。
- 选择应用、包名、进程。
- 选择Frame工具。
- 操作到指定页面,点击Create Session 创建一个Frame 模板。
- 点击Frame模板框中的播放按钮开始录制,操作应用界面点击响应,完成操作之后点击结束录制。
- 确认响应起点和终点:
- 根据点击响应的初始位置,找到手势抬起的那一帧,设置为分析起点,对应mmi-service泳道中H:service report的type为up的事件。
- 找到页面变化后的第一帧,设定为分析的终点,对应RSHardwareThread泳道的CommitAndReleaseLayers结束点。
- 分解时间段:点击响应的整体时延拆解后,主要分为三个阶段:输入阶段,应用阶段,渲染阶段。
首帧响应时延 | 起点 | 终点 | 基线(ms) |
---|---|---|---|
输入阶段 | mmi_service对应的service report(type为up) | 应用DispatchTouchEvent的起点(type=1) | 8 |
应用阶段 | 应用DispatchTouchEvent的起点(type=1) | 页面首次发生变化帧对应的H:FlushMessage结束点 | 25 |
渲染阶段 | 对应的RS帧ProcessCommandUni起点 | 对应的RSHardwareThread::CommitAndReleaseLayers的结束点 | 20 |
其中,应用阶段(如下图中标记2与3之间的部分)是开发者需要关注优化的部分,一般来说,应用阶段耗时若超过25ms的基线,加上机器硬件的30ms左右耗时,整体的时延就可能超过100ms的标准,导致点击响应体验不佳,需要进一步定位性能问题。
- 分析定位原因:针对框选的应用阶段,分析主进程泳道,观察是否有耗时长的函数阻塞主线程;是否有超长耗时单帧。如果有长段的ExecuteJs 可以查看具体的调用栈或火焰图,定位耗时函数;如果是FlushLayoutTask阶段耗时,就需要结合UI组件树去分析,布局是否合理,是否有优化空间。