正确使用Android性能分析工具——TraceView

前面唠叨

最近公司app中有些列表在滑动的时候会有卡顿现象，我就开始着手解决这些问题，解决问题以前首先要分析列表滑动的性能瓶颈在什么地方。由于以前不会正确使用TraceView这个工具，主要是看不懂TraceView界面下方数据指标的值表明什么意思…之前我用StopWatch类来分析性能，如今以为弱爆了…不过有些地方StopWatch工具类仍是很简单好用的~

网上能够找了不少博客来介绍这个工具的使用方法，不少都是讲解了一些一些就会的方法，讲一个大概，包括StackOverFlow上我也没有找到很好的讲解TraceView各个数据指标代码什么意思的回答

由于我要解决列表滑动的卡顿问题，就必需要找到致使卡顿现象的缘由，我就在StackOverFlow上找着别人零散的回答慢慢琢磨这个工具的使用方法。如今我学会了，至少能看懂每一个指标什么意思，最后发现这个工具实在太强大了！！！

TraceView界面

现来看一下整个界面的图，整个界面包括上下两部分，上面是你测试的进程中每一个线程的执行状况，每一个线程占一行；下面是每一个方法执行的各个指标的值

上面一部分是你测试进程的中每一个线程运行的时间线，下图中能够能够看到，主要只有一个main线程在执行，由于我滑动了一下列表，main线程（UI线程）正在进行绘制View呢~

而后我点击了序号为133的一个方法io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView，就会出现两部分数据：

• Parents
• Children

Parents表示调用133这个方法的父方法，能够看到序号为130。Children表示方法133调用的其余方法，能够看到有好几个方法。

如何使用TraceView

由于此次我主要是分析列表滑动卡顿问题，我就讲讲我是怎么使用这个工具的，而且我是怎么分析的。

使用TraceView主要有两种方式：

1. 最简单的方式就是直接打开DDMS，选择一个进程，而后按上面的“Start Method Profiling”按钮，等红色小点变成黑色之后就表示TraceView已经开始工做了。而后我就能够滑动一下列表（如今手机上的操做确定会很卡，由于Android系统在检测Dalvik虚拟机中每一个Java方法的调用，这是我猜想的）。操做最好不要超过5s，由于最好是进行小范围的性能测试。而后再按一下刚才按的按钮，等一会就会出现上面这幅图，而后就能够开始分析了。
2. 第2种方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，当运行了这段代码的时候，就会有一个trace文件在/sdcard目录中生成，也能够调用startMethodTracing(String traceName) 设置trace文件的文件名，最后你可使用adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中，而后用DDMS工具打开就会出现第一幅图了

第一种方式相对来讲是一种简单，可是测试的范围很宽泛，第二中方式相对来讲精确一点，不过我我的喜欢使用第一种，由于简单，并且它是检测你的某一个操做。由于第二中更适合检测某一个方法的性能，其实也没有那种好，看使用的场景和喜爱了。。。

看懂TraceView中的指标

其实我今年7月份就已经开始使用TraceView工具了，可是当时不懂其中每一个指标的含义，就没注意到它强大的地方。看不懂界面下方表格中的指标，这些数据其实一点意义都没有。

网上包括Android官网也没有对TraceView工具的使用有详细的说明文档，这点确实比较蛋疼。

纵轴

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

每一个方法前面都有一个数字，多是所有方法按照Incl CPU Time 时间的排序序号（后面会讲到）

点一个方法后能够看到有两部分，一个是Parents，另外一个是Children。

• Parent表示调用这个方法的方法，能够叫作父方法
• Children表示这个方法中调用的其余方法，能够叫作子方法

横轴

横轴上是不少指标，这些指标表示什么意思真的困扰了我很长一段时间。。。

可以很衡量一个方法性能的指标应该只有时间了吧？ 一个方法确定就是执行时间越短约好咯~~

1. Incl Cpu Time

define inclusive ： 全包括的

上图中能够看到0（toplevel） 的Incl Cpu Time 占了100%的时间，这个不是说100%的时间都是它在执行，请看下面代码：

1

2

3

4

5

6

public void top() {

a();

b();

c();

d();

}

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

并且调用方法top的方法的执行时间是100ms，那么：

Incl Cpu Time

top
10%

a
10%

b
20%

c
30%

d
40%

从上面图中能够看到：
toplevel的 Incl Cpu Time 是1110.943，而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time为12.859，说明后者的Incl Cpu Time % 约为1.2%

这个指标表示 这个方法以及这个方法的子方法（好比top方法中的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表示递归调用次数，看下图：

我选中了一个方法，能够看到这个方法的Calls + Recur Calls 值是14 + 0，表示这个方法调用了14次，可是没有递归调用

从Children这一块来看，不少方法调用都是13的倍数，说明父方法中有一个判断，可是这不是重点，有些Child方法调用Calls为26，这说明了这些方法被调用了两遍，是否是可能存在重复调用的状况？这些都是可能能够优化性能的地方。

6. Cpu Time / Call

重点来了！！！！！！！！！！

这个指标应该说是最重要的，从上图能够看到，133这个方法的调用次数为20次，而它的Incl Cpu Time为12.859ms，那么133方法每一次执行的时间是0.643ms（133这个方法是SimpleAdapter的getItemView方法）

对于一个adapter的getView方法来讲0.643ms是很是快的（由于这个adapter中只有一个TextView，我为了测试用的）

若是getView方法执行时间很长，那么必然致使列表滑动的时候产生卡顿现象，能够在getView方法的Children方法列表中找到耗时最长的方法，分析出现问题的缘由：

• 是由于有过多的计算？
• 仍是由于有读取SD卡的操做？
• 仍是由于adapter中View太复杂了？
• 仍是由于须要有不少判断，设置View的显示仍是隐藏
• 仍是由于其余缘由…

7. Real Time / Call

Real Time 和 Cpu Time 我如今还不太明白它们的区别，个人理解应该是:

• Cpu Time 应该是某个方法占用CPU的时间
• Real Time 应该是这个方法的实际运行时间

为何它们会有区别呢？多是由于CPU的上下文切换、阻塞、GC等缘由方法的实际执行时间要比Cpu Time 要稍微长一点。

总结

TraceView是一个很是强大的性能分析工具，由于Android 官网对这个工具的使用介绍文档不多，并且一些中文博客中写的也都是抄来抄去，没有讲到底怎么使用。

最近我在作这方面的性能分析，就慢慢琢磨了这么工具的使用，发现很是强大，写下来总结一下。

Android的性能分析工具还有不少，好比：

• Eclipse Memory Analyzer Tool 来分析Android app的内存使用
• Dump UI Hierarchy for UI Atomator，分析UI层级
• systrace
• 其余

下图这一条工具栏中有不少性能分析工具~~~

29