Android性能分析之时间分析

TraceView性能分析

我们在使用APP的时候会经常使用Log去看一下运行时间的问题，运行时间的时长与用户体验有直接的关系。而这种通过Log计算的方式计算出来的时间影响因素有很多，因此我们需要对运行时间有一个更为准确的分析。通过TraceView我们就可以分析每个函数具体的运行时间占用的CPU的时长等等。

同时往往存在内存泄漏的地方运行时间也会更长，因此在这里说明使用TarceView进行的分析。

TraceView文件的生成

这个文件的后缀是.trace，我们可以有很多种方式进行分析结果的采集，由于在工具中直接进行采集效果不好，推荐在代码中人工进行采集。

采集的方法是：在怀疑造成使用卡顿的开始以及结尾处加入下面两句话：

//这里的参数可以为空，不为空的时候文件名指定为我们设置的文件名
Debug.startMethodTracing("test.trace");
//结束Trace
Debug.stopMethodTracing();

例如我们可以在Activity的onCreate开始的时候进行跟踪，在结束的时候结束跟踪，这样就可以分析Activity创建的耗时分析。

在这两句之间的执行的每个函数都会反映在最终的trace文件中。

生成的trace文件的目录（不修改的前提下）在手机的sdcard中。

TraveView的位置

TraceView可以通过在AndroidStudio中的tools->Android Device Monitor也就是DDMS中直接打开，想对一个TraceView的文件进行分析的话，直接通过File->open即可进行展示。

TraceView的UI展示

首先通过一张图来帮助说明：

上半部分是TimePanel，下班部分是ProfilePanel；

TimePanel

在TimePanel的黑色区域我们可以通过十字架的位置，看到上面显示的函数信息以及调用时间等。

左边的部分显示不同的线程信息，我们可以通过十字架来观察对应的运行。

ProfilePanel

这部分的内容很多，也是我们进行性能分析时经常用的部分。解释上面各列参数的含义:

列名	含义
Inclu CPU Time	函数以CPU时间为单位的运行时间，包含内部调用其他函数的时间
Exclu CPU Time	函数以CPU时间为单位的运行时间，不包含内部调用其他函数的时间
Inclu Real Time	函数以毫秒为单位的实际运行时间，包含内部调用其他函数的时间
Exclu Real Time	函数以毫秒为单位的实际运行时间，不包含调用其他函数的时间
CPU Time/Call	函数执行的总CPU时间/总调用次数也就是平均运行时间(以CPU时间为单位)
Real Time/Call	函数执行的总实际时间/总调用次数也就是实际的平均运行时间（以毫秒为单位）
Call+Recur Calls/Total	函数调用次数以及递归调用次数的和/总调用次数

在这里我们比较关注的两个列就是CPU Time/Call以及Call+Recur Calls/Total。

这两列的数据按照降序进行排序会反应出系统运行时间最长的函数。从上向下分析往往会找到卡顿的原因。

关于启动

我们都知道反应Activity的实际性能的时间是它的diaplay Time，这个时间比Log打出来的事假更稳定也更准确。

在启动的时候往往二次启动也就是Activity已经创建过一次的情况下启动时间会大大减少，这些现象一定程度与我们的代码有关，但不是全部的原因。

因此，在启动的时候如果分析热启动（已经创建过），冷启动（没有创建过）会产生不同的结果，而往往热启动的分析结果会直接暴露出运行时间较长的函数。（热启动减少了一定的类加载时间，减少了分析干扰因素）。

结束语

呼呼呼~~~，写过最认真也最长的文章，之后如果再进行性能分析可能会将本篇博文中不恰当的说法进行修改。

最后这句话是说给我的，希望能做到。