Android内存泄露调试

AndroidAndroidAndroidAndroid 内存泄漏调试 Made by 李文栋 liwd@thunderst.com | rayleeya@gmail.com 2010-07-25 Friday 一、概述.............................................................................................................................................1 二、Android(Java)中常见的容易引起内存泄漏的不良代码......................................................... 1 (一) 查询数据库没有关闭游标................................................................................................2 (二) 构造 Adapter时，没有使用缓存的 convertView.......................................................... 3 (三) Bitmap对象不在使用时调用 recycle()释放内存.............................................................4 (四) 释放对象的引用................................................................................................................ 4 (五) 其他.................................................................................................................................... 5 三、内存监测工具 DDMS --> Heap................................................................................................5 四、内存分析工具 MAT(MemoryAnalyzer Tool).......................................................................... 7 (一) 生成.hprof文件................................................................................................................. 7 (二) 使用MAT导入.hprof文件...............................................................................................8 (三) 使用MAT的视图工具分析内存..................................................................................... 8 Android 内存泄漏调试 1 一、概述 Java编程中经常容易被忽视，但本身又十分重要的一个问题就是内存使用的问题。 Android应用主要使用 Java语言编写，因此这个问题也同样会在 Android开发中出现。本文 不对 Java编程问题做探讨，而是对于在 Android中，特别是应用开发中的此类问题进行整 理。 由于作者接触 Android时间并不是很长，因此如有叙述不当之处，欢迎指正。 二、Android(Java)Android(Java)Android(Java)Android(Java)中常见的容易引起内存泄 漏的不良代码 Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通 常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代码当中有太多的对内 存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得 Android 应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的 Dalvik虚拟机实 例来运行，它是由 Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的 进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的 进程被 kill掉，而不会影响其他进程（如果是 system_process等系统进程出问题的话，则会 引起系统重启）。另一方面 Android为不同类型的进程分配了不同的内存使用上限，如果应 用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被 kill掉。Android为 应用进程分配的内存上限如下所示： 位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本 # Define the oom_adj values for the classes of processes that can be # killed by the kernel. These are used in ActivityManagerService. setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.SECONDARY_SERVER_ADJ 2 setprop ro.BACKUP_APP_ADJ 2 setprop ro.HOME_APP_ADJ 4 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.CONTENT_PROVIDER_ADJ 14 setprop ro.EMPTY_APP_ADJ 15 # Define the memory thresholds at which the above process classes will # be killed. These numbers are in pages (4k). setprop ro.FOREGROUND_APP_MEM 1536 setprop ro.VISIBLE_APP_MEM 2048 setprop ro.SECONDARY_SERVER_MEM 4096 setprop ro.BACKUP_APP_MEM 4096 setprop ro.HOME_APP_MEM 4096 Download at Pin5i.Com Android 内存泄漏调试 2 setprop ro.HIDDEN_APP_MEM 5120 setprop ro.CONTENT_PROVIDER_MEM 5632 setprop ro.EMPTY_APP_MEM 6144 # Write value must be consistent with the above properties. # Note that the driver only supports 6 slots, so we have HOME_APP at the # same memory level as services. write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15 write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144 # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存 使用问题。如下是一些常见的内存使用不当的情况。 ((((一一一一)))) 查询数据库没有关闭游标查询数据库没有关闭游标查询数据库没有关闭游标查询数据库没有关闭游标 描述： 程序中经常会进行查询数据库的操作，但是经常会有使用完毕 Cursor后没有关闭的情 况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的 情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。 示例代码： Cursor cursor = getContentResolver().query(uri ...); if (cursor.moveToNext()) { ... ... } 修正示例代码： Cursor cursor = null; try { cursor = getContentResolver().query(uri ...); if (cursor != null && cursor.moveToNext()) { ... ... } } finally { if (cursor != null) { try { Android 内存泄漏调试 3 cursor.close(); } catch (Exception e) { //ignore this } } } ((((二二二二)))) 构造构造构造构造 AdapterAdapterAdapterAdapter时，没有使用缓存的时，没有使用缓存的时，没有使用缓存的时，没有使用缓存的 convertViewconvertViewconvertViewconvertView 描述： 以构造 ListView的 BaseAdapter为例，在 BaseAdapter中提高了方法： public View getView(int position, View convertView, ViewGroup parent) 来向 ListView提供每一个 item所需要的 view对象。初始时 ListView会从 BaseAdapter中根 据当前的屏幕布局实例化一定数量的 view对象，同时 ListView会将这些 view对象缓存起来 。 当向上滚动 ListView时，原先位于最上面的 list item的 view对象会被回收，然后被用来构 造新出现的最下面的 list item。这个构造过程就是由 getView()方法完成的，getView()的第二 个形参 View convertView就是被缓存起来的 list item的 view对象(初始化时缓存中没有 view 对象则 convertView是 null)。 由此可以看出，如果我们不去使用 convertView，而是每次都在 getView()中重新实例化 一个 View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item的 view对象的过程可以查看: android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。 示例代码： public View getView(int position, View convertView, ViewGroup parent) { View view = new Xxx(...); ... ... return view; } 修正示例代码： public View getView(int position, View convertView, ViewGroup parent) { View view = null; if (convertView != null) { view = convertView; populate(view, getItem(position)); ... } else { view = new Xxx(...); ... } return view; } Download at Pin5i.Com Android 内存泄漏调试 4 ((((三三三三)))) BitmapBitmapBitmapBitmap对象不在使用时调用对象不在使用时调用对象不在使用时调用对象不在使用时调用 recycle()recycle()recycle()recycle()释放内存释放内存释放内存释放内存 描述： 有时我们会手工的操作 Bitmap对象，如果一个 Bitmap对象比较占内存，当它不在被使 用的时候，可以调用 Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的 ， 视情况而定。可以看一下代码中的注释： /** * Free up the memory associated with this bitmap's pixels, and mark the * bitmap as "dead", meaning it will throw an exception if getPixels() or * setPixels() is called, and will draw nothing. This operation cannot be * reversed, so it should only be called if you are sure there are no * further uses for the bitmap. This is an advanced call, and normally need * not be called, since the normal GC process will free up this memory when * there are no more references to this bitmap. */ ((((四四四四)))) 释放对象的引用释放对象的引用释放对象的引用释放对象的引用 描述： 这种情况描述起来比较麻烦，举两个例子进行 说明 关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书 。 示例 A： 假设有如下操作 public class DemoActivity extends Activity { ... ... private Handler mHandler = ... private Object obj; public void operation() { obj = initObj(); ... [Mark] mHandler.post(new Runnable() { public void run() { useObj(obj); } }); } } 我们有一个成员变量 obj，在 operation()中我们希望能够将处理 obj实例的操作 post到 某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了 obj 所引用的对象，但这个对象仍然不会被垃圾回收掉，因为 DemoActivity.obj还保有这个对象 的引用。所以如果在 DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的 Android 内存泄漏调试 5 引用，而代码可以修改为： ... ... public void operation() { obj = initObj(); ... final Object o = obj; obj = null; mHandler.post(new Runnable() { public void run() { useObj(o); } } } ... ... 示例 B: 假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信 号强度等)，则可以在 LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到 TelephonyManager服务中。对于 LockScreen对象，当需要显示锁屏界面的时候就会创建一 个 LockScreen对象，而当锁屏界面消失的时候 LockScreen对象就会被释放掉。 但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的 PhoneStateListener对 象，则会导致 LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会 由于大量的 LockScreen对象没有办法被回收而引起 OutOfMemory,使得 system_process进程 挂掉。 总之当一个生命周期较短的对象 A，被一个生命周期较长的对象 B保有其引用的情况 下，在 A的生命周期结束时，要在 B中清除掉对 A的引用。 ((((五五五五)))) 其他其他其他其他 Android应用程序中最典型的需要注意释放资源的情况是在 Activity的生命周期中，在 onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础， 在此不详细说明，具体可以查看官方文档对 Activity生命周期的介绍，以明确何时应该释放 哪些资源。 三、内存监测工具 DDMSDDMSDDMSDDMS -->-->-->--> HeapHeapHeapHeap 无论怎么小心，想完全避免 bad code是不可能的，此时就需要一些工具来帮助我们检 查代码中是否存在会造成内存泄漏的地方。Android tools中的 DDMS就带有一个很不错的 内存监测工具 Heap(这里我使用 eclipse的 ADT插件，并以真机为例，在模拟器中的情况类 似)。用 Heap监测应用进程使用内存情况的步骤如下： 1. 启动 eclipse后，切换到 DDMS透视图，并确认 Devices视图、Heap视图都是打开的； 2. 将手机通过 USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作 Download at Pin5i.Com Android 内存泄漏调试 6 为“Mass Storage”； 3. 链接成功后，在 DDMS的 Devices视图中将会显示手机设备的序列号，以及设备中正在 运行的部分进程信息； 4. 点击选中想要监测的进程，比如 system_process进程； 5. 点击选中 Devices视图界面中最上方一排图标中的“Update Heap”图标； 6. 点击 Heap视图中的“Cause GC”按钮； 7. 此时在 Heap视图中就会看到当前选中的进程的内存使用量的详细情况［如图所示］。 说明： a) 点击“Cause GC”按钮相当于向虚拟机请求了一次 gc操作； b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定 时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化； c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。 如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视 图中部有一个 Type叫做 data object，即数据对象，也就是我们的程序中大量存在的类类型 的对象。在 data object一行中有一列是“Total Size”，其值就是当前进程中所有 Java数据对 象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断： a) 不断的操作当前应用，同时注意观察 data object的 Total Size值； b) 正常情况下 Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良 好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象 ， 而在虚拟机不断的进行 GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定 的水平； c) 反之如果代码中存在没有释放对象引用的情况，则 data object的 Total Size值在每次 GC 后不会有明显的回落，随着操作次数的增多 Total Size的值会越来越大， 直到到达一个上限后导致进程被 kill掉。 d) 此处已 system_process进程为例，在我的测试环境中 system_process进程所占用的内存的 data object的 Total Size正常情况下会稳定在 2.2~2.8之间，而当其值超过 3.55后进程就会被 Android 内存泄漏调试 7 kill。 总之，使用 DDMS的 Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的 可能性。 四、内存分析工具 MAT(MemoryMAT(MemoryMAT(MemoryMAT(MemoryAnalyzerAnalyzerAnalyzerAnalyzer Tool)Tool)Tool)Tool) 如果使用 DDMS确实发现了我们的程序中存在内存泄漏，那又如何定位到具体出现问 题的代码片段，最终找到问题所在呢？如果从头到尾的分析代码逻辑，那肯定会把人逼疯， 特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT)。 MAT是一个 Eclipse插件，同时也有单独的 RCP客户端。官方下载地址、MAT介绍和 详细的使用教程请参见：www.eclipse.org/mat，在此不进行说明了。另外在 MAT安装后的 帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是 MAT的 eclipse插件，使用插件要比 RCP稍微方便一些。 使用MAT进行内存分析需要几个步骤，包括：生成.hprof文件、打开MAT并导入.hprof 文件、使用MAT的视图工具分析内存。以下详细介绍。 ((((一一一一)))) 生成生成生成生成.hprof.hprof.hprof.hprof文件文件文件文件 生成.hprof文件的方法有很多，而且 Android的不同版本中生成.hprof的方式也稍有差 别，我使用的版本的是 2.1，各个版本中生成.prof文件的方法请参考： http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap- profiling.html;hb=HEAD。 1. 打开 eclipse并切换到 DDMS透视图，同时确认 Devices、Heap和 logcat视图已经打开了 ； 2. 将手机设备链接到电脑，并确保使用“USB 调试”模式链接，而不是“Mass Storage“模 式； 3. 链接成功后在 Devices视图中就会看到设备的序列号，和设备中正在运行的部分进程； 4. 点击选中想要分析的应用的进程，在 Devices视图上方的一行图标按钮中，同时选中 “Update Heap”和“Dump HPROF file”两个按钮； 5. 这是 DDMS工具将会自动生成当前选中进程的.hprof文件，并将其进行转换后存放在 sdcard当中，如果你已经安装了MAT插件，那么此时MAT将会自动被启用，并开始对.hprof 文件进行分析； 注意：第 4步和第 5步能够正常使用前提是我们需要有 sdcard，并且当前进程有向 sdcard 中写入的权限(WRITE_EXTERNAL_STORAGE)，否则.hprof文件不会被生成，在 logcat中 会显示诸如 ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied. 的信息。 Download at Pin5i.Com Android 内存泄漏调试 8 如果我们没有 sdcard，或者当前进程没有向 sdcard写入的权限（如 system_process），那 我们可以这样做： 6. 在当前程序中，例如 framework中某些代码中，可以使用 android.os.Debug中的： public static void dumpHprofData(String fileName) throws IOException 方法，手动的指定.hprof文件的生成位置。例如： xxxButton.setOnClickListener(new View.OnClickListener() { public void onClick(View view) { android.os.Debug.dumpHprofData("/data/temp/myapp.hprof"); ... ... } } 上述代码意图是希望在 xxxButton被点击的时候开始抓取内存使用信息，并保存在我们 指定的位置：/data/temp/myapp.hprof，这样就没有权限的限制了，而且也无须用 sdcard。但 要保证/data/temp目录是存在的。这个路径可以自己定义，当然也可以写成 sdcard当中的某 个路径。 ((((二二二二)))) 使用使用使用使用MATMATMATMAT导入导入导入导入.hprof.hprof.hprof.hprof文件文件文件文件 1. 如果是 eclipse自动生成的.hprof文件，可以使用MAT插件直接打开（可能是比较新的ADT 才支持）； 2. 如果 eclipse 自动生成的 .hprof 文件不能被 MAT 直接打开，或者是使用 android.os.Debug.dumpHprofData()方法手动生成的.hprof文件，则需要将.hprof文件进行转 换，转换的方法： 例如我将.hprof文件拷贝到 PC上的/ANDROID_SDK/tools目录下，并输入命令 hprof- conv xxx.hprof yyy.hprof，其中 xxx.hprof为原始文件，yyy.hprof为转换过后的文件。转换过 后的文件自动放在/ANDROID_SDK/tools目录下。OK，到此为止，.hprof文件处理完毕，可 以用来分析内存泄露情况了。 3. 在 Eclipse中点击Windows->Open Perspective->Other->MemoryAnalyzer，或者打Memory Analyzer Tool的 RCP。在MAT中点击 File->Open File，浏览并导入刚刚转换而得到的.hprof 文件。 ((((三三三三)))) 使用使用使用使用MATMATMATMAT的视图工具分析内存的视图工具分析内存的视图工具分析内存的视图工具分析内存 导入.hprof文件以后，MAT会自动解析并生成 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 ，点击Dominator Tree，并按 Package 分组，选择自己所定义的 Package类点右键，在弹出菜单中选择 List objects->With incoming references。这时会列出所有可疑类，右键点击某一项，并选择 Path to GC Roots -> exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪 到代码中的某一个产生泄露的类。 MAT的界面如下图所示。 Android 内存泄漏调试 9 具体的分析方法在此不做说明了，因为在MAT的官方网站和客户端的帮助文档中有十 分详尽的介绍。 了解MAT中各个视图的作用很重要，例如www.eclipse.org/mat/about/screenshots.php中 介绍的。 总之使用MAT分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有 被释放，找到没有被释放的原因，也就可以很容易定位代码中的哪些片段的逻辑有问题了。 至此请各位自己动手，丰衣足食吧！ Download at Pin5i.Com 一、概述 二、Android(Java)中常见的容易引起内存泄漏的不良代码 (一)查询数据库没有关闭游标 (二)构造Adapter时，没有使用缓存的convertView (三)Bitmap对象不在使用时调用recycle()释放内存 (四)释放对象的引用 (五)其他 三、内存监测工具DDMS-->Heap 四、内存分析工具MAT(MemoryAnalyzerTool) (一)生成.hprof文件 (二)使用MAT导入.hprof文件 (三)使用MAT的视图工具分析内存