正确使用Android性能分析工具——TraceView

标签: Android 开发 | 发表时间:2014-10-27 13:04 | 作者:OKC_Thunder
出处:http://blog.jobbole.com

前面唠叨

最近公司app中有些列表在滑动的时候会有卡顿现象,我就开始着手解决这些问题,解决问题之前首先要分析列表滑动的性能瓶颈在什么地方。因为之前不会正确使用TraceView这个工具,主要是看不懂TraceView界面下方数据指标的值代表什么意思…以前我用 StopWatch类来分析性能,现在觉得弱爆了…不过有些地方 StopWatch工具类还是很简单好用的~

网上可以找了很多博客来介绍这个工具的使用方法,很多都是讲解了一些一些就会的方法,讲一个大概,包括StackOverFlow上我也没有找到很好的讲解TraceView各个数据指标代码什么意思的回答

因为我要解决列表滑动的卡顿问题,就必须要找到导致卡顿现象的原因,我就在StackOverFlow上找着别人零散的回答慢慢琢磨这个工具的使用方法。现在我学会了,至少能看懂每个指标什么意思, 最后发现这个工具实在太强大了!!!

TraceView界面

现来看一下整个界面的图,整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值

上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行,因为我滑动了一下列表,main线程(UI线程)正在进行绘制View呢~

然后我点击了序号为133的一个方法 io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView,就会出现两部分数据:

  • Parents
  • Children

Parents表示调用133这个方法的父方法,可以看到序号为130。Children表示方法133调用的其他方法,可以看到有好几个方法。

如何使用TraceView

因为这次我主要是分析列表滑动卡顿问题,我就讲讲我是怎么使用这个工具的,并且我是怎么分析的。

使用TraceView主要有两种方式:

  1. 最简单的方式就是直接打开DDMS,选择一个进程,然后按上面的“Start Method Profiling”按钮,等红色小点变成黑色以后就表示TraceView已经开始工作了。然后我就可以滑动一下列表(现在手机上的操作肯定会很卡,因为Android系统在检测Dalvik虚拟机中每个Java方法的调用,这是我猜测的)。 操作最好不要超过5s,因为最好是进行小范围的性能测试。然后再按一下刚才按的按钮,等一会就会出现上面这幅图,然后就可以开始分析了。
  2. 第2种方式就是使用 android.os.Debug.startMethodTracing();android.os.Debug.stopMethodTracing();方法,当运行了这段代码的时候,就会有一个trace文件在 /sdcard目录中生成,也可以调用 startMethodTracing(String traceName) 设置trace文件的文件名,最后你可以使用 adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中,然后用DDMS工具打开就会出现第一幅图了

第一种方式相对来说是一种简单,但是测试的范围很宽泛,第二中方式相对来说精确一点,不过我个人喜欢使用第一种,因为简单,而且它是检测你的某一个 操作。因为第二中更适合检测某一个方法的性能,其实也没有那种好,看使用的场景和喜好了。。。

看懂TraceView中的指标

其实我今年7月份就已经开始使用TraceView工具了,但是当时不懂其中每个指标的含义,就没注意到它强大的地方。看不懂界面下方表格中的指标,这些数据其实一点意义都没有。

网上包括Android官网也没有对TraceView工具的使用有详细的说明文档,这点确实比较蛋疼。

纵轴

TraceView界面下方表格中纵轴就是每个方法,包括了JDK的,Android SDK的,也有native方法的,当然最重要的就是app中你自己写的方法,有些Android系统的方法执行时间很长,那么有很大的可能就是你app中调用这些方法过多导致的。

每个方法前面都有一个数字,可能是全部方法按照Incl CPU Time 时间的排序序号(后面会讲到)

点一个方法后可以看到有两部分,一个是Parents,另一个是Children。

  • Parent表示调用这个方法的方法,可以叫做父方法
  • Children表示这个方法中调用的其他方法,可以叫做子方法

横轴

横轴上是很多指标,这些指标表示什么意思真的困扰了我很长一段时间。。。

能够很衡量一个方法性能的指标应该只有时间了吧? 一个方法肯定就是执行时间越短约好咯~~

1. Incl Cpu Time

define  inclusive : 全包括的

上图中可以看到 0(toplevel) 的Incl Cpu Time 占了100%的时间,这个不是说100%的时间都是它在执行,请看下面代码:

public void top() {
    a();
    b();
    c();
    d();
}

Incl Cpu Time表示方法top执行的总时间,假如说方法top的执行时间为10ms,方法a执行了1ms,方法b执行了2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间要小一点)。

而且调用方法top的方法的执行时间是100ms,那么:

Incl Cpu Time
top 10%
a 10%
b 20%
c 30%
d 40%

从上面图中可以看到:
toplevel的 Incl Cpu Time 是1110.943,而 io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time为12.859,说明后者的Incl Cpu Time % 约为1.2%

这个指标表示  这个方法以及这个方法的子方法(比如top方法中的a、b、c、d方法)一共执行的时间

2. Excl Cpu Time

理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了,还是上面top方法的栗子:

方法top 的 Incl Cpu Time 减去 方法a、b、c、d的Incl Cpu Time 的时间就是方法top的Excl Cpu Time 了

3. Incl Real Time

这个感觉和Incl Cpu Time 差不多,第7条会讲到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

这个指标非常重要!

它表示这个方法执行的次数,这个指标中有两个值,一个Call表示这个方法调用的次数,Recur Call表示递归调用次数,看下图:

我选中了一个方法,可以看到这个方法的 Calls + Recur Calls 值是14 + 0,表示这个方法调用了14次,但是没有递归调用

从Children这一块来看,很多方法调用都是13的倍数,说明父方法中有一个判断,但是这不是重点,有些Child方法调用Calls为26,这说明了这些方法被调用了两遍,是不是可能存在重复调用的情况?这些都是可能可以优化性能的地方。

6. Cpu Time / Call

重点来了!!!!!!!!!!

这个指标应该说是最重要的,从上图可以看到,133这个方法的调用次数为20次,而它的Incl Cpu Time为12.859ms,那么133方法每一次执行的时间是0.643ms( 133这个方法是 SimpleAdaptergetItemView方法

对于一个 adaptergetView方法来说0.643ms是非常快的(因为这个 adapter中只有一个 TextView,我为了测试用的)

如果 getView方法执行时间很长,那么必然导致列表滑动的时候产生卡顿现象,可以在 getView方法的Children方法列表中找到耗时最长的方法,分析出现问题的原因:

  • 是因为有过多的计算?
  • 还是因为有读取SD卡的操作?
  • 还是因为 adapterView太复杂了?
  • 还是因为需要有很多判断,设置 View的显示还是隐藏
  • 还是因为其他原因…

7. Real Time / Call

Real Time 和 Cpu Time 我现在还不太明白它们的区别,我的理解应该是:

  • Cpu Time 应该是某个方法占用CPU的时间
  • Real Time 应该是这个方法的实际运行时间

为什么它们会有区别呢?可能是因为CPU的上下文切换、阻塞、GC等原因方法的实际执行时间要比Cpu Time 要稍微长一点。

总结

TraceView是一个非常强大的性能分析工具,因为Android 官网对这个工具的使用介绍文档很少,而且一些中文博客中写的也都是抄来抄去,没有讲到底怎么使用。

最近我在做这方面的性能分析,就慢慢琢磨了这么工具的使用,发现非常强大,写下来总结一下。

Android的性能分析工具还有很多,比如:

  • Eclipse Memory Analyzer Tool 来分析Android app的内存使用
  • Dump UI Hierarchy for UI Atomator,分析UI层级
  • systrace
  • 其他

下图这一条工具栏中有很多性能分析工具~~~

正确使用Android性能分析工具——TraceView,首发于 博客 - 伯乐在线

相关 [正确 android 性能分析] 推荐:

正确使用Android性能分析工具——TraceView

- - 博客 - 伯乐在线
最近公司app中有些列表在滑动的时候会有卡顿现象,我就开始着手解决这些问题,解决问题之前首先要分析列表滑动的性能瓶颈在什么地方. 因为之前不会正确使用TraceView这个工具,主要是看不懂TraceView界面下方数据指标的值代表什么意思…以前我用 StopWatch类来分析性能,现在觉得弱爆了…不过有些地方 StopWatch工具类还是很简单好用的~.

Android应用性能 分析

- - CSDN博客推荐文章
  其实主要是内存方面,内存管理是个永恒的话题. 1.从工具DDMS中,在Sysinfo的tab栏里面有一个Memory usage的选项,通过USB连接Android设备以后很容易抓到图. 在图中可以看到系统随时可以用的内存是Free和Buffers两项,因为我抓图的系统只有128M的内存,所以看上去这部分可用内存已经很少了.

Linux 和 Android 系统性能分析

- - CSDN博客综合推荐文章
作为一名Linux 或 Android 平台的系统工程师,在开发系统新功能外,主要工作就是优化系统性能,使系统上以最优的状态运行,但是由于硬件问题、软件问题、网络环境等的复杂性和多变性,导致对系统的优化变得异常复杂,如何定位性能问题出在哪个方面,是性能优化的一大难题, 从系统入手,阐述由于系统软、硬件配置不当可能造成的性能问题,并且探讨检测系统故障和优化性能的一般方法和流程.

Android 性能分析工具之 TraceView 使用说明

- - CSDN博客推荐文章
TraceView 是 Android 平台配备一个很好的性能分析的工具. 它可以通过图形化的方式让我们了解我们要跟踪的程序的性能,并且能具体到 method. TraceView 是 Android 平台特有的数据采集和分析工具,它主要用于分析 Android 中应用程序的 hotspot. TraceView 本身只是一个数据分析工具,而数据的采集则需要使用 Android SDK 中的 Debug 类或者利用 DDMS 工具.

如何正确地在Android手机上安装国产软件?

- - FreeBuf.COM | 关注黑客与极客
国产软件往往会申请与之功能不符的权限,读取着用户手机信息,开机后就驻足系统,这些对于注重隐私的用户来说都是问题. 如何“干净”地安装国产流氓软件呢. 国产app的全家桶问题一直被大家诟病,一个应用启动后就会“唤醒”其“家族”内的其他应用,有时还会通过其他方式确保应用始终在后台运行;与此同时,很多应用还会申请与之功能完全不符的权限,这些严重破坏了Android系统的体验.

lucene MoreLikeThis性能分析

- - 七磅-d0evi1
最近使用lucene的MoreLikeThis实现一个小型的推荐系统. 语料由短文本构成,本身也还算比较中小等规模:7000w左右(亿级别)的数据量,3G大小的文件. 对需要的Field建完索引后的索引文件大小在4G左右. 本文只是结合自己的实践列出一些注意事项,以做为参考. 一、MoreLikeThis实现原理.

Akka简单性能分析

- - 并发编程网 - ifeve.com
因为最近工作的关系,要把异步任务从应用服务器中拆分到专门的异步处理服务器中. 是采用MQ的方式将任务消息发出,在服务端进行处理,如下图所示:. 这种方案是采用MQ作为中间的媒介,在服务端采用线程池异步处理任务,处理完成之后将结果发送到MQ中,客户端采用侦听的方式得到结果继续进行处理. 这种方案的不足是,可能在某些需求的情况下,需要将结果存放到共享的HashMap或者Threadlocal中进行存放结果,客户端会一直阻塞,直到得到结果,从多线程的角度来说,还是用了共享变量,虽然共享变量可能是线程安全的,但是从并发模型的角度来讲,并不是一个最好的方式.

leveldb性能分析和表现

- Adam - Erlang非业余研究
原创文章,转载请注明: 转载自Erlang非业余研究. 本文链接地址: leveldb性能分析和表现. Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了. 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计. 那么数据库最怕的的随机IO他是如何解决的呢.

分布式事务性能分析

- wangdei - 风轻扬
这两年来,随着NoSQL系统、CAP理论和Eventual Consistency的大热,关于分布式操作要保证强一致还是弱一致性的讨论络驿不绝. 双方各执一词,倾向实现强一致性的一方认为弱一致性满足不了应用开发的需要,倾向实现弱一致性的一方则认为保证强一致性将导致系统性能与可伸缩性难以接受. 弱一致性能否满足应用开发的需求这一点由应用特征决定,难以一概而论,但强一致性对系统性能、可伸缩性和可用性的影响则是可以作技术分析的.

leveldb性能分析和表现

- mbcw - IT技术博客大学习
    Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了. 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计.     那么数据库最怕的的随机IO他是如何解决的呢.     先说随机写,它的写都是先记录到日志文件去的,在日志文件满之前只是简单的更新memtable,那么就把随机写转化成了顺序写.