TraceView性能优化工具使用

Traceview布局

---

当你有一个跟踪日志文件，你可以加载Traceview，显示在两个小组的日志数据的日志文件（通过添加跟踪代码，您的应用程序或DDMS生成）：

• 一时间线面板-描述了当每个线程和方法，启动和停止
• 一个轮廓面板-提供了一种方法里面发生了什么事情的总结

一、面板组成

1. Timeline Panel

（1）每一行表示一个线程
（2）每一种不同颜色代表一个不同的方法
（3）每一个bar对应一个方法执行过程，bar的宽度表示方法执行的时长
（4）对于缩小图，bar表示方法开始执行时间；对于放大图，每个方法对应的bar会扩大成一个有色的U型，U型的左边 表示方法开始时间，右边表示方法结束时间
（5）小技巧：双击上面的时间轴可以缩小图，鼠标选中线程的颜色部分轻微水平拉动可以放大图

2. Profile Panel

（1）表示执行的方法列表
（2）任意点击一个方法展开，Parent表示调用该方法的方法，Children表示该方法调用的方法
（3）颜色和Timeline中的颜色含义相同，且选中一个方法会在Timeline中同步高亮
（4）参数解释：
Incl Cpu Time(%)－方法自身及该方法调用的所有子方法所占时间和（百分比）
Excl Cpu Time(%)－方法自身所占时间（百分比）
Incl Real Time(%)－类似于Incl Cpu Time(%)
Excl Real Time(%)－类似于Excl Cpu Time(%)
Calls + Recur Calls/Total－调用次数＋递归调用次数。或某子方法被该父方法调用的次数／某子方法被所有方法调用的总次数。

Cpu Time/Call－方法调用一次所占Cpu Time。[Calls + Recur Calls/Total] * [Cpu Time/Call] = [Incl Cpu Time]
Real Time/Call－方法调用一次所占Real Time。[Calls + Recur Calls/Total] * [Real Time/Call] = [Incl Real Time]
关于Cpu Time和Real Time的区别 ：
Cpu Time指的是方法执行所占用的cpu时间，不包括中间的等待时间

Real Time指的是方法从开始执行到结束执行总的时间，包括中间的等待时间

二、关于分析方法

性能问题通常分为两类：
（1）调用次数不多，但每次耗时长的方法
（2）自身耗时不长，但频繁调用的方法
关于第一种，通常做法是先按Cpu Time/Call降序排序，然后看Incl Cpu Time的大小，综合起来越大的性能问题越严重
关于第二种，通常做法是按Calls + Recur Calls/Total降序排序，然后看Incl Cpu Time的大小，综合起来越大的性能问题越严重

总的来说，还是要自己多试验多体会，具体问题具体分析。

三、分析实例

问题查找：

1. Calls + Recur Calls / Total 重要指标！

它表示这个方法执行的次数，这个指标中有两个值，一个Call表示这个方法调用的次数，Recur Call表示递归调用次数，引用我在做的一个阅读项目，视图如下：

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

2.Inc Cup Time: 表示CPU占用率8.4% ，

3.Inc Cup Time：160.958毫秒。 这已经很高了，说明问题一定在这里。

4.Cup Time/Call:160.958毫秒。偏高。

5.Name:重点分析函数：

• Parent:无视 （一般都100%）
• Children: booksTojson 这个函数CPU占用率高达96.6%,这就很尴尬了，是一个Gson解析方法，竟然这么耗时,这是可以优化性能的地方。

问题分析及解决方案：

既然问题定位了，我又重点撸了一遍这个函数相关代码，发现了蛛丝马迹，于是我重构了函数逻辑，并使用JackSon 代替GSON 解析工具，结果速度、时间都有显著优化。

欢迎更多开发朋友加群：

群名称：Android性能分析

群号：570847156