利用 Traceview 精准定位启动时间测试的异常方法 (工具开源)

机智的防爬虫标识
原创博客地址：http://www.cnblogs.com/alexkn/p/7095855.html
博客求关注： http://www.cnblogs.com/alexkn

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

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

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

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

问题定位方法的改进
误差需要用科学的方法去做估算

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

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

在这里要推荐的是Traceview。Traceview的介绍可以看这篇文章：https://testerhome.com/topics/5049

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

操作不超过5s
在IDE上查看才比较方便
大部分方法都混淆了，很难有效定位到对应的方法

其实这些问题都不是问题

Traceview可以通过android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();来打点，生成这段启动周期的Trace数据
google提供了一个半成品dmtracedump，可以解析Traceview文件，当然也只是半成品，但我们可以自己解析，但是是有办法突破IDE限制的
混淆问题其实不算问题，一般都有自己的mapping文件去解混淆

3.方案应用

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

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

4.思路拓展

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

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

5.开源一个工具

目前工具已开源，项目地址：https://github.com/alexknight/TraceAnalysis ，欢迎star
代码是一年半前写的，原来也只是边探索边验证效果，后面没有做重构，所以代码质量并不高。最近仅仅只是把功能抽了出来，如果能够帮到你，随手star让我更有动力输出一些有用的东西。
目前工具实现的功能包括