共计 5137 个字符，预计需要花费 13 分钟才能阅读完成。
作者 | 龙霸天
一、引言
为了晓得「为什么会打雷下雨」，咱们拿起了手机，应用百度 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 的要害节点进行「日志打点」，再通过日志数据统计分析，失去感兴趣的速度指标。
以下，举一个比拟好的例子来阐明下。
如图所示，是百度贴吧智能小程序的一次调起过程，从小程序开始加载（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