知乎 iOS App 启动时间测试实践(启动测试时间时长数据)

Optimizing App Startup Time - Slide Page 126

因此我们的测试方案，需要分为冷启动和暖启动两组场景，冷启动提供更真实的启动时长数据，暖启动数据反映用户日常使用的体验感受（毕竟苹果用户不会经常重启设备）。

录屏工具我们选取了开源的工具 xrecord。
设备连接上电脑后，通过 xrecord 工具将视频文件录制到本地。
在每个设备每个 app 启动测试一次，产生视频一条。

视频内容包含：桌面 → 被测 App 图标变黑 → 展示知乎开屏 → 展示主体框架 → 首页内容加载完成。
由于首页内容加载完成是异步实现的，因此我们选取分析的关键节点，是「被测 App 图标变黑」和「展示主体框架」这两个点。
通过 FFmpeg 将视频转换成分帧后的图像，剔除相似度较高的图像后，再进行人工选取关键节点。

竞品的选择需要综合考虑包体积、业务复杂度、业务类型等因素，选择和知乎体量相当的 App 进行真实的同等机型测试。
否则相差较大的应用，启动时间的参考意义也不大。

经过实际测试后，我们发现：

详细测试结果如下：

优化后结果

在知乎移动平台 iOS 工程师的不懈努力下，经历多个版本的迭代优化，最终知乎 iOS App 的启动时长终于在同类竞品中处于较快水平，优化效果非常明显，

详细测试结果如下：

如何「守住」优化后的结果

业务的快速发展不可避免的会导致启动时间逐步增长，如何「守住」工程师们辛苦「攻下」的优化成果呢？录屏分帧测试虽然结果非常有说服力，但每个版本测试包含录制、标注、整理报告等环节，且需要对同一个机型进行多组测试来减少误差，需要耗费约 3 人/天的工作量。
如果每个版本都进行一次测试，将会耗费大量测试人力。
且这种测试方法只能给出整体启动时长的报告，无法准确定位到启动的异常。
因此我们尝试做了一些低成本、能快速反馈的自动化测试。

目前，知乎 iOS App 启动项分为三种：

同步启动项是决定启动时长的关键因素，知乎移动平台 iOS 工程师团队在知乎自研的性能收集 APM SDK 中，加入了同步启动项的耗时收集，并记录在沙盒的数据库中。
通过这些数据，我们可以轻松的分析每次启动时的耗时情况。

知乎的代码是托管在 Gitlab 上，每一个需求的提测，都是对应到一个 Merge Request。
我们希望针对 Merge Request 进行测试，确认代码变动不会引入增加启动耗时的风险，才能正常合入。
在 Merge Request 打出包后，通过 ios-deploy 工具，在真机上自动安装知乎 App 并启动 10 次。
测试结束后，客户端上报记录的启动时长数据到数据收集服务。
数据收集服务进行汇总分析，并用前端图表给出直观的展示。
整体测试在 Jenkins Pipeline 里完成，测试流程如下：

测试流程图

测试报告主要提供平均启动时长、启动项数量、各个启动项占用的时长等几个维度，通过图表展示，非常直观的看到各个启动项的时间占用。

对于新增启动项或启动时长远超过平均值时，会给出对应的警告反馈，需要 Merge Request 的负责人跟进排查。

测试报告列表

测试报告详细数据

通过这套自动化测试方案，能够快速的找到新增启动项和启动明显变慢的 Merge Request，更有效的帮助我们「守住」优化后的成果。

启动速度优化是一个持续的工作，「攻」和「守」双方面都要关注。
除了分析 APM SDK 记录的启动项时间，我们也不会放弃录屏分帧的测试方法，毕竟它是最直观的用户感受。
后续我们也会尝试使用机器学习领域的技术对图像进行识别，训练原来人工标注的视频帧，自动识别出新录制视频里的启动开始和结束的那两帧，提高录屏测试方法的标注效率。

作者:钟离无糖

出处:https://zhuanlan.zhihu.com/p/48218035