android app优化工具之traceview

1.TraceView 是什么

TraceView 是AndroidSDK 中内置的一个工具,它可以加载trace文件,用图形的形式展示代码的执行时间、次数及调用栈,便于我们分析。

手机卡顿很多时候都是由于某个操作过于耗时,在茫茫代码中查找元凶未免太过痛苦,这时候就该体现 TraceView 的价值了,通过traceview,可以知道时间都消耗在哪里了

生成 trace 文件有三种方法:

使用代码

使用 Android Studio

使用 DDMS

这里我只分享下用DDMS生成

2、详细操作步骤:

打开 Android Device Monitor,在 DDMS 中打开 trace 文件,DDMS 会启动 TraceView 加载 trace 文件:

android app优化工具之traceview_第1张图片

操作手机上出现问题的地方


android app优化工具之traceview_第2张图片


android app优化工具之traceview_第3张图片

3、分析生成的数据:

先分析上半部分


android app优化工具之traceview_第4张图片

上半部分显示了不同线程的执行时间

每种颜色代表不同的函数和步骤,同一颜色的区域越大,就代表这个步骤运行时间越长

程序中每个线程调用方法的启动和停止时间

同一个颜色越长,说明执行时间越久,如图中的主线程 main

空白表示这个时间段内没有执行内容

右上角显示程序总共运行了13400毫秒

纵轴

TraceView界面下方表格中纵轴就是每个方法,包括了JDK的,Android SDK的,也有native方法的,当然最重要的就是app中你自己写的方法,有些Android系统的方法执行时间很长,那么有很大的可能就是你app中调用这些方法过多导致的。

下半部分展示了不同方法的执行时间信息,关键指标有三个:

Cpu Time/Call :该方法平均占用 CPU 的时间

Real Time/Call :平均执行时间,包括切换、阻塞的时间,>= Cpu Time

Calls + Recur Calls/Total :调用、递归次数

每个方法前面都有一个数字,可能是全部方法按照Incl CPU Time 时间的排序序号(后面会讲到)

点一个方法后可以看到有两部分,一个是Parents,另一个是Children。

Parent表示调用这个方法的方法,可以叫做父方法

Children表示这个方法中调用的其他方法,可以叫做子方法

横轴


android app优化工具之traceview_第5张图片

inclusive:就是说除统计函数本身运行的时间外再加上调用子函数所运行的时间

Exclusive:统计函数本身运行的时间

1. Incl Cpu Time

Incl Cpu Time表示方法top执行的总时间,假如说方法top的执行时间为10ms,方法a执行了1ms,方法b执行了2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间要小一点)。

publicvoidtop() {

a();

b();

c();

d();

}

2. Excl Cpu Time

理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了,还是上面top方法的栗子:

方法top 的 Incl Cpu Time 减去 方法a、b、c、d的Incl Cpu Time 的时间就是方法top的Excl Cpu Time 了

3. Incl Real Time

这个感觉和Incl Cpu Time 差不多,第7条会讲到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

这个指标非常重要!

它表示这个方法执行的次数,这个指标中有两个值,一个Call表示这个方法调用的次数,Recur Call表示递归调用次数,看下图:


android app优化工具之traceview_第6张图片

我选中了一个方法,可以看到这个方法的Calls + Recur Calls值是1 + 17,表示这个方法调用了1次,递归调用17次

6. Cpu Time / Call

重点来了!!!!!!!!!!


android app优化工具之traceview_第7张图片

这个指标应该说是最重要的,从上图可以看到,这个方法的调用次数为3次,而它的Incl Cpu Time为251.793ms,方法调用了3次,所以每一次的时间为83.913(也就是Cpu Time)

getView方法执行时间很长,那么必然导致列表滑动的时候产生卡顿现象,可以在getView方法的Children方法列表中找到耗时最长的方法,分析出现问题的原因:

是因为有过多的计算?

还是因为有读取SD卡的操作?

还是因为adapter中View太复杂了?

还是因为需要有很多判断,设置View的显示还是隐藏

还是因为其他原因…

7. Real Time / Call

Real Time 和 Cpu Time 我现在还不太明白它们的区别,我的理解应该是:

Cpu Time 应该是某个方法占用CPU的时间

Real Time 应该是这个方法的实际运行时间

为什么它们会有区别呢?可能是因为CPU的上下文切换、阻塞、GC等原因方法的实际执行时间要比Cpu Time 要稍微长一点。

下半部分展示了不同方法的执行时间信息,关键指标有三个:

Cpu Time/Call :该方法平均占用 CPU 的时间

Real Time/Call :平均执行时间,包括切换、阻塞的时间,>= Cpu Time

Calls + Recur Calls/Total :调用、递归次数

点击下面的任意一个方法,可以看到它的详细信息:

Parents:选中方法的调用处

Children:选中方法调用的方法

根据 TraceView 显示内容定位问题

定位问题时 TraceView 的使用方式:

从上半部分查看哪些线程执行时间长?什么时候开始执行?与主线程交错时间?

哪些方法的执行需要花费很长时间

点击 TraceView 中的 Cpu Time/Call,按照占用 CPU 时间从高到低排序

哪些方法调用次数非常频繁

点击 TraceView 中的 Calls + Recur Calls/Total ,按照调用次数从高到底排序

排序后,然后逐个排查是否有项目代码或者依赖库代码,有的话点击查看详情,查看是这个方法还是调用的子方法的问题,进一步定位问题。


实例:


android app优化工具之traceview_第8张图片
android app优化工具之traceview_第9张图片

可以看到项目中我们写的方法的耗时,可以点进去,看child,查找时间消耗去向

1)

android app优化工具之traceview_第10张图片

经由上图可以发现,HouseListTask的doInBackground方法的时间消耗在UtilsLog和解析上了

2)GetHouseTrueCountAsynTask的doInBackground方法的时间消耗在了HttpClient.execute上了

GetHouseTrueCountAsynTask的onPostExcute方法的时间消耗在cacheToDisk这个方法上

3)getview方法时间消耗在inflate方法上了

你可能感兴趣的:(android app优化工具之traceview)