android performance analyse

讲三个Android上的性能分析工具：TraceView，Systrace，以及GPU呈现分析模式。

（PS：我只是可以用这三种工具获得测试结果，具体的分析并不是很在行，我发现这方面的资料奇少。）

一、TraceView

这是三个工具里面目前最最方便的，主要是Eclipse里面集成了这个工具，并不需要你写代码。

步骤：1）打开DDMS窗口（如果界面上没，则Window->Open Perspective->DDMS）；2）在DDMS界面上打开Devices视图（如果没有，则Window->Show

View->Devices），打开虚拟机或者连上你的真机，大致会得到下面的情况：

有设备，有运行的程序，Devices旁边有一排按钮，现在除了“虫子”亮着之外，全是暗的，请选中你要测试的程序，现在按钮全亮，看到这个按钮没有？OK，照着下面的步骤去做：

1）打开你的应用程序；

2）当你想测试某个动作的性能的时候，在动作开始之前，点击这个按钮；

3）做动作（比如滚动ListView），动作完成之后，还是点击这个按钮（注意！！不是旁边的Stop按钮，点击那个得不到结果）

3）之后，你将得到如下的图片（Eclipse会自动显示，不需要你做任何的操作）：

我简单讲一下分析方法吧，具体的可以去developer.android.com上搜索TraceView获得。

这幅图片反映了你操作过程中涉及到的所有函数调用所消耗的资源，包括所占CPU的时间，其中Incl表示自己本身代码执行的时间加上所有子函数调用的时间，而Excl则仅仅表示自己本身代码执行的时间，上半部分是按照每个线程的函数调用绘制的时间流调用图，而下半部分则是按照资源消耗程度从大到小排序的，其中0（toplevel）应该是系统级别的线程，它的时间全是100%的，所以，下面的百分比全是以它为基准计算，比如，1的Incl Cpu Time%为85.0%，就是1548.292/1822.001得到的，正常情况下，排在前面的函数应该都是一些系统底层的函数，而不应该出现你自己写的函数，假如你有一个函数跑到很前面，比如已经达到40%（参考值，我看自己的程序一般在12%以下）以上，那么那个函数肯定是有问题了，网上有人专门写了一个函数做测试，已经达到89%以上了，果断需要修改，止于后面的一些数字，看完开发者文档（很老了，图片都已经和最新的不一样了，而且说的不清楚）会了解一些，我以后会经常看看这些参数，看看能不能有新发现（比如理解开发者文档上说的那个多次调用中有一次不正常，到底是怎么回事！）

二、Systrace

这个工具使用起来就比较复杂了，因为必须从命令行入手，对手机（注：我在模拟器上始终不能使用，报文件无法找到的错误，换成真机即可）系统的要求是4.1以及以上。OK，开始吧。步骤如下：

1）在命令行下输入adb，看看能否找到命令（这是一个检测步骤，看看你的adb是否在环境变量下），如果找不到，请配置好环境再继续，直到adb命令正常运行；

2）在你的SDK安装目录下有一个文件夹android-sdks/tools/systrace，打开systrace文件夹：

里面有一个文件，叫做systrace.py。这个就是我们获取测试结果的脚本。

3）打开设置->开发者选项->4.1版本上，这边有一个选项启用跟踪选项，点击它，选择Graphics和View，还可以选择其他选项（注：可以去developer.android.com网站上，搜索Systrace，会获得这边具体的教程，还有各种命令行参数）；

4）打开你要测试的应用，运行命令python systrace.py -t 10开始测试（-t 10是一个参数，这个工具会获得非常多的数据，你必须做出限制，这里的参数表示对接下来的10s内的操作进行录制分析）；

5）10s过后会在命令行里面显示录制文件的存储地址，不指定的话适合systrace.py文件存储在一起，和上图一样，为trace.html。可以直接在浏览器中打开。

图打开大致如下：

这幅图片里面是有范本的：SurfaceFinger。

上面这幅图片上面有一段特别绵密有规律的，这就是Systrace的评价标准：竖线要尽量窄，要有规律。而上面这段后半部分虽然窄，但是没有规律，是因为有别的线程特别耗时干涉了它，这个时候就需要去分析，方法同样在开发者网站上面，我还没研究透。

三、GPU呈现分析模式

这种模式已经有一篇文章讲述的很详细了，顺带着对上面两种方式也有阐述：http://blog.chengyunfeng.com/?p=458#。读者可以参考。（在使用方法2）成功之后，要使用本方法已经很简单了：改变设置，输入命令行）。

这个方法可以让你看出你的APP哪里被过度绘制了，比如头像。因为需要做很多的效果，比如阴影，边框，需要用到很多的图片，很容易造成某一块被过度绘制（也就是绘制多次，但又没有实际意义），可以通过这种方式看出并且想办法修正。

 

四、总结

以上三种方式都有一定的作用，可以让你从总体上感受程序的性能，做出一定的改进。但是：

1）很遗憾，三种方式中，尤其是前两种，没有给出测试结论和改进意见，只有测试数据，需要自己分析，而且资料不全，不能发挥出应有的全部功效；

2）虽然全部可以图形化，但是依旧不够直观，需要自己去分析原因；

3）最重要的还是自己在写程序的时候要注意优化性能，比如异步线程等等，要适当使用，分化任务，遵循编程规范（我一直比较怀疑第二中测试方法中是否将程序中的方法分化成小方法就可以得到好看的窄竖条）

 

我会持续使用三种方法，争取掌握三种方法的分析手段，优化APP。到时分享。