从零到一了解APP速度测评网络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-mat... ）
速度如此重要，所以我们经常需要对 APP 的关键场景进行速度评测，以实现两个目的：

防劣化：防止 APP 自己本身速度劣化，以持续给予用户最好的交互体验；
看差距：努力提供比竞品 APP 更好的性能体验，以留存用户，提高转化。

需要注意的是：APP 速度评测，不关注交互过程中 APP 发起了多少后端请求，启动了多少个进程，每一个任务处理耗时多久，CPU/内存损耗，渲染是否抖动，过程是否流畅，而只关注用户同 APP 的交互速度，也就是用户给 APP 一个输入信号，APP 的反馈响应速度。
而本文主要讲述了三种 APP 速度评测的手法。
二、基于日志打点的APP速度评测手法概述：在 APP 的关键节点进行「日志打点」，再通过日志数据统计分析，得到感兴趣的速度指标。
【从零到一了解APP速度测评】以下，举一个比较好的例子来说明下。
如图所示，是百度贴吧智能小程序的一次调起过程，从小程序开始加载（Loading）、到 APP 开始初步绘制小程序外框架（FP），到第一次内容呈现（FCP），再到整体页面成型（FMP），最后达到可交互状态（TTI）。

文章图片

智能小程序生态期望小程序开发者可以关注小程序性能，从而让小程序拥有更好的用户体验，因此期望为各个小程序的开发者提供各页面启动场景的上屏时长，从而让开发者了解现状，助力其优化小程序性能体验。
智能小程序生态有数十万小程序，一个一个帮开发者评测速度明显不大现实，因此选择了「基于日志打点的评测手法」。
通过在小程序核心框架进行日志打点得到「小程序启动时间」及「小程序页面内容超过一屏时刻」，并定义两者时间间隔为小程序调起的上屏时长，通过日志数据统计分析后提供给小程序开发者。

文章图片

该手法的优点在于：

成本较低
容易实施
结果基于线上日志数据抽样统计生成从而更贴近整体情况

但同时也存在一些问题：

日志打点仅能针对自家 APP，因此无法通过这种方式完成竞品 APP 的速度评测，无法获悉同竞品 APP 的速度差距。
受限于所评测业务场景的各种异步数据请求动作，在各阶段进行日志打点以准确捕捉对应时刻在实际操作中并不容易，且为了防止对业务本身性能影响，大多时候只能做简单采集，未必能得到最贴近用户观感的速度指标。

因此，为了能更好刻画用户直接观感，我们往往会倾向于采用人工评测的手法。
三、人工手段的APP速度测评手法概述：人工操作 APP，全程摄像头录屏，事后对录屏做分帧处理，然后人工寻找关键节点帧，统计得出相应速度指标。
以下，继续举例子来说明。
如图所示，是百度 APP 的一个搜索过程，我们期望得到「点击搜索」按钮到「搜索结果页」完全渲染的过程时间。

文章图片

点击搜索按钮到搜索结果页完成渲染的过程很短（百毫秒级），要人工观测这个操作过程时长不大现实。
因此我们使用摄像头对操作过程全程录屏并把录屏存到电脑。

文章图片

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

文章图片

△多 APP 混合评测得到对比结果
该手法的优点在于：

可以采集到最贴近用户观感的速度指标
可以做竞品对比

但同时也存在一些问题：

整个过程充斥着大量重复而又枯燥的过程，极其耗时、极其耗费精力，非常低效。参考既有人效数据：人工评测一个简单场景就要耗费
3 天，复杂场景可以达到半个月，而如果想要做到更精确的多地域多用户覆盖的话，周期可以长达两个月。
人工评测过程得到的数值会受评测时网络、设备状态等影响，且采样数量非常有限，故不能使用绝对值作为直接结果，而只能用于竞品对比或者版本间对比

如果一件事情做起来成本较高，即使它对产品有所增益，考虑性价比，我们也会选择不做或者少做。
低效的手段让大部分业务望而却步，因此常将性能评测周期延长到一个季度甚至半年一次。
为了降低人工评测成本，自动化评测应运而生。
四、自动化驱动APP速度评测手法概述：通过自动化手段操作 APP 并全程录屏，事后对路径进行分帧并经算法找到目标关键帧，最后通过统计学手法计算相应速度指标。
回顾整个人工评测过程，其实也就三个步骤：

操作 APP 完成交互同时全程录屏（有时也会直接采用手机的系统录屏工具直接录屏）
对录屏进行分帧处理，并在分帧里人工找寻首尾帧
重复 n 次，按一定统计学手法取均值

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

自动化操控手机的能力
全程录屏的能力
自动化找寻首尾帧的能力

自动化操控手机完成交互的开源工具有很多，比如：Appium、Adb、WDA、Uiautomator2、Tidevice 等。
自动化进行手机录屏的开源工具也有：scrcpy、minicap 等。
值得一提的是，自动化找寻首尾帧在市面上并没有现成通用的工具，需要根据交互场景的不同及现实限制性条件去设计，一般来说都需要动用到计算机视觉相关算法。为了方便大家理解，这里举几个例子：
例子1：我们在 Android 设备上开启了「显示指针位置」，这样当我们操作手机的时候，都会在手机上留下一个「十字锚点」。如此，针对于 Android 设备以某个点击动作为开始的交互场景，我们就可以把「找寻首帧」问题转换成找寻带有「十字锚点」帧的问题。接着使用计算机视觉算法找寻十字锚点帧，便能实现首帧自动识别。

文章图片

△Android 设备开启「显示指针位置」，将找寻首帧问题转换成找寻十字锚点帧
例子2：我们想要取得「搜索结果页」自点击搜索到第一个视频卡片的视频启动播放的过程耗时。视频启动播放的标识是左下角出现一个「开启声音的 icon」，因此我们只要使用计算机视觉算法找寻对应 icon 图标出现帧，便能实现该交互场景的尾帧自动识别。

文章图片

△通过使用特定图像作为锚定物，将找寻尾帧问题转换成图像查找问题。
自动化评测手法相比于人工评测优点在于：

极大降低了人力消耗
极大提升了评测效率

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

自动化用例编写的难易度、上手成本及可持续性等
自动化执行的稳定性及置信度
首尾帧识别算法的定制化开发成本及准确率问题

因此，我们开发了一个名为 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