鸿蒙NEXT开发【Web页面内点击响应时延分析】性能分析

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

图1 场景动画

问题定位流程

Web网页整体加载流程与关键Trace点

图2 Web网页整体加载泳道图

Web网页加载流程拆解	关键Trace
点击事件	最后一个DispatchTouchEvent到组件初始化前
Web组件初始化	NWebImpl
导航流程	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

响应时延类问题首先确认响应起止点，确定区域位置与大致操作。

1. 确认起点：如果为点击触发，则首先先找到应用侧的DispatchTouchEvent，如下图虚线所示：

   图3 Trace起点

   

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

   图4 Trace终点

   

   可以发现，后续动画已经达到最大帧率，说明无响应是图中区域内。

3. 分析中途出现的H:ReceiveVsync信号可以发现，在无响应阶段出现过几帧，但是每帧的耗时并没有过大。应用侧也如此，说明在UI绘制过程并没有高负载。

   图5 Trace帧率分析

   

4. 同时可以发现在此过程中，应用长时间占用CPU，可能的原因是产生了大量的计算。

   图6 可能耗时原因

   

经过前面的分析，应用侧发现可能是Web侧产生了大量的计算，此时需要使用Devtools工具进一步分析。

使用Devtools进行分析

抓取的DevTools泳道图如下图所示，本章节将可能发生的异常区域进行分析：

图7 DevTools泳道图区域划分

• 区域1: 该处为起点，输入Event搜索点击事件
• 区域2：该处为组件加载区域，主要是JS执行
• 区域3：该处为响应终点，Frame泳道第一帧送显
• 区域4：该区域为动画区域，负责执行动画
• 区域5：该区域为空白区域，一般是由于setTimeout等延迟函数引起

由于此页面不涉及网络交互，所以还有部分区域如网络区域等没有标记，后面也会给出示例。

常见问题分析实例

H5页面点击切换场景下，此时Web组件已经初始化，点击事件为Web内部的Event，场景过程主要发生在下图的1234的区域。

图8 DevTools泳道图区域划分

当点击时会执行以下流程：

1. Web导航等待主页面渲染出第一个非空白帧
2. 主页面中的主资源下载之后主资源解析渲染，之后子资源下载与子资源解析渲染交错进行
3. 主资源渲染完成，若为非空白帧，唤起导航动画，页面响应
4. 主资源渲染完成，若为空白帧，Web会丢弃，后续子资源渲染出的第一个非空白帧，唤起导航动画，页面响应

按照经验大部分响应慢是存在以下原因：

1. 主资源渲染组件结构复杂耗时高
2. 主资源空白，子资源动态加载，第一帧显示慢

本文将从组件加载区域异常、网络区域异常、动画区域异常、空白区域异常分别进行介绍。

组件加载区域异常分析

对应下图中的区域2：可以记录此段内容的加载耗时。

图9 DevTools泳道图区域划分

此处异常点通常为：

1. 区域耗时长占比高，比如区域2耗时290ms左右，是一个优化点
2. 有几段区域都是在加载渲染组件，此时可能是动态加载组件，通常时延会高，同时可以看到出现了大量调用的myFun1，此时可以点击左下方跳转到源码：

图10 DevTools泳道图区域划分

源码耗时如下图所示：

图11 源码耗时

如图所示，源码处会显示具体方法的耗时，此时可以发现myFun1方法采用了递归，大幅增加了CPU的运算耗时，导致了响应延时。可以将递归方法myFun1优化为循环方法myFun2，时间复杂度从O(2^n)降低到O(n)，在该场景下能显著减少耗时（经测试myFun2实际耗时在us级别，无法使用DevTools工具统计，可以使用其他方法进行函数耗时统计分析）。

网络区域异常分析

网络耗时占比过高异常通常发生在响应阶段，表现为网络请求完成后执行JavaScript或任务时阻塞线程，导致整体耗时显著增加。对应下图中的区域2：

图12 DevTools泳道图区域划分

动画区域异常分析

对应于下图中的区域4，如果测试的响应时间的Trace起点到终点的时间相差很大，此时动画区域会有异常。常见的异常如动画中的页面背景色为透明，动画曲线为先慢后快导致动画弹出起点时，透明色视觉上没有变化。

图13 DevTools泳道图区域划分

空白区域异常分析

对应下图中的区域5：

图14 DevTools泳道图区域划分

此处的异常点通常为：

1. 网络请求时间过长，导致页面长时间没有页面元素渲染显示。
2. 定时器等待，空白区域之后能找到定时器相关的函数执行。

发现代码中有await delayFun(500)这种定时器延迟函数，优化方法是移除冗余延迟函数。

经过上述分析步骤的优化，此时再次调用DevTools进行分析：

图15 优化后的泳道图

可以看出耗时明显减少，回归正常水平。

总结

通过以上步骤，使用录屏、Trace工具和Devtools分析，可以有效定位并解决Web页面内点击响应时延类问题。