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/