Android性能分析工具——TraceView

四 05 三月 2015
起因

最近一直都是在忙活后台的东西，然后突然客户那边儿说你们的App做好了没？唔，好像还没有，然后就赶紧开始调试之前扔掉的Android应用，由于这个App是通过WiFi控制LED灯的，所以并不是由我们独立来做的，首先是由硬件团队做出硬件控制板以及相应的SDK，我们在他们的基础上做上层应用。

但是一直有个问题，我写的Demo中，只要发现了LED设备，可以进行很快速的操控，十秒钟内基本上可以进行7到8次左右的开关灯操作，但是由我们的Android小伙伴集成到我们之前做好的UI界面中，效果就完全不一样了，卡得要死要死的了，很明显这样儿的产品客户是不会同意的，所以我就准备赶紧解决掉这个问题，避免客户爆豆。。。

既然要分析性能了，那就肯定要借助工具来了，Android性能分析的工具有很多，而且是内置了也有好多，今天我们这里用到的是TraceView，因为熟悉我的同学也都知道我只是个打酱油的，所以边学边总结。

TraceView如何使用

TraceView有两种使用方式。

一种方式是直接打开DDMS

不管你用的是Idea还是Eclipse，都可以，大致如图所示:

img

等“Start Method Profiling”按钮编程一个黑色的小方块了之后，就表示它正在记录，点击停止之后，你就可以看到如下图所示的效果了:

img

然后你就可以好好分析一下为啥各项指标是否达标以及哪里出了问题了，当然需要注意的是这种方式使用起来虽然比较方便但是范围过大，不够精确，如果要实现对一个方法的略为精准的分析的同学可以继续往下看。

另一种方式是直接在你个人觉得可能比较耗时的地方写上如下代码，例如，我们现在怀疑onCreate()方法耗时严重，那么我们就可以填写如下代码：
    @Override
    protected void onCreate(Bundle savedInstanceState){
        // TODO Auto-generated method stub

        Debug.startMethodTracing("DemoTrace");
        //中间是我的各项操作
        doSomething();
        Debug.stopMethodTracing();
    }

这样儿运行之后你得sd卡根目录会生成“DemoTrace.trace”这样一个log文件，它记录了这段时间内的运行信息，把它从手机里pull出来就可以。。。唔对，继续用DDMS工具打开了，这种方式会比上一种方式更加精确，相当于定向爆破，但也很有可能会因为你自己掌握不好方向，爆破错了反而适得其反，所以我个人觉得两种方式结合起来用还是很不错的。

TraceView中的指标

不过很多同学就要问了，这图太乱了，方法这么多，怎么看啊，我也是新手，真是无比头大，所以尽量还是参照一下官方文档--Profiling with Traceview and amtracedump。

根据官方文档的介绍，Traceview总共有两个面板：

一个是Timeline Panel，即时间线面板，如下图：

img

Timeline Panel展示了每个线程的执行情况，其中的[3]main是UI主线程，将鼠标移动到某个位置可以查看该点对应的方法的执行信息，可以选择用左键按住不放，选中区域放大局部查看详细的，不同的方法采用不同的颜色标注。不过，跟我一样色弱（也可以直呼为瞎）的同学可以考虑静静的看一下就好，总之就是各种颜色不敏感。。。所以我们关注另外一个。。。

另一个是Profile Panel，即性能面板（暂且就这么翻译吧，大家理解意思就好），如下图：

img

Profile Panel展示了所有方法的执行情况，点击某个方法可以查看对应线程上得执行时间区域，并且会显示其父方法和子方法。

每个方法包括如下信息列，可以点击根据某列进行排序，从而确定产生性能问题的函数： Icnl Cpu Time， Excl Cpu Time， Incl Real Time， Incl Cpu Time%， Excl Cup Time%， Incl Real Time%， Calls+RecurCalls/Total， Cpu Time/Call， Real Time/Call， 所有的Time都是以毫秒计算的。

  1. Incl表示将所有子函数耗时计算在内的调用时间，Excl则表示不包括子函数的调用时间，通过将这两项进行对比，基本就可以确定耗时的操作到底是发生在自身函数中，还是发生在子函数中。
  2. Cpu Time表示占用Cpu执行的时间，Real Time则包括Cpu Time以及其他的等待或者切换的时间，所以一般情况下Real Time肯定大于Cpu Time，通过将这两项进行对比可以基本判断耗时的操作是否发生在Cpu执行段内。
  3. Calls+RecurCalls/Total表示被外部调用次数+递归次数/总次数，通过该项可以查看相应的函数的调用次数是否在自己的预期以内。
  4. Cpu Time/Call， Reall Time/Call表示总的Cpu Time及Real Time与总次数的比例，如果觉得这些所有的指标都太复杂的话，想要查看每次调用的耗时的时候，一般就可以直接通过该项指标来确定每个函数的性能。

当然，还有其他的很多Android的性能分析工具，后续如果有时间的话，我也会选择性的看看学习一下如何使用。但是总的来说，性能优化基本上是个很庞大的话题，涉及到方方面面的知识也很多，在Android开发方面我很多时候也只是为了解决问题而解决问题，慢慢积累吧。

Category: Android Develop

Comments