DevEco Testing 数据存疑？三步教你快速校准！

在使用 DevEco Testing 进行性能测试时，偶尔可能会对某些数据结果产生疑问。别担心！DevEco Testing 贴心地为每个操作步骤都记录了每帧截图和视频，方便你快速自行定位和校准特殊情况下的数据。下面我们就针对常见的响应时延、完成时延和卡顿指标，看看如何利用这些图像资源进行校准：

一、校准响应时延

响应时延的起点是基于系统 Trace 判断的，通常比较准确。一般只需要验证结束点：

1. 定位起始点： 点击报告中响应时延的“开始时间”。工具会定位到距离你点击动作瞬间最近的那一帧截图。

   • 为什么是“最近”而不是“精确点击瞬间”？ 因为屏幕刷新（刷帧）和设备响应点击的时刻不一定完全同步。DevEco Testing 的图像是按帧抓取的，而你的点击可能发生在两次刷帧之间。

   • 如何判断起点准确？ 观察这张“开始时间”帧，此时界面应该与前几帧相同，表明设备此时是静止的，尚未开始响应你的操作。

2. 定位结束点： 点击报告中响应时延的“结束时间”。工具会定位到它判断为界面发生变化的第一帧。

   • 如何判断终点准确？ 仔细观察这张“结束时间”帧，并与它之前和之后的几帧对比。如果这张图确实是界面首次发生可见变化的那一帧，那么这个结束点就是准确的。

二、校准完成时延

完成时延的判断逻辑与响应时延类似，关键在于结束点的定义不同：

• 定位结束点： 完成时延的结束点是找到界面变化后再次进入静止状态的第一帧。

• 特殊场景处理： 有些应用会先加载内容，然后很快又刷新一次（比如先显示缓存内容，再二次进行刷新）。对于这种情况，DevEco Testing 默认会取第二次刷新完成的时间作为结束点，因为这更能代表用户感知到的“完成”状态。

三、校准卡顿（丢帧）

卡顿类指标（如丢帧数）的校准相对直观，主要依赖图片的时间戳：

1. 理解刷帧原理：

   • DevEco Testing 只在有动画或变化的动态过程中检测卡顿，静止画面本身的不刷帧不算问题。

   • 在动态过程中，设备屏幕应该按照其刷新率稳定刷帧。例如，对于 60Hz 刷新率的屏幕，预期每帧间隔大约是 16.67 毫秒 (ms)。

2. 识别丢帧： 查看连续图片的时间戳：

   • 正常情况下： 相邻图片的时间戳差应该接近 16.67ms（60Hz 下）。

   • 出现卡顿/丢帧： 当你发现相邻图片的时间戳差远大于 16ms 左右时，就表明在这段时间内设备没有按预期刷帧，发生了丢帧。

3. 计算丢帧数：

   • 计算两个连续帧之间过大的时间差。

   • 将这个时间差除以预期的每帧时间（如 16.67ms），就能估算出中间丢失了多少帧。

   • 示例（如下图）： 从时间戳 1610ms 的帧到 1660ms 的帧，中间间隔了 50ms。

     • 预期刷帧次数：50ms / 16.67ms ≈ 3 帧（即在 1610ms 之后，预期大约在 1626.67ms, 1643.34ms, 1660ms 刷出3帧）。

     • 实际刷帧：只有 1660ms 这一帧。

     • 因此，判定在这 50ms 内丢失了 2 帧（预期3帧 - 实际1帧 = 丢失2帧）。