如何对 Android 应用进行性能分析

记录一下自己在使用DDMS的过程：开启AS，打开并运行项目  找到TOOL/选择Android Device Monitor

一款 App 流畅与否安装在自己的真机里，玩几天就能有个大概的感性认识。不过通过专业的分析工具可以使我们更好的分析我们的应用。而在实际开发中，我们解决完当前应用所有 bug 后，就会开始考虑到新能的优化。如果不考虑使用其他第三方性能分析工具的话，我们可以直接使用 ddms 中的工具，其实 ddms 工具已经非常的强大了。ddms 中有 traceview、heap、allocation tracker 等工具都可以帮助我们分析应用的方法执行时间效率和内存使用情况。

traceview

TraceView 简介

Traceview 是 Android 平台特有的数据采集和分析工具，它主要用于分析 Android 中应用程序的 hotspot（瓶颈）。Traceview 本身只是一个数据分析工具，而数据的采集则需要使用 AndroidSDK 中的 Debug 类或者利用 DDMS 工具。 
二者的用法如下： 
开发者在一些关键代码段开始前调用 Android SDK 中 Debug 类的startMethodTracing 函数，并在关键代码段结束前调用 stopMethodTracing 函数。 这两个函数运行过程中将采集运行时间内该应用所有线程（注意，只能是 Java 线程）的函数执行情况，并将采集数据保存到/mnt/sdcard/下的一 
个文件中。开发者然后需要利用 SDK 中的 Traceview 工具来分析这些数据。 
借助 Android SDK 中的 DDMS 工具。DDMS 可采集系统中某个正在运行的进程的函数调用信息。对开发者而言，此方法适用于没有目标应用源代码的情况。DDMS 工具中 Traceview 的使用如下图 

点击上图中所示按钮即可以采集目标进程的数据。当停止采集时，DDMS 会自动触发 Traceview 
工具来浏览采集数据。 
下面，我们通过一个示例程序介绍 Traceview 的使用。界面有 4 个按钮，对应四个方法。

public class MainActivity extends ActionBarActivity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);}public void method1(View view) {int result = jisuan();System.out.println(result);}private int jisuan() {for (int i = 0; i < 10000; i++) {System.out.println(i);}return 1;}public void method2(View view) {SystemClock.sleep(2000);}public void method3(View view) {int sum = 0;for (int i = 0; i < 1000; i++) {sum += i;}System.out.println("sum=" + sum);}public void method4(View view) {Toast.makeText(this, "" + new Date(), 0).show();}
}

我们分别点击按钮一次，要求找出最耗时的方法。点击前通过 DDMS 启动 Start Method Profiling按钮。 
 
然后依次点击 4 个按钮，都执行后再次点击上图中红框中按钮，停止收集数据。 
接下来我们开始对数据进行分析。 
当我们停止收集数据的时候会出现如下分析图表。该图表分为 2 大部分，上面分不同的行，每一行代表一个线程的执行耗时情况。main 线程对应行的的内容非常丰富，而其他线程在这段时间内干得工作则要少得多。图表的下半部分是具体的每个方法执行的时间情况。显示方法执行情况的前提是先选中某个线程。 

我们主要是分析 main 线程。 
上面方法指标参数所代表的意思如下：

我们为了找到最耗时的操作，那么可以通过点击 Incl Cpu Time，让其按照时间的倒序排列。我点击后效果如下图：

通过分析发现：红色部分最耗时

heap

heap 简介

heap 工具可以帮助我们检查代码中是否存在会造成内存泄漏的地方。 
用 heap 监测应用进程使用内存情况的步骤如下： 
1．启动 eclipse 后，切换到 DDMS 透视图，并确认 Devices 视图、Heap 视图都是打开的； 
2．点击选中想要监测的进程，比如 system_process 进程； 
3．点击选中 Devices 视图界面中最上方一排图标中的“Update Heap”图标； 
4．点击 Heap 视图中的“Cause GC”按钮； 
5．此时在 Heap 视图中就会看到当前选中的进程的内存使用量的详细情况。 
说明： 
a. 点击“Cause GC”按钮相当于向虚拟机请求了一次 gc 操作； 
b. 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap 视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化； 
c. 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。 
如何才能知道我们的程序是否有内存泄漏的可能性呢？ 
这里需要注意一个值：Heap 视图中部有一个 Type 叫做 data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在 data object 一行中有一列是“Total Size”，其值就是当前进程中所有 Java 数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： 
1、 不断的操作当前应用，同时注意观察 data object 的 Total Size 值； 
2、 正常情况下 Total Size 值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚机不断的进行 GC 的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平； 
3、反之如果代码中存在没有释放对象引用的情况，则 data object 的 Total Size 值在每次 GC 后不会有明显的回落，随着操作次数的增多 Total Size 的值会越来越大，直到到达一个上限后导致进程被 kill 掉。 
4、此处以 system_process 进程为例，在我的测试环境中 system_process 进程所占用的内存的data object 的 Total Size 正常情况下会稳定在 2.2~2.8 之间， 而当其值超过 3.55 后进程就会被kill。 
总之，使用 DDMS 的 Heap 视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。

allocation tracker

allocation tracker 简介

allocation tracker 是内存分配跟踪工具 
步骤： 
运行 DDMS，只需简单的选择应用进程并单击 Allocation tracker 标签，就会打开一个新的窗口，单击“Start Tracing”按钮；然后，让应用运行你想分析的代码。运行完毕后，单击“Get Allocations”按钮，一个已分配对象的列表就会出现第一个表格中。单击第一个表格中的任何一项，在表格二中就会出现导致该内存分配的栈跟踪信息。通过 allocationtracker，不仅知道分配了哪类对象，还可以知道在哪个线程、哪个类、哪个文件的哪一行。