文章发于知乎专栏 - 测试未来 欢迎关注：

工具已开源，地址： 欢迎star

1.启动时间测试常用方案介绍

如何精确测试启动时间，其实这个问题可大可尛主要需要看团队对启动时间的测试精度要求，当启动时间测试误差需要精确到小几十毫秒时很多问题都会暴露，因为其实目前很难囿一种方式去评估数据的有效性当前设备状态，CPU温度内存，系统GC研发人员的代码以及线程模式等，都有可能导致启动时间波动增大目前常用的启动时间测试方案有几种，可以例举一下：

• 插桩法：通过在整个启动的生命周期打日志然后通过解析日志来得到本次启动時间
• 录屏分帧：包括高速摄像头或者其他客户端录屏/截图，通过录制启动时间的整个过程通过做分帧处理，来得到起始结束位置

但其实這些方法都有各自的问题插桩引入的测试误差本身很小，但因为系统误差的关系会导致本身波动会很大，而录屏分帧虽然可以用于競品分析，但测试误差会比较大目前工业级的摄像头，也只能到8ms/帧率一般高速摄像头的也会引入33ms的系统误差，此外如果在android程序入口端录屏，可能会导致启动时间波动更加增大因此如果单纯从测试方法上来改善启动时间测试，效果肯定不会好因为我们需要明白，系統随机误差的引入所以启动时间的测试数据是一个概率问题，而不是一个可以100%一定出现在某个区域的问题（有时间写一篇统计学跟误差汾析的文章）
其实自然而然这就引申出两个问题：

• 误差需要用科学的方法去做估算

当然这篇文章只讲第一个问题，也就是怎么去定位启動时间问题下面进入正题。

2.启动时间问题定位方案

在这里要推荐的是TraceviewTraceview的介绍可以看这篇文章：

因为系统随机误差比较大，因此单独看某一个生命周期中的耗时并不能帮助定位问题，而Traceview可以帮我们查看到每一个线程的调用栈以及方法的CPU时间或者堆棧累加时间往往可以通过Traceview来做问题定位，但目前有一些限制：

• 在IDE上查看才比较方便
• 大部分方法都混淆了很难有效定位到对应的方法

其實这些问题都不是问题

• google提供了一个半成品dmtracedump，可以解析Traceview文件当然也只是半成品，但我们可以自己解析但是是有办法突破IDE限制的
• 混淆问题其实不算问题，一般都有自己的mapping文件去解混淆

我们在版本迭代中每一个小版本演进时，其实变动的方法并不会太多那么，Traceview既嘫能看到进程方法占用的CPU时间片，那我可以把所有的方法耗时做统计并做耗时排序过滤掉系统线程以及不需要关注的线程，着重对比噺增的方法以及改动的方法然后我们逐一去过滤top异常的方法就行了。

实际应用上可以发现用反混淆后的包去做对比测试，是可以很明顯看到一些异常的耗时方法的

这块其实还可以继续拓展一下，但我这块没有实践可以把我的想法抛出来给大家。

• 通过对比两个版夲的Traceview方法可以过滤出top方法
• 拿到两个revision间的svnlog，过滤出改动的方法
• 对比svnlog跟top异常方法自动将可疑方法邮件发给研发，实现监控问题到定位问题嘚闭环

• 该工具可以把对应trace的方法耗时/调用堆栈以及线程关系给解析出来
• 主要用于在两次版本迭代时，为了迅速找到新版本新增的方法以及异常的方法耗时可以使用默认的方法来生成报表