详细列表

这里显示了每个进程、每段时间所调用的方法，以及该方法所占用的CPU和该方法的调用次数。数据量非常大，要读懂这个详细列表，需要先了解一下它每一列代表的含义。

• Name：调用函数名。
• Incl CPU Time（%）：某方法包括其内部调用的其他方法所占用的CPU时间（占总CPU的百分比）。
• Excl CPU Time（%）：某方法但不包括其内部调用的其他方法所占用的CPU时间（占总CPU的百分比）。
• Incl Real Time（%）：某方法包括其内部调用的其他方法所占用的真实时间（占总时间的百分比）。
• Excl CPU Time（%）：某方法但不包括其内部调用的其他方法所占用的真实时间（占总时间的百分比）。
• Call+Recur Calls/Total：某方法调用的次数+递归调用占总调用次数的百分比。
• CPU Time/Call：某方法占用的CPU时间与调用次数的百分比，即该方法的平均占用CPU时间。
• Real Time/Call：某方法占用的真实时间与调用次数的百分比，即该方法的平均占用真实时间。

关于CPU时间和真实时间，一个方法在执行过程中，CPU时间和真实时间并不是完全等同的。CPU时间可以理解为CPU对方法中的数据进行处理的时间，但不包括方法调用、线程调度、线程等待等其他时间，而这所有的时间才是方法的真实时间。

参数非常多，但根据前面的分析，开发者最关心的实际上就是CPU Time/Call和Call+Recur Calls/Total这两列的数据。它们分别对应着以下内容。

• CPU Time/Call方法平均占用CPU时间的长度，即可以寻找单次执行最耗时的方法。
• Call+Recur Calls/Total方法调用次数的多少，即可以寻找调用次数最多的方法。

关于Traceview各种参数的含义，官方开发者网站上给出了详细的介绍，地址如下所示。

• http://developer.android.com/intl/zh-cn/tools/performance/traceview/index.html
• http://developer.android.com/intl/zh-cn/tools/debugging/debugging-tracing.html

首先，点击CPU Time/Call列，让其按照降序排列，找到平均执行时间长的方法（很多系统方法执行时间也是非常长的，这些需要先排除它们的耗时，大部分情况下这是由于App的代码问题造成的）。经过排序后的列表如图6.41所示。

图6.41　按调用时间排序

除去前面的系统方法，可以发现应用的getView方法明显耗时严重（你也可以通过下面的Find来筛选自己应用的方法）。展开这一行数据，如图6.42所示。

图6.42　查找耗时方法

可以发现getView方法调用了10次，但平均耗时却有260多毫秒。再继续查看，发现getView方法中调用的doLongWork（）方法的Incl CPU Time消耗了getView的大量时间，这也就是导致UI卡顿的主要原因。

接下来，点击Call+Recur Calls/Total列，让其按照降序排列，找到调用次数最多的方法，如图6.43所示。

图6.43　按调用次数排序

通过排序，我们可以很清楚地看见测试方法doLongWork（）进行了大量的递归调用。这是导致UI卡顿的主要原因。

以上两种方式是使用Traceview的常用方法。在实际操作过程中，通常会以这两个参数作为重要的判断依据。并结合其他参数，例如Incl CPU Time等来进一步分析。