Android性能分析优化 - TraceView介绍
来源:互联网 发布:如何加淘宝店铺粉丝 编辑:程序博客网 时间:2024/06/06 04:30
大家在Android应用程序的开发过程中,经常会遇到卡顿的问题,如列表滑动卡顿、界面切换卡顿、动画播放卡顿等各种性能问题。这些问题严重影响到APP的使用体验。解决这些问题,通常我们会分析导致卡顿的瓶颈问题,Android自带的TraceView可以方便的查看线程的执行情况,方法的执行时间调用次数以及在总体中的占比等,因此我们可以借助TraceView来分析卡顿的瓶颈问题。
TraceView的使用:
TraceView 分为两个界面TimeLine Panel 和 Profile Panel。
TimeLinePanel 左边显示的是测试数据中所采集的线程信息,右边所示为时间线,时间线上是每个线程测试时间段内所涉及的函数调用信息。这些信息包括函数名,函数执行时间等。我们可以在时间线Panel中移动时间轴,纵轴上边将显示当前时间点中某线程正在执行的函数信息。
这里介绍几个重要的概念
Name: 表示线程运行过程中调用的函数名
Incl CPU Time: 表示函数占用的CPU时间,包含内部调用其它函数的CPU时间 如方法top执行的总时间,假如说方法top的执行时间为10ms,方法a执行了1ms,方 法b执行了 2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间 要小一点)。
Excl Cpu Time: 表示函数占用的CPU时间,但不含内部调用其它函数所占用的CPU时间
Incl Real Time: 表示函数运行的真实时间(以毫秒为单位),内含调用其它函数所占用的真实时间
Excl Real Time: 表示函数运行的真实时间(以毫秒为单位),不含调用其它函数所占用的真实时间
Call+Recur Calls/Total: 表示函数被调用次数以及递归调用占总调用次数的百分比
Cpu Time/Call: 表示函数调用CPU时间与调用次数的比。相当于该函数平均执行时间
Real Time/Call: 表示同CPU Time/Call类似,只不过统计单位换成了真实时间
接下来我们说一下如何利用TraceView来分析性能瓶颈,一般导致卡顿的函数有两种类型:
一类是调用次数不多,但每次调用却需要花费很长时间的函数。
找到hotspot之后我们就需要分析我们的代码,找到优化的方案,重构代码。
有时我们采用上述分析方法产生的干扰信息较多, 对于TraceView还有另外的一种分析方法,如果我们已经知道那个过程卡段,可以在这个过程开始和结束分别添加android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing(); 然后我们重新安装,执行操作,结束后会在sdcard的根目录会生成一个traceView.trace文件(确保手机带有sdcard),我们可以打开TraceView导入该文件分析,接下来的分析和第一种的分析方法是一样的。
TraceView的使用:
我们可以在Android studio 或 Eclipse中打开DDMS,选中要调试的进程,然后点击start method profiling如图:
这时start method profiling的红色小点就会变成黑色如图:
我们就可以在手机或者模拟器上操作比较卡顿的地方,因为这时进程处于debug状态,会比平时更加卡顿。这个操作过程尽量不要太长,避免将来的分析数据太多,干扰瓶颈问题的查找。操作结束后我们就可以点击已经变黑的start method profiling,这时会打开分析界面,如图:
TraceView 分为两个界面TimeLine Panel 和 Profile Panel。
TimeLinePanel 左边显示的是测试数据中所采集的线程信息,右边所示为时间线,时间线上是每个线程测试时间段内所涉及的函数调用信息。这些信息包括函数名,函数执行时间等。我们可以在时间线Panel中移动时间轴,纵轴上边将显示当前时间点中某线程正在执行的函数信息。
Profile Panel 是TraceView的核心界面,我们先在Timeline Panel中选择线程然后在Profile Panel中查看对应想成的调用情况,包括CPU使用时间,调用次数等信息,而这些信息证实查找瓶颈的关键。
这里介绍几个重要的概念
Name: 表示线程运行过程中调用的函数名
Incl CPU Time: 表示函数占用的CPU时间,包含内部调用其它函数的CPU时间 如方法top执行的总时间,假如说方法top的执行时间为10ms,方法a执行了1ms,方 法b执行了 2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间 要小一点)。
Excl Cpu Time: 表示函数占用的CPU时间,但不含内部调用其它函数所占用的CPU时间
Incl Real Time: 表示函数运行的真实时间(以毫秒为单位),内含调用其它函数所占用的真实时间
Excl Real Time: 表示函数运行的真实时间(以毫秒为单位),不含调用其它函数所占用的真实时间
Call+Recur Calls/Total: 表示函数被调用次数以及递归调用占总调用次数的百分比
Cpu Time/Call: 表示函数调用CPU时间与调用次数的比。相当于该函数平均执行时间
Real Time/Call: 表示同CPU Time/Call类似,只不过统计单位换成了真实时间
接下来我们说一下如何利用TraceView来分析性能瓶颈,一般导致卡顿的函数有两种类型:
一类是调用次数不多,但每次调用却需要花费很长时间的函数。
一类是那些自身占用时间不长,但调用却非常频繁的函数。
针对这两种hotspot查找有不同的方法:
第一类,通常我们需要选择按Cpu Time/Call进行降序排序,这时再去查找
第二类,点击Call/Recur Calls/Total列头,使之按降序排列然后再去查找,只不过这里边排在最上面的不一定是真正的hotspot还需要结合cpu时间分析。找到hotspot之后我们就需要分析我们的代码,找到优化的方案,重构代码。
有时我们采用上述分析方法产生的干扰信息较多, 对于TraceView还有另外的一种分析方法,如果我们已经知道那个过程卡段,可以在这个过程开始和结束分别添加android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing(); 然后我们重新安装,执行操作,结束后会在sdcard的根目录会生成一个traceView.trace文件(确保手机带有sdcard),我们可以打开TraceView导入该文件分析,接下来的分析和第一种的分析方法是一样的。
参考文章:
http://developer.android.com/tools/debugging/debugging-tracing.html
http://blog.csdn.net/innost/article/details/9008691
http://bxbxbai.github.io/2014/10/25/use-trace-view/
0 0
- Android性能分析优化 - TraceView介绍
- android TraceView性能分析与性能优化
- Android Studio TraceView性能优化分析
- Android Studio TraceView性能优化分析
- android性能优化-----TraceView
- Android性能优化---TraceView
- TraceView[Android性能分析]
- Android性能分析-traceview
- TraceView性能分析工具介绍
- TraceView android 性能优化工具
- Android性能优化(一):TraceView
- android TraceView分析android 性能
- android性能分析工具 traceview
- TraceView分析android应用性能
- Android性能分析工具-TraceView
- Android性能分析工具TraceView
- 性能分析工具 Android TraceView
- Android 性能分析工具TraceView
- BZOJ 1004 [HNOI2008]Cards 置换+burnside定理+逆元
- 如何在Eclipse里面更新添加主题
- os.rename()导致WindowsError: [Error 183]的问题
- 多线程(二)
- 在VirtualBox中安装Ubuntu14报错:Failed to open a session for the virtual machine,Unable to load R3……
- Android性能分析优化 - TraceView介绍
- SQL常用语句总结
- 关于C++二维指针
- Qt libqevdevtouchplugin.so插件的改写
- xtrabackup 热备 mysql
- java不定参数存在一个小问题。
- 网络编程
- 45. Jump Game II
- 犀牛——第6章对象 6.5 枚举属性