Android性能分析之TraceView分析

平时开发中特别是列表界面中我们很容易就会发现如果在getView方法中处理了很多操作会带来卡顿现象，这时候我们想优化该从何入手呢？我们想知道一个函数到底被调用了几次，一个方法到底执行完毕需要耗时多久呢？带着这些疑问Google查资料带来了TraceView分析。

TraceView启动

其实呢，TraceView有两种启动方式。第一，可以在代码里面添加

android.os.Debug.startMethodTracing(

以及

android.os.Debug.stopMethodTracing()

添加玩上面代码后就会在sdcard目录下生产一个trace文件，这种方式我是不太喜欢因为比较繁琐，但是这种方式确能更精确。第二种，DDMS启动，进入DDMS选中对应的要调试的应用进程然后点击Start Method Profiling按钮在弹出的对话框中点击确定后在需要调试的界面执行操作，当然操作最好不要超过5s小范围性能优化效果会更佳。

TraceView界面

在经过上面操作之后就会弹出traceview生成界面，我们可以看下如下的效果。

上半部分代表的是当前进程中运行的线程，我们可以看出又main主线程、uil-pool-2-thread1这个图片下载进程等等。下半部分代表的是执行的函数以及一些性能指标。

TraceView分析

可以看出下半部分每个函数都有一个编号，我们随便选中一个函数点击打开可以看出里面有parent、children分别代表的是调用的父方法以及父方法调用的子方法，其实这个还是比较容易理解。

当然以上这些分析肯定不能代表什么，因为根本不知道这些能为你的性能优化带来什么解决办法。所以我们就需要分析下半部分的xxxTime横轴的指标。

首先我们需要看下toplevel这一项：

toplevel代表的是总得消化时间，也就是说在你点击Start Method Profiling按钮以及到生产taceview文件过程中调用的总次数、调用的总时间，明白这一点之后我们可以分析下横线上的指标了。

1.Incl Cpu Time
代表了这个函数执行一遍需要的时长百分比和具体时长值，比如说toplevel总的时长是1000ms，incl cpu time占比是10%也就是说这个函数执行总的时长是1000 * 10%。

2.Excl Cpu Time
可以理解为额外的时间消耗，因为CPU可能需要等待、阻塞等原因导致停止了多少时间，所以说这个函数具体执行时间是Incl Cpu Time减去Excl Cpu Time。

3.Incl Real Time、Excl Real Time
我是把他理解为函数真正的执行时间、时间占比以及额外的时间消化和消化占比。

4.Calls + Recur Calls / Total
其中calls代表这个函数被调用的次数，Recur Calls代表递归调用次数，Total代表的是总的调用次数。然后我们可以看到有的children调用的次数比parent的次数多，我们就可以判断出在parent中有多次调用children的方法从而我们可以判断是否可以省去从而去调性能。

5.Cpu Time / Call
除了上面那个查看调用次数外，这个指标其实更重要，因为这个指标代表了每次执行这个函数所消耗的时间值。比方说，Incl Cpu Time为1000ms然后调用次数为10那么他们的值就为100ms。通过这个时间我们就能知道是不是因为这个函数执行的时间过长，然后再次优化。

6.Real Time / Call
跟第三点分析类似，CPU可能额外等待、阻塞等原因，从而值跟Cpu Time/Call的值有差距。

最后，在我们读懂了这些性能指标之后，可是那么多方法总不能每个方法都去分析，所以我们分析的时候当然只分析跟我们app开发里面涉及的方法做分析，从而找出性能缺陷来实现修复性能问题。