从零到一了解APP速度测评

原创
09/21 11:15
阅读数 1.2K

图片

作者 | 龙霸天

一、引言

为了知道「为什么会打雷下雨」,我们拿起了手机,使用百度 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. 整个过程充斥着大量重复而又枯燥的过程,极其耗时、极其耗费精力,非常低效。参考既有人效数据:人工评测一个简单场景就要耗费
    3 天,复杂场景可以达到半个月,而如果想要做到更精确的多地域多用户覆盖的话,周期可以长达两个月。

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

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

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

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

四、自动化驱动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

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部