Android应用开发完成后,一般都会需要关注性能优化的问题,可是哥比较悲惨还没走到这一步就出现动画滑动不流畅的问题,花了不少时间去优化插值函数效果也不佳。最后无意中把APK安装到其他厂家的盒子上发现动画就流程了,开始怀疑跟平台相关。可直接这样抛给平台也不太负责了,也不符合哥的风格,还是得往深里扣啊。用两篇博文来记录一下这次查找问题原因的过程,本文介绍TraceView。
一: TraceView 简介
TraceView 是Android平台数据采集和分析工具,它可以分析应用程序的性能,而采集数据可以通过DDMS工具来实现。如图1所示:
图1: 启动TraceView采集数据
按照图1方法,打开device后选中需要采集的应用,点击对应图标启动采集数据,再次点击结束采集。
二:TraceView结果分析
TraceView 界面比较负责,其中UI分两部分,包括Timeline Panel(时间线面板)和Profile Panel(分析面板)。如图2所示
图2: TraceView UI面板
从图2可以看出,时间面板对应了时间轴上的方法调用,同时能看到该方法的测试时间。Profile Panel是Traceview的核心界面,其内涵非常丰富。它主要展示了某个线程(先在Timeline Panel中选择线程)中各个函数调用的情况,包括CPU使用时间、调用次数等信息。而这些信息正是查找hotspot的关键依据。所以,对开发者而言,一定要了解Profile Panel中各列的含义。笔者总结了其中几个重要列的作用,如表1所示:
列名 | 描述 |
Name | 该线程运行过程中所调用的函数名 |
Incl Cpu Time | 某函数占用的CPU时间,包含内部调用其它函数的CPU时间 |
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类似,只不过统计单位换成了真实时间 |
对应性能有影响的我们一般需要关注两类API:
1,每次执行占用CPU资源多
2,调用频繁的API
对于第1类方法,可以通过按Cpu Time/call 来排序,找到平均执行CPU时间长的方法,看是否存在问题。
对于第2类方法,可以通过按Call+Recur Calls/Total来排序,看调用频繁且占CPU资源多的方法,检查是否存在问题。
我这里遇到的问题是,同一APK在两个平台上表现不一样,一个平台A动画平滑,另一个平台B动画会出现卡顿。很自然的会通过对比两个平台的Traceview来找原因,结果并不像想象中那样,对比发现两个平台traceview基本相当,如下图
图3 平台A的分析面板数据
图2 平台B中的TraceView
两个平台的traceView基本相当,也找不出哪里的问题。但在这个对比中有两个重要的收获:
1, 从traceView分析面板中,可以跟踪没个函数的调用关系,对阅读framework代码有很大帮助,另外在跟踪函数过程中发现只能追踪JAVA层代码而Native的及不是本进程的代码也无法跟踪。正是这个原因导致用traceView没有分析出为什么在平台B中会有动画卡顿的问题。
2,跟踪函数过程中发现了Choreographer类及Vsync(后面还会介绍到),这个类是Android 4.1以后引如为解决UI平滑度的,感兴趣的可以点击打开链接。相信对UI平滑会有更深的理解。