从零到一了解 APP 速度测评

作者 | 龙霸天

一、引言

为了知道「为什么会打雷下雨」，我们拿起了手机，使用百度 APP 进行搜索：

小小的一个搜索诉求，却需要经历一个不短的交互过程。就跟去银行办业务一样，只想改个银行预留手机号，却要：扫核酸码进场，取号，等号，沟通，办理，完成。

交互过程中的任何一个过长的等待，都可能会导致用户流失，以下我们列举了几个常见的 APP 交互慢导致用户流失的场景：

△启动 APP 如果要好几秒，用户下一次可能会选择直接使用原生浏览器

△点击搜索好久才出搜索结果，用户下一次很可能会选择竞品搜索引擎

△查看一个内容，如果资源打开缓慢，用户下一次可能就去垂直 APP 找答案了

△你是不是也曾被打开缓慢的健康码困扰？

速度是影响用户存留的关键因素。BBC 发现他们的网站加载时间每增加一秒，就会失去 10% 的用户；Pinterest 将感知等待时间减少了 40% 后，来自搜索引擎的流量和注册量增加了 15%……

速度意味着提高转化。Lazada 将页面 LCP 提升 3 倍后，转化率提升了 16.9%；GYAO 将页面 LCP 提升 3.1 倍后，广告点击率增加了 108%；……

（数据来源：https://web.dev/why-speed-matters/ ）

速度如此重要，所以我们经常需要对 APP 的关键场景进行速度评测，以实现两个目的：

1. 防劣化：防止 APP 自己本身速度劣化，以持续给予用户最好的交互体验；

2. 看差距：努力提供比竞品 APP 更好的性能体验，以留存用户，提高转化。

需要注意的是：APP 速度评测，不关注交互过程中 APP 发起了多少后端请求，启动了多少个进程，每一个任务处理耗时多久，CPU/内存损耗，渲染是否抖动，过程是否流畅，而只关注用户同 APP 的交互速度，也就是用户给 APP 一个输入信号，APP 的反馈响应速度。

而本文主要讲述了三种 APP 速度评测的手法。

二、基于日志打点的 APP 速度评测

手法概述：在 APP 的关键节点进行「日志打点」，再通过日志数据统计分析，得到感兴趣的速度指标。

以下，举一个比较好的例子来说明下。

如图所示，是百度贴吧智能小程序的一次调起过程，从小程序开始加载（Loading）、到 APP 开始初步绘制小程序外框架（FP），到第一次内容呈现（FCP），再到整体页面成型（FMP），最后达到可交互状态（TTI）。

智能小程序生态期望小程序开发者可以关注小程序性能，从而让小程序拥有更好的用户体验，因此期望为各个小程序的开发者提供各页面启动场景的上屏时长，从而让开发者了解现状，助力其优化小程序性能体验。

智能小程序生态有数十万小程序，一个一个帮开发者评测速度明显不大现实，因此选择了「基于日志打点的评测手法」。

通过在小程序核心框架进行日志打点得到「小程序启动时间」及「小程序页面内容超过一屏时刻」，并定义两者时间间隔为小程序调起的上屏时长，通过日志数据统计分析后提供给小程序开发者。

该手法的优点在于：

1. 成本较低

2. 容易实施

3. 结果基于线上日志数据抽样统计生成从而更贴近整体情况

但同时也存在一些问题：

1. 日志打点仅能针对自家 APP，因此无法通过这种方式完成竞品 APP 的速度评测，无法获悉同竞品 APP 的速度差距。

2. 受限于所评测业务场景的各种异步数据请求动作，在各阶段进行日志打点以准确捕捉对应时刻在实际操作中并不容易，且为了防止对业务本身性能影响，大多时候只能做简单采集，未必能得到最贴近用户观感的速度指标。

因此，为了能更好刻画用户直接观感，我们往往会倾向于采用人工评测的手法。

三、人工手段的 APP 速度测评

手法概述：人工操作 APP，全程摄像头录屏，事后对录屏做分帧处理，然后人工寻找关键节点帧，统计得出相应速度指标。

以下，继续举例子来说明。

如图所示，是百度 APP 的一个搜索过程，我们期望得到「点击搜索」按钮到「搜索结果页」完全渲染的过程时间。

点击搜索按钮到搜索结果页完成渲染的过程很短（百毫秒级），要人工观测这个操作过程时长不大现实。

因此我们使用摄像头对操作过程全程录屏并把录屏存到电脑。

△摄像头全程录屏

接着，我们使用视频分帧工具对录屏按一定帧率进行分帧，然后人工寻找「点击搜索按钮」的那一帧及「结果页完全渲染」那一帧，最后取两个帧的时间间隔作为本次搜索时间。

△多 APP 混合评测得到对比结果

该手法的优点在于：

1. 可以采集到最贴近用户观感的速度指标

2. 可以做竞品对比

但同时也存在一些问题：

1. 整个过程充斥着大量重复而又枯燥的过程，极其耗时、极其耗费精力，非常低效。参考既有人效数据：人工评测一个简单场景就要耗费

2. 3 天，复杂场景可以达到半个月，而如果想要做到更精确的多地域多用户覆盖的话，周期可以长达两个月。

3. 人工评测过程得到的数值会受评测时网络、设备状态等影响，且采样数量非常有限，故不能使用绝对值作为直接结果，而只能用于竞品对比或者版本间对比

如果一件事情做起来成本较高，即使它对产品有所增益，考虑性价比，我们也会选择不做或者少做。

低效的手段让大部分业务望而却步，因此常将性能评测周期延长到一个季度甚至半年一次。

为了降低人工评测成本，自动化评测应运而生。

四、自动化驱动 APP 速度评测

手法概述：通过自动化手段操作 APP 并全程录屏，事后对路径进行分帧并经算法找到目标关键帧，最后通过统计学手法计算相应速度指标。

回顾整个人工评测过程，其实也就三个步骤：

1. 操作 APP 完成交互同时全程录屏（有时也会直接采用手机的系统录屏工具直接录屏）

2. 对录屏进行分帧处理，并在分帧里人工找寻首尾帧

3. 重复 n 次，按一定统计学手法取均值

拆解后，可以发现，只要三个核心能力，便能实现自动化：

1. 自动化操控手机的能力

2. 全程录屏的能力

3. 自动化找寻首尾帧的能力

自动化操控手机完成交互的开源工具有很多，比如：Appium、Adb、WDA、Uiautomator2、Tidevice 等。

自动化进行手机录屏的开源工具也有：scrcpy、minicap 等。

值得一提的是，自动化找寻首尾帧在市面上并没有现成通用的工具，需要根据交互场景的不同及现实限制性条件去设计，一般来说都需要动用到计算机视觉相关算法。为了方便大家理解，这里举几个例子：

例子 1：我们在 Android 设备上开启了「显示指针位置」，这样当我们操作手机的时候，都会在手机上留下一个「十字锚点」。如此，针对于 Android 设备以某个点击动作为开始的交互场景，我们就可以把「找寻首帧」问题转换成找寻带有「十字锚点」帧的问题。接着使用计算机视觉算法找寻十字锚点帧，便能实现首帧自动识别。

△Android 设备开启「显示指针位置」，将找寻首帧问题转换成找寻十字锚点帧

例子 2：我们想要取得「搜索结果页」自点击搜索到第一个视频卡片的视频启动播放的过程耗时。视频启动播放的标识是左下角出现一个「开启声音的 icon」，因此我们只要使用计算机视觉算法找寻对应 icon 图标出现帧，便能实现该交互场景的尾帧自动识别。

△通过使用特定图像作为锚定物，将找寻尾帧问题转换成图像查找问题。

自动化评测手法相比于人工评测优点在于：

1. 极大降低了人力消耗

2. 极大提升了评测效率

我们期望通过自动化来降低评测成本，但自动化本身也带来了额外的成本和问题：

1. 自动化用例编写的难易度、上手成本及可持续性等

2. 自动化执行的稳定性及置信度

3. 首尾帧识别算法的定制化开发成本及准确率问题

因此，我们开发了一个名为 LazyPerf 的 APP 速度评测工具，期望能够通过一体化的解决方案让整体评测成本有质变的下降。

五、APP 速度评测工具 LazyPerft

整个工具核心围绕两个方面提升评测效率：

• 降低自动化用例的编写成本

• 降低首尾帧校准的人工成本

5.1 降低自动化用例的编写成本

核心点 1：我们采用了「基于真机操作录制用例」的手法来编写自动化用例。

好处是：用户只需在手机上轻松一点，便能完成一个自动化用例步骤的录制，上手成本非常低，用例格式统一带来了较好的可持续性，让用户可以将主要精力放在用例的整体设计上。

缺点是：相比于基于脚本代码编写用例，牺牲了用例编写的灵活性，原本脚本里一个 For 循环就能解决的问题，可能就需要工具花费大量精力去设计较为友好的用例编写方式。

核心点 2：引入了基于布局的控件寻址方式，降低 UI 局部变动对自动化用例的影响，同时支持按照「模式」来寻址。

页面结构树往往层级深而冗长，导致基于 XPATH 的控件寻址时常受 UI 局部内容变动影响较大，进而导致用例执行的不稳定，从而要重新录制用例。

因此，我们基于 UI 控件布局关系对页面结构树进行了重塑，重新定义了新的控件寻址方式并通过 LazyPerf 来进行组织，以期降低变动带来的影响。

△页面结构树往往层级深而冗长

此外，我们还遇到了一些场景，是没办法通过 XPATH 进行控件寻址的。

举个例子，我们期望在百度 APP 的推荐栏目下找寻「百度动态类型卡片」，通过点击这类型卡片看「百度动态页」的启动速度。

遇到的问题是，咱们每次打开百度 APP，推荐栏目的内容是会变化的，百度动态类型卡片出现在 Feed 流的第几屏、第几个是不确定的，卡片的内容也是不确定的。

这种情况，我们该怎么进行寻址？

因此，我们在新型的控件寻址方式上追加设计了一种「基于模式的控件寻址方式」，每一个非叶子控件都会通过子控件的 UI 布局信息生成一个模式属性，由此同种类型的 Feed 卡片便会拥有一样的模式属性，这样我们便能通过模式轻松寻址到我们所需的特定类型卡片。

△通过「基于模式的寻址」在多屏内轻松找到「百度动态类型卡片」

核心点 3：设计了基于 UI 控件结构树的控件寻址方式，解决部分场景无法通过系统工具完成控件寻址的问题。

在实践过程中，我们发现有一些 APP 页面会因为内容过于丰富，而没有办法通过 Uiautomator2/WDA 等工具取得控件树，进而使得自动化用例无法编写。

因此我们设计了基于 UI 控件结构树的控件寻址方式，使用视觉算法基于手机截图生成 UI 控件结构树供用户编写用例。

同时也支持用户在截图上自定义圈定控件，然后通过 OCR/图像查找/相似度比对等系列算法组合实现寻址。

5.2 降低收尾帧校准的人工成本

核心点 1：集成各类型场景首尾帧识别算法，让首尾帧识别自动化。

我们采用了传统 CV 及深度学习方案，抽象了 8 套模板，适配 20+ 场景，能够快速满足用户场景需求，这是性能评测降耗的核心所在。虽然大部分场景我们可以实现 5 帧差内准确率 90%+，但是仍然有很多复杂场景是难以实现自动化的，比如「搜索结果页的划屏起播场景」，我们想要获得在划动页面的时候，上一个视频停止播放到下一个视频自动播放的时间间隔，因为不好界定锚点所以较难通过算法实现自动识别。

核心点 2：支持单录屏多场景标注。

往往多个场景存在连续性关系。

举个例子：为了在「搜索结果页」中点击「视频卡片」取得「视频落地页」启动速度，我们需要冷启百度 APP、点击搜索框、输入 Query、点击搜索按钮，最后找寻「视频卡片」并点击。

整个过程至少包含了 3 个交互场景，与其分开执行自动化后进行校准，不如直接利用一次自动化录屏进行分场景校准。

核心点 3：十帧校准模式。

在屏幕固定情况下，一个页面展示的帧数越多，帧图片的可见度就越低，在 13.3 英寸 Macbook 屏上我们发现 10 帧的展示恰到好处。

在 10 帧展示的基础上，我们发现，如果算法自动校准的帧能够在展示的 10 帧内找到，那么人工校准成本在 10s，如果左右滑动 10 帧可以找到则需 20s，滑动超过 10 帧则需 30s+。

因此，如果算法能实现 5 帧差（算法校准帧离目标帧不超过 5 帧以确保在首屏 10 帧内找到）准确率 100%，那么单次校准的人耗就能维持在 10s（较低成本）。

由此，校准成本的持续降低就能够精确转换为自动校准算法 5 帧差准确率的持续提升。

六、问题与展望

由于我们是通过一些系统级的开源工具实现的设备的自动化操控，所以不可避免的，这些工具本身会带来对设备的性能损耗，进而影响评测结果。

虽然我们可以通过控制变量，以巡回执行形式实现对比测试、叠加统计学手法来将影响降低，但是影响终究存在。

与此同时，这些开源工具本身也时常受到设备型号、操作系统版本影响而产生各种可用性问题，且部分工具已无人维护。

这些都为自动化评测的可持续性带来了较大的隐患。

但好在这些问题不是不可解决的，业界已经逐步诞生出一些通过物理方式进行设备自动化操控的手段，所以我们设想，下一代的自动化评测方式可以是这样的：电脑本地 APP 驱动用例录制及执行；通过单目摄像头感知场景，指导自动化执行，同时全程录屏；双轴导轨确定坐标，竖向点触头操作屏幕……

---------- END ----------

推荐阅读【技术加油站】系列：

百度工程师教你玩转设计模式（工厂模式）

揭秘百度智能测试在测试分析领域实践

百度用户产品流批一体的实时数仓实践

ffplay视频播放原理分析

百度工程师眼中的云原生可观测性追踪技术

使用百度开发者工具 4.0 搭建专属的小程序 IDE