【最佳实践】Web页面内点击响应时延分析(一)
下图为在ArkTS侧使用Web组件加载Web页面时的效果,当用户点击字块后,经过较长延迟才触发动画效果。点击操作响应时延性能指标衡量的起点为用户点击应用元素时间,终点为应用界面开始发生变化的时间,从起点到终点的变化时间,应控制在100ms以内。保障应用内操作响应及时,维护用户极致流畅体验。开发者可以通过录屏辅助测试,通过录屏分析工具来量化点击响应时延的大小,进而判断是否存在需要优化的时延类问题。
图1 场景动画

问题定位流程
Web网页整体加载流程与关键Trace点
图2 Web网页整体加载泳道图

|
Web网页加载流程拆解 |
关键Trace |
|---|---|
|
点击事件 |
最后一个DispatchTouchEvent到组件初始化前 |
|
Web组件初始化 |
NWebImpl|CreateNWeb到导航流程前 |
|
导航流程 |
NavigationControllorImpl::LoadURLWithParams到NavigationBodyLoader::OnStartLoadingResponseBody结束 |
|
DOM&CSS解析 |
CSSParserImpl::parseStyleShee和ParseHTML解析,扣除HTMLDocumentParser::RunScriptsForPausedTreeBuilder |
|
JS编译+执行 |
EvaluateScript 和 v8.callFunction |
|
等待网络资源下载 |
render主线程ThrottlingURLLoader::OnReceiveResponse前的空闲 |
|
点击响应结束点 |
NotifyFrameSwapped,UnloadOldFrame/第一个SkiaOutputSurfaceImplOnGpu::SwapBuffers |
|
绘制 |
ThreadProxy::BeginMaiFrame扣除v8执行 |
|
光栅化&合成 |
从ProxyImpl::NotifyReadyToCommitOnImpl开始到SwapBuffers结束 |
|
完成时延结束 |
最后一个SkiaOutputSurfaceImplOnGpu::SwapBuffers |
使用Profiler工具抓取Trace
Profiler工具分析卡顿丢帧场景的使用方式可以参考Frame分析。响应时延类问题首先确认响应起止点,确定区域位置与大致操作。
- 确认起点:如果为点击触发,则首先找到应用侧的DispatchTouchEvent,如下图虚线所示:图3 Trace起点

- 确认终点:此处之所以选择已经连续稳定地发出vsync信号的第一帧vsync信号作为终点,而不是取其中不稳定vsync信号作为终点,是由于非连续的vsync信号,不一定导致了界面上的渲染行为,而本文要分析从应用元素点击到应用界面开始发生变化这一段区域内存在的点击时延问题,所以选择了连续稳定渲染的第一帧vsync信号作为终点。图4 Trace终点

可以发现,后续动画已经达到最大帧率,说明无响应是图中区域内。
- 分析中途出现的H:ReceiveVsync信号可以发现,在无响应阶段出现过几帧,但是每帧的耗时并没有过大。应用侧也如此,说明在UI绘制过程并没有高负载。图5 Trace帧率分析

- 同时可以发现在此过程中,应用长时间占用CPU,可能的原因是产生了大量的计算。
图6 可能耗时原因

经过前面的分析,应用侧发现可能是Web侧产生了大量的计算,此时需要使用Devtools工具进一步分析。
使用Devtools进行分析
Devtools调试使用请参考此链接:使用Devtools工具调试前端页面。
抓取的DevTools泳道图如下图所示,本章节将可能发生的异常区域进行分析:
图7 DevTools泳道图区域划分

- 区域1: 该处为起点,输入Event搜索点击事件。
- 区域2:该处为组件加载区域,主要是JS执行。
- 区域3:该处为响应终点,Frame泳道第一帧送显。
- 区域4:该区域为动画区域,负责执行动画。
- 区域5:该区域为空白区域,一般是由于setTimeout等延迟函数引起。。
由于此页面不涉及网络交互,所以还有部分区域如网络区域等没有标记,后面也会给出示例。
更多推荐



所有评论(0)