背景

对于端侧应用而言，启动耗时是个非常重要的性能指标：它的快慢很大程度上决定了用户第一印象的好坏，与用户的实际体验密切相关。

而正因为它的地位举足轻重，在敏捷开发逐渐成为主流的今天，我们不得不在每一轮迭代中都对它进行重复回归。而随着迭代周期逐渐缩短，发布频次逐渐增加，重复回归带来的副作用也日益沉重，让我们不得不开始思考如何进行优化。

行业现在是怎么做的

一般来说分为两个方向：

以埋点插桩为代表的开发向；
以视频数帧为代表的质量向；

埋点

埋点方案的应用在开发领域非常广泛，它也几乎是进行性能优化的唯一参考。以android为例，常见做法是在各类组件生命周期相关的回调函数中，插入部分代码（诸如日志、网络请求等）对调用行为进行标注。如此做之后，当应用进行常规的生命周期切换时，我们就能够通过这些带有时间戳的标注得到每个阶段的具体耗时。

这种做法非常细致，我们几乎能够得到任意函数级别的耗时情况，这也让我们能够在此基础上建立 benchmark 以控制后续的行为。目前大多数的全链路监控都是基于类似的方法实现的。

但，它得到的代码层面的数据，与实际用户感受到的情况是有差距的，这也是质量人员对此并不感冒的原因。

视频

原理非常直接：

利用诸如摄像机之类的设备将整个应用的启动过程录制成视频
对视频进行拆帧
由于每一帧都有对应的时间戳，我们可以通过计算得到任意两帧之间的差值
同理我们能够得到任意场景的耗时情况

这种方法与用户的实际感受基本一致，能够较好地反映真实情况，也是一般质量侧用得最多的方法。但这种方法带来的问题是，我们只能计算能够被观测到的数据，而对于不可见的（例如具体函数耗时）部分我们无从得知。

异同与优劣

目前来说，这两种方法都有相当数量的用户，在行业内并存。追根溯源，是关注点的差异导致了这两股人群的分化：

开发人员更关注的是“优化”。埋点得到的信息能够帮助开发人员更好地知悉并评估代码执行过程的变化，找到优化点；
质量人员更关注的是“体验”。视频得到的信息反馈了用户的真实感受，也是最终应用呈现的状态，而这正是质量人员需要牢牢把控的；

综上而言，这两者通常会结合使用，以配合得到更好的结果。

难点

埋点方案已经广泛地应用到全链路监控中，各类成熟的解决方案层出不穷，并不是一个很难解决的问题。

视频方案上，目前我们很大程度上依旧只能依赖外置摄像机+人工数帧的方式，这种不可编程的方式优化空间非常有限。而这种方式被大量应用到各类准入准出标准中，是一个难以避开的问题。

本篇文章将聚焦于视频方案的优化与解决。

优化点与方案

最终目的

我们希望将视频方案上消耗的人力最大限度地降低。这其中主要有两个问题：

摄像机（硬件依赖）能否替换？
帧计算如何自动化？

问题分析

摄像机

之所以质量侧一直不够信任软件录制，主要有两个原因：

被测主体与测试工具在同一台设备上，有互相影响的可能；

部分软件录制得到的视频fps可能是不稳定的，而这会影响opencv的分析结论；

对于问题1，在过去硬件条件不够发达的情况下确实是个客观存在的问题。但近年来移动设备的硬件水平已经得到了非常大的提升，对于常规应用与机型而言，这部分的影响已经非常小。

对于问题2，以adb为例，这种方式带来的误差可能是非常巨大的。因为opencv会默认以稳定fps的情况来处理你的视频：

而 adb 的录制原理是，当画面发生变化时才会将帧写入视频，这会导致整个视频的fps存在较大的波动。

自动化的帧计算

因为作为前提的摄像机录制目前没有很好的解决方案，所以自动计算受到了很大的限制而难以开展。目前比较常见的方式是利用目标检测来自动界定阶段：

通过判断界面上是否存在特定标志物，我们可以知悉目前流程进行到哪个阶段，并在此基础上进行扩展计算。但这种做法伴随的问题同样很多：

需要额外的成本去管理标志物图片，而这种做法在UI频繁变换的业务中反而引入了更大的工作量；
逐帧、多目标的检测带来算力的浪费，随着标志物的增加效率会继续下降；
对于动态的标志物（诸如每次刷新都会改变的icon）无从下手；

如何解决

对于fps不稳定的问题，有个前提是，虽然fps不稳定，但每一帧的时间戳是准确的。那么，我们可以利用 ffmpeg 对这些视频进行补帧，使整个视频的fps维持在一个固定值。经过这种方法处理之后，opencv就能够正确地处理视频的时间。

在前提得到满足之后，我们使用 stagesepx 进行帧时间的自动计算。

stagesepx

这是什么

轻量化的、基于图像处理与机器学习的、全自动的视频分析工具。它提供了丰富的可定制性，能够根据你的实际需求分析视频并将其拆分为一系列阶段。在此之后，你可以清晰地得知视频包含了几个阶段、以及每个阶段发生了什么。而这一切都是自动完成的。

例如，这段视频展示了一个应用的完整启动过程：

将视频传递给 stagesepx，它将自动分析拆解，得到视频中所有的阶段。包括变化的过程及其耗时，以及在稳定的阶段停留的时长：

你可以据此得到每个阶段对应的精确耗时。而你几乎可以将它应用到任何端，甚至：

而它自带的python接口可以让开发者很轻松地二次开发，以落地到实际环境。例如，将结果转换为字典：

{
	"data": [{
		"data": null,
		"frame_id": 1,
		"stage": "0",
		"timestamp": 0.0,
		"video_path": "../demo.mp4"
	}, {
		"data": null,
		"frame_id": 2,
		"stage": "0",
		"timestamp": 0.04,
		"video_path": "../demo.mp4"
	}, {
		"data": null,
		"frame_id": 3,
		"stage": "0",
		"timestamp": 0.08,
		"video_path": "../demo.mp4"
	}, {
    
    ...

从这个字典中我们可以知道，每一帧分别对应的：

被分类到哪一个类别
时间戳
帧编号
…

用户可以随意处理这些数据，无论是保存或是交给下一段代码。

全自动化

上面提到的处理过程只能满足一些常规场景的需求，要想达到更好的泛用，它面对的一个最大问题是如何使自动化分析得到的结果与我们的预期匹配起来。例如：

当偶现弹窗时会导致阶段数量发生改变或后移，如果直接以阶段编号进行计算的话必然是错误的；
目前许多超级app都会具备UI动态化的设计，以达到更高的灵活度。这些都会影响阶段的分类：
- 内容型APP每次打开首页内容都不一致
- 插屏广告播放的内容是随机的
- 游戏某个阶段场景是动态的（有循环播放的动画等，很多游戏的初始界面都会有）

在 0.10.0 之后，stagesepx 借助了 keras 来处理该类型问题。

基于 stagesepx 的双层结构，开发者能够使用自己提供的训练集干预分类过程，让计算机能够按照定制好的规则进行分类，以支撑后续耗时计算的准确性。

具体使用可参考全自动化的抖音启动速度测试。

性能

这套方案在没有GPU的情况下依旧保持了较为理想的工作效率。默认配置下，在普通的windows办公PC上，对于一个15s的视频而言，一次分析耗时1分钟左右。

stagesepx 提供了大量的可配置项（诸如分辨率压缩系数），使得用户能够自由地在颗粒度与效率之间找到最合适的平衡。比起传统方式，这种方法有能力大幅提高回归次数，从而得到一个更为客观的评估数据。

如何使用

如果你希望优化你的现有流程：

你可以直接基于上面的落地方式，以自动或人工的方式优化评估流程。

如果你在寻找最佳实践：

一般来说，这套流程会搭配链路监控同步使用。如果你的业务已经具备了链路监控能力，你可以将该套方案添加到已有流程中，将开发侧与质量侧数据汇总起来达到更为全面客观的评测效果。

相关链接

更多使用方式与具体原理请参考官方文档：

创作场景

开源 stagesepx：全自动化的 App 启动耗时测试工具