Android开发——利用Systrace工具优化AndroidApp的运行性能

###信条

• 用数据说话&＃xff1a;在细微的差别面前大部分人无法感知辨别&＃xff0c;在每一次优化代码后使用如下将介绍的工具进行检验。
• 使用低性能机器测试&＃xff1a;低性能的机器会更多地暴露问题。
• 意识到等价交换的思想&＃xff1a;所有优良代码之上的优化都是基于等价交换&＃xff0c;而这其中基本上都是以空间换时间。

• 内核部分&＃xff1a;Systrace 利用了Linux Kernel 中的 ftrace 功能。所以&＃xff0c;如果要使用 Systrace 的话&＃xff0c;必须开启 kernel 中和 ftrace 相关的模块。
• 数据采集部分&＃xff1a;Android 定义了一个 Trace 类。应用程序可利用该类把统计信息输出给 ftrace。同时&＃xff0c;Android 还有一个 atrace 程序&＃xff0c;它可以从 ftrace 中读取统计信息然后交给数据分析工具来处理。
• 数据分析工具&＃xff1a;Android 提供一个 systrace.py&＃xff08;python脚本文件&＃xff0c;位于Android SDK 目录 /tools/systrace 中&＃xff0c;其内部将调用 atrace 程序&＃xff09;用来配置数据采集的方式&＃xff08;如采集数据的标签、输出文件名等&＃xff09;和收集 ftrace 统计数据并生成一个结果网页文件供用户查看。

Systrace使用方式 有两种&＃xff1a;

• 1.Device Monitor
• 2.命令行

  $ cd android-sdk/platform-tools/systrace $ python systrace.py --set-tags&＃61;gfx,view,wm $ adb shell stop $ adb shell start

ps:先在设备中打开Settings > Developer options > Monitoring > Enable traces。

抓取的信息使用浏览器打开如下&＃xff1a;

我们来选取一个Alert来看一下&＃xff1a;

可以看到Alert原因是Long View#draw&＃xff08;&＃xff09;&＃xff0c;下面还会有相关文档链接。选择Frame这一行&＃xff0c;就能看到每一帧的渲染&＃xff0c;通过不同的颜色发现一些问题&＃xff0c;我们来选择红色的一帧&＃xff1a;

在底部&＃xff0c;有三个Alert信息&＃xff0c;打开“Inflation during ListView recycling”&＃xff1a;

看这部分耗费的时间&＃xff0c;32ms&＃xff0c;超过了保证60fps的16ms。再看下面细分每一步耗费的时间&＃xff0c;有5个obtainView都消耗了大约 5ms。Description指出了问题所在&＃xff0c;没有使用ListView的复用机制造成inflate单个Item成本过高。再看上面的图形部分&＃xff0c;它将 所有的东西都可视化&＃xff0c;我们放大来看“inflate”&＃xff1a;

在选择一帧之后&＃xff0c;可以通过“m”键显示具体耗费的时间。可以看到耗费超过19ms渲染这一帧。展开这一帧唯一的一个Alert&＃xff0c;看到“Scheduling delay”。选择最长的DrawFrame来看一下&＃xff1a;

Wall duration是从时间片的开始到结束。CPU Duration是CPU的实际运行时间。注意这两个时间的巨大差别&＃xff0c;来看一下CPU这段时间做了什么&＃xff1a;

四个核心都处于忙碌状态&＃xff0c;选择一个Thread看它从哪里发起&＃xff0c;一个包名为com.udinic.keepbusyapp。原来是其它app的原 因。这种情况通常是暂时的&＃xff0c;因为其它app不太可能在后台长时间占用CPU&＃xff0c;这些线程可能来自你的App的其它进程&＃xff0c;或者是主进程。由于Systrace 是以系统的角度返回一些信息&＃xff0c;要进一步获取CPU满负荷运行的原因&＃xff0c;我们来使用另一个工具Traceview。

###TraceviewTraceview是一个很好的性能分析工具。它可以通过图形化的方式让我们了解我们要跟踪的程序的性能&＃xff0c;并且能具体到method&＃xff1a;

使用方式同样有两种&＃xff0c;Android Device Monitor或者使用代码&＃xff0c;参考 这里 .

我们来看一下不同列代表的含义&＃xff1a;

• Name&＃xff1a;method的名称&＃xff0c;前面有一个和上图对应的颜色标识。
• Inclusive CPU Time&＃xff1a;此方法和子方法调用占用的CPU时间。
• Exclusive CPU Time&＃xff1a;此方法单独调用占用的CPU时间。
• Inclusive / Exclusive Real Time&＃xff1a;从方法开始到结束的时间&＃xff0c;类似于“Wall Duration“。
• Calls&＃43;Recursion&＃xff1a;调用次数。
• CPU/Real time per Call&＃xff1a;每次调用平均占用的CPU时间。

我打开了一个不能平滑滚动的App&＃xff0c;开始跟踪&＃xff0c;滚动以下部分&＃xff0c;停止跟踪。找到getView&＃xff08;&＃xff09;方法&＃xff0c;展开&＃xff1a;

这个方法调用了12次&＃xff0c;每次CPU时间3ms&＃xff0c;但是每次调用的真实时间是162ms&＃xff0c;绝对有问题&＃xff01;

查看这个方法下地Children&＃xff0c;Thread.join()耗费了约98%的inclusive real time。这个方法是用来等待其他线程结束。另一个children是Thread.start(),由此认定getView()方法启动了一个线程并等 待它结束。

但是这个线程在哪&＃xff1f;

我们不知道这个getView()中的线程做了什么&＃xff0c;因为getView()中没有直接启动它。为了找到它&＃xff0c;我查找了Thread.start()方法。最终发现了它&＃xff1a;