Android性能分析工具Traceview的使用
2016-06-14 16:02
330 查看
如何使用TraceView
使用TraceView主要有两种方式:最简单的方式就是如上图,直接打开DDMS,选择一个进程,然后按上面的“Start Method Profiling”按钮,等红色小点变成黑色以后就表示TraceView已经开始工作了。然后我就可以滑动一下列表(现在手机上的操作肯定会很卡,因为Android系统在检测Dalvik虚拟机中每个Java方法的调用,这是我猜测的)。操作最好不要超过5s,因为最好是进行小范围的性能测试。然后再按一下刚才按的按钮,等一会就会出现下面这幅图,然后就可以开始分析了。
第2种方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法,当运行了这段代码的时候,就会有一个trace文件在/sdcard目录中生成,也可以调用startMethodTracing(String traceName) 设置trace文件的文件名,最后你可以使用adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中,然后用DDMS工具打开就会出现第一幅图了。
第一种方式相对来说是一种简单,但是测试的范围很宽泛,第二中方式相对来说精确一点,不过我个人喜欢使用第一种,因为简单,而且它是检测你的某一个操作。因为第二中更适合检测某一个方法的性能,其实也没有那种好,看使用的场景和喜好了。
Traceview的界面
整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值。上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行,因为我滑动了一下列表,main线程(UI线程)正在进行绘制View呢~
然后我点击了序号为133的一个方法:io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView,就会出现两部分数据:
Parents
Children
Parents表示调用133这个方法的父方法,可以看到序号为130。Children表示方法133调用的其他方法,可以看到有好几个方法。
看懂TraceView中的指标
纵轴
TraceView界面下方表格中纵轴就是每个方法,包括了JDK的,Android SDK的,也有native方法的,当然最重要的就是app中你自己写的方法,有些Android系统的方法执行时间很长,那么有很大的可能就是你app中调用这些方法过多导致的。每个方法前面都有一个数字,可能是全部方法按照Incl CPU Time 时间的排序序号。
点一个方法后可以看到有两部分,一个是Parents,另一个是Children。
Parent表示调用这个方法的方法,可以叫做父方法
Children表示这个方法中调用的其他方法,可以叫做子方法
横轴
Incl Cpu Time
Incl Cpu Time表示:这个方法以及这个方法的子方法(比如top方法中的a、b、c、d方法)一共执行的时间方法top执行的总时间。假如说方法top的执行时间为10ms,方法a执行了1ms,方法b执行了2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间要小一点)。
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了。
Incl Real Time
这个感觉和Incl Cpu Time 差不多,第7条会讲到。
Excl Real Time
同上
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这个方法是SimpleAdapter的getItemView方法)
对于一个adapter的getView方法来说0.643ms是非常快的(因为这个adapter中只有一个TextView,我为了测试用的)
如果getView方法执行时间很长,那么必然导致列表滑动的时候产生卡顿现象,可以在getView方法的Children方法列表中找到耗时最长的方法,分析出现问题的原因:
是因为有过多的计算?
还是因为有读取SD卡的操作?
还是因为adapter中View太复杂了?
还是因为需要有很多判断,设置View的显示还是隐藏
还是因为其他原因…
相关文章推荐
- Android进程间通信之Messenger
- Android多线程—–AsyncTask详解
- android图片压缩,注释很详细
- Android 源码下载及编译
- Layouts
- Android fragment使用详解及案例
- android中颜色的透明度16进制的设置
- Android 自定义view一,Path篇
- Android入门--RadioGroup 组与onCheckedChanged 事件
- Android中的Drawable资源—— ClipDrawable
- android的adb命令总结
- AndroidStudio 查看不到源码中的方法解决办法
- 如何使Android Studio项目发布到Jcenter中
- Android 指定时间执行任务
- Android中的Drawable资源—— InsetDrawable
- android图片的异步加载和双缓存学习笔记——DisplayImageOptions (转)
- 使用jarsigner对APK签名
- Android Studio SVN配置忽略文件
- Android--从零单排系列(6)--相对应对话框popupwindow的优势和使用
- Android 混淆完全解析