利用 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让我更有动力输出一些有用的东西。
目前工具实现的功能包括

• 支持反混淆
• 支持获取Traceview文件的解析结果，json对象返回
• 提供默认模板，支持Traceview两两对比，生成csv的结果文件

6.效果展现

在这里，展现一下traceview文件解析后获取到的json数据内容。其中包括了

• call_times每一个方法的调用次数
• costs:总耗时时长
• exclusive:每一个方法的cpu时间片以及调用栈
• inclusive:包含了每一个方法及孩子方法的时间累加
• method_thread:包含了涉及到该trace涉及到的全部线程
• sorted_dic:对全部耗时方法作了排序以tuple方式存储在list中
• threads_pid:各个线程对应的pid

展开exclusive，能够看到不少细节都有存储

另外若是使用默认的报表对比输出格式，展现的结果则为：