在构建功能，修复bug，整理代码之后，你应该花一些时间来关注应用的性能。应用画像素和执行操作的速度和流畅度影响了用户体验。
Android应用运行在一个共享资源的环境中，你的应用的性能会被与其交互的系统资源的效率所影响。应用也运行在一个多线程的环境中，与其它拥有线程的进程争夺资源，可能会引起很难诊断的性能问题。
Systrace工具允许你收集和审查应用和Android系统的代码执行数据，你可以使用这些数据诊断执行中的问题以提升应用的性能。
- 概述
Systrace帮助你分析应用程序执行是怎么融入更大的Android系统的，让你在公共时间轴上看到系统和应用进程的执行。这个工具允许你在4.1或者更高的版本生成更加详细的，可互动的报告，比如下图1的报告。
应用进程运行5s后的Systrace报告
- 生成Traces
为了创建应用的trace文件，你必须执行一系列的操作，首先，要有一个运行了Android 4.1或者更高版本的设备，设置设备允许调试，连接到开发系统，装上应用。一些类型的trace信息，特别是磁盘活动和内核工作队列，需要你有root权限，但是，大部分trace数据之需要设备允许开发者调试。
Systrace 可以通过命令行和用户界面启动，本向导主要讲通过命令行的方法。
- 限制trace数据
Systrace工具可以生成应用和系统的潜在的巨大数据，为了限制工具收集的数据量，使数据与分析相关，使用下面的选项：
1.限制trace抓取的时间使用-t，--time选项，默认的trace时长是5s
2.限制trace抓取数据的size使用-b，--buf-size选项
3.指定哪些类型的进程被跟踪。可以被跟踪的进程在不同的Android版本上面略有不同：
Android4.2和低于4.2的：使用--set-tags选项和--disk，--cpu-freq，--cpu-idle，--cpu-load选项
Android4.3和高于4.3的：使用--list-categories选项来查看类型列表
- 在4.3和大于4.3的版本抓取trace信息
1.确保设备通过usb调试选项打开，并成功连接到电脑
2.指定要抓取的选项来执行trace，例如
$ cd android-sdk/platform-tools/systrace
$ python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
3.在设备上，执行任何你想要被包含进trace信息的操作
- 在4.2和低于4.2的版本抓取trace信息
在4.2和低于4.2的设备上面使用trace，为了提高效率，你必须在抓取之前配置想要跟踪的进程类型，工具可以收集下面进程类型的信息：
1.通常的系统进程，比如graphics，audio和input进程（使用trace category tags选择）
2.低级别的系统信息，比如CPU，kernel和磁盘活动(使用options选择)
使用下面的命令设置Systrace的tags：
1.使用--set-tags选项：
$ cd android-sdk/platform-tools/systrace
$ python systrace.py --set-tags=gfx,view,wm
2.重启adb使这些进程跟踪生效
$ adb shell stop
$ adb shell start
当你配置完trace的category tags，就可以开始收集信息来进行分析。
使用现在的trace tag设置来运行trace：
1.确保设备adb连接成功
2.执行trace并设定低级别的trace选项，限定选项等
$ python systrace.py --cpu-freq --cpu-load --time=10 -o mytracefile.html
3.在设备上，执行任何你想要被包含进trace信息的操作
- 跟踪应用代码
Systrace工具可以跟踪应用代码的执行，在4.3或者更高的版本，你可以使用Trace类的方法来添加标志到应用的代码，然后在Systrace报告中查看结果。
下面的代码显示了怎么使用Trace类来跟踪应用方法的执行，包括两个嵌套的代码块。
public void ProcessPeople() {Trace.beginSection("ProcessPeople");
try {
Trace.beginSection("Processing Jane");
try {
// code for Jane task...
} finally {
Trace.endSection(); // ends "Processing Jane"
}
Trace.beginSection("Processing John");
try {
// code for John task...
} finally {
Trace.endSection(); // ends "Processing John"
}
} finally {
Trace.endSection(); // ends "ProcessPeople"
}
}
当trace方法嵌套时，endSection()方法结束最近的beginSection(String)方法。这意味这一个在其他trace中开始的trace，不可能超过外围trace的结束位置，所以要确保开始和结束方法的位置在想要测试的进程中是合适的。
Traces必须在同一个线程中调用begin和end方法，不能在一个线程中调用begin，而在另一个线程中调用end。
当使用应用级别的跟踪时，必须在用户界面设置应用的包名或者使用-a，--app=选项
- 分析Traces
当使用Systrace工具生成trace后，它列出了输出文件的位置，你可以打开使用web浏览器打开报告。怎么使用trace收集的数据依赖与你要分析的性能问题。但是本章提供了一些通用的分析trace的方法。
Systrace生成的报告是可交互的，允许你放大缩小察看进程执行的细节，W键放大，S键缩小，A键往左移，D键往右移。在时间轴上面选择一个任务，使用鼠标来获取这个任务更多的信息。
长时间运行的进程
一个良好的应用程序迅速而且有规律地执行许多细小的操作，一些操作的几毫秒内完成，根据进程所在的设备有所不同，就在图2显示的
图2的trace显示了一个运行良好的应用进程有一个有规律的节奏(1),图2下面的区域放大了虚线圈起来部分，它显示了在运行过程中的一些不规则。特别是，2标记的一个稍微宽一点的task条，花费了稍微长一点的时间(14ms),相比其他的，线程里相似的任务，平均在9到12毫秒就可以完成。这个特殊的任务执行的时长貌似没有被用户注意到，除非它在特殊的时间影响另一个进程，比如屏幕更新。
长时间运行的进程如果有一些bars比正常执行的bars宽，说明你的应用中有性能问题。当trace中出现这个问题时，点击引起问题的task获取更加详细的信息，你也应该关注同一时间运行的其他进程，寻找被其他进程阻塞的进程中的线程。
- 显示执行中断
Systrace工具分析应用显示慢或者动画停止是非常有用的，因为它显示了应用在多个系统进程中的执行。对于显示的执行，有规律节奏地绘制屏幕帧是良好的性能不能缺少的。有节奏规律地显示确保了屏幕上动画和移动的平滑。如果应用退出了这个节奏，从用户方面来看，显示会变得卡顿或者慢。
如果你正在分析应用这种类型的问题，检查Systrace报告中应用程序执行的SurfaceFlinger进程，来寻找退出有规律节奏的位置。
图3 显示处理中断
图3显示了显示中断的区域，这个区域在SurfaceFlinger进程中，图示中的（1）位置，表明了显示帧的丢失。丢帧可能会导致显示卡顿或停止。进入下方trace的问题区域，显示了surfaceFlinger进程的内存操作花费时间过长。这个延时导致了应用widows显示的丢失。作为这个应用的开发者，你应该检查应用中的其他线程是否在同一时间尝试分配内存或者其他的请求和任务阻塞了内存分配。
SurfaceFlinger进程有规律节奏地执行是屏幕内容显示平滑的必要条件，特别是对动画和移动来说。线程中有规律的执行被打断并不一定都意味着是应用显示问题，需要从用户的角度更进一步的测试来确定是不是性能问题。能够识别正常的显示执行信息可以帮助你检测显示问题，构建一个平滑运行，高性能的应用。
当使用Systrace来分析显示问题，确保你设置了Graphics和Views tag。