手机性能测试.docxVIP

android手机性能测试测试工具DDMS（Dalvik Debug Monitor Service）安装与配置首先安装JDK，1.5以上的版本（目前java vuser不支持JDK1.7）在安装完JDK 后，就需要下载及安装Android SDK，即： android-sdk-windows，压缩包大约有551M左右解压缩android-sdk-windows，放在C盘的根目录下，配置系统变量path 的值为：C: \android-sdk-windows\tools启动DDMS可以在开始--运行中进入DDMS也可以在C: \android-sdk-windows\tools目录下启动ddms.bat连接DDMS使用数据线连接安卓系统的手机，确认手机是处于“USB调试”模式。在手机上按下“Menu”键，在弹出的菜单中选择“Setting（设置）”；选择“应用程序”；在此界面勾选“未知来源”，然后选择“开发”；勾选“USB调试”，“保持唤醒状态”；在ddms的左边框中会显示手机已经打开的应用程序(APP)进程，如果不显示，可以多连接几次，或者换个手机试操作DDMS点击选中想要监测的进程，比如system_process进程；点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；点击Heap视图中的“Cause GC”按钮；此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。分析DDMS如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：不断的操作当前应用，同时注意观察data object的Total Size值；正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被kill掉。此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill掉Android程序的内存泄漏与规避方法造成Android应用程序内存泄漏的原因1、引用没释放造成的内存泄露注册没有取消造成的内存泄漏这种Android的内存泄露比纯Java的内存泄漏还要严重，因为其他一些Android程序可能引用系统的Android程序的对象(比如注册机制)。即使Android程序已经结束了，但是别的应用程序仍然还有对Android程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。集合中对象没有关闭造成的内存泄漏通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，慢慢地这个集合就会越来越大。如果这个集合是静态的话，那情况就会更严重。2、资源对象没有关闭造成的内存泄漏资源对象比如Cursor、File文件等往往都用了一些缓冲，在不使用的时候应该及时关闭它们，以便它们的缓冲及时回收内存。这些缓冲不仅存在于Java虚拟机内，还存在于Java虚拟机外，如果仅仅是把它的引用设置为空,而不关闭它们，那么往往会造成内存泄漏。3、一些不良代码造成的内存压力原因如下：Bitmap没有调用recycle( )；构造Adapter时，没有使用缓存的convertView；ThreadLocal使用不当；内存泄漏的检测及定位1、内存泄漏的检测Android应用程序是基于虚拟机的，其内存管理都是由Dalvik[2]代为管理，GC的回收不是及时的。一个正常的应用程序在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长。同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。当我们持续地观察某个应用程序运行过程中使用内存的大小和各实例的个数时，如果内存的大小持续增长，则说明系统存在内存泄漏的问题;如果特定类的实例对象个数随时间而增长，则说明这个类的实例可能存在泄漏情况。在重复打开关闭某个应用程序的时候，内存一直在向上爬升，也就是说