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

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

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

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

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

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

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

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

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

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

在这里要推荐的是TraceviewTraceview的介绍可以看这篇文章: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,过滤出改动的方法
  • 对比svnlogtop异常方法,自动将可疑方法邮件发给研发,实现监控问题到定位问题的闭环。

5.开源一个工具

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

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

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