Android 应用的性能分析,优化,需要检查分析内存使用情况和方法调用情况。本文给出进行这两方面分析的工具和方法。
虽然Android系统的Dalvik虚拟机有垃圾回收机制,但因手机内存使用存在不同于普通PC的更大的限制,内存使用方面的问题,我们更应多加注意。
一些内存使用问题会非常明显,比如内存耗尽(不足)时触发的OutOfMemoryError
可能会使App直接崩溃。
另有一些内存问题则表现得不那么明显,但他们会让你的App以及系统变得越来越慢。
当有以上两种情况之一时,就得看看内存的使用情况了,是否存在:
在Android的ADT中,提供了两种工具可以用来分析内存使用
对象分配相关:DDMS中的Allocation Tracker。借助这个工具可以查看对象的生成和分配情况, 可了解到对象在何时被创建,但无法了解整个App的对象分配情况。
Heap使用情况相关:
hprof文件是Java 虚拟机的Heap快照
根据实时的Heap使用情情况,我们可以大致判断哪些操作,哪些页面可能存在内存是一共问题,但是具体的问题的需要更进一步的数据。
Allocation Tracker提供了对象分配和被引用的详细的信息
另外,还提供了一个报告,为我们分析提供参考
请在此处下载:Memeory Analyzer
我们可以通过DDMS导出hprof文件,在Memeory Analyzer中分析, 如下:
Dump HPROF file
, 等待一段时间,
10几秒甚至更长,保存hprof文件。导出的文件为Dalvik虚拟机格式的,需要转成J2SE虚拟机格式的,否则Memeory Analyzer无法打开
在windows中,cmd:
cd /d D:\android\adt\adk\tools
hprof-conv.exe D:\tmp\com.srain.cube.sample.hprof D:\tmp\com.srain.cube.sample-conv.hprof
界面展示大致如下:
点击Histogram:
各对象在列表中,可排序:
选中某个对象,List Objects -> with incoming reference / with outcoming reference 可查看引用和被应用的情况。 根据这些,加上搜索,可判断未释放的或者过大的有问题的对象的位置。
Memeory Analyzer功能强大,更多用法,点击这里
App不流畅卡顿,和方法执行速度有更直接的关系。 主UI线程上的耗时操作,超过5s,系统就会提示用户,是否终止程序。
在ListView中的getView()
方法,一个耗时10ms的操作就足够把你的列表卡顿得惨不忍睹。
Android框架Debug类提供了方法,记录方法调用的执行数据到一个trace文件,在代码中:
// 开始 trace文件位置: /sdcard/cube.trace
Debug.startMethodTracing("cube");
// ...
// 其他的代码
// 停止
Debug.stopMethodTracing();
在模拟器或者没SDK的真机上调试时,直接使用 /sdcard下的路径可能会有Permission deny错误,改用机身内部存储试试。
生成的trace文件,通过adb pull存到本地。
adb pull /sdcard/cube.trace D:\tmp\cube.trace
直接在ADT的eclipse中打开:
上图中:
上图中,Excl Time
排名第二的方法 bytesToHexString
很可能是有性能问题的。
原文:http://www.cnblogs.com/liaohuqiu/p/3528876.html