Android oom(out of memory)的疑难问题

最近遇到一个Android oom(out of memory)的疑难问题, 至今仍未有解决. 一路走来, 遇到过多次Android oom. 在此做个总结, 也继续Track目前正在解的问题.

第一步: 发现问题

当我们在把玩自己的AP的时候, 突然它Force Close了. Logcat出来日志以后, 发现是可爱的oom问题.

第二步: 分析问题

 

通常引起oom的原因据我了解有以下几种情况:

1. 程序中使用了太多自己创建的Bitmap.

这种情况通常是最好解决的. 因为你明白你在哪里使用了这些Bitmap, 在什么时候就不需要了.

大部分情况是因为重复创建bitmap, 而不使用的bitmap没有被及时释放, 导致了 oom. 所以在不使用的时候要将bitmap对象回收bitmap.recycle(), 并将bitmap对象置为null.

还有就是当你一次性使用过多bitmap的时候也会导致oom. 比如使用系统的Gallery组件, 然后在每一项使用自己的图片, 这个时候我们通常自定义Gallery的adapter. 当Gallery需要显示很多图片的时候, 而我们没有做图片缓存机制的话必然会导致oom发生. 所以这个时候需要做图片缓存机制. 例如只保存当前显示项前后3项的图片, 滑动Gallery的时候再根据当前项动态回收前后不需要的图片和加载需要的图片.

2. 程序中一些对象创建的时候需要context的时候.

这种情况, 通常我们会使用create(this); 这个时候引用的时候activity的context, 如果该对象没有被及时回收, activity的引用将被它保留, 从而导致activity不能被及时销毁, 当重复创建activity后, 就会导致activity有多个实例, 从而导致内存泄露. 所以在用到context的时候尽量使用application的context: getApplicationContext().

3. 查询数据库没有关闭游标

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor 后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。所以在使用完游标以后要 cursor.close();

4. 没有释放对对象的引用:

这种情况描述起来比较麻烦，举两个例子进行说明。

示例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]的位置释放对象的引用，而代码可以修改为：

… …

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 的引用。

5.其它

Android 应用程序中最典型的需要注意释放资源的情况是在Activity 的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity 生命周期的介绍，以明确何时应该释放哪些资源。

还有其它一些疑难的很难找到原因的问题:

这种情况通常是比较折磨人的, 但是你要及时转换一种心态: 哇, 这个问题比较有趣呢, 如果解决掉,岂不是很有成就感呢? 题外话..

排查问题的方法:假设我的程序是A.

1. 如果是A和B程序交互时出现的问题, 那么我就用A和C来交互来重现这个问题, 前提是C和B有些共同点.如果能重现, 说明是A自己的问题, 和B没有关系.

2. 关注A相关的一些回调函数, 打印log, 去找具体的地方.

3. 可以用最小化问题的方法来排除, 叠加屏蔽一些可疑代码, 直到问题消失. 这个是最有效的发现问题的方法.

使用内存分析工具MAT(MemoryAnalyzer Tool)

MAT 是一个Eclipse 插件，同时也有单独的RCP 客户端。官方下载地址、MAT 介绍和详细的使用教程请参见：www.eclipse.org/mat，在此不进行说明了。另外在MAT 安装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是MAT 的eclipse 插件，使用插件要比RCP 稍微方便一些。

1. 打开DDMS

2.打开程序, 会看到程序的进程.

3.选中程序的进程, 点击Update Heap按钮.

4.按照发生oom的步骤操作, 直到发生oom.

5.点击Dump HPROF file按钮.

6.过一会eclipse会自动用MAT打开生成的.hprof文件.

7.点击文件上面的Histogram会打开一个视图.

8.在class name那一栏最底部, 会有一行Total**** 然后右击选项ExpandAll.

9. 点击Shadow Heap排序, 最顶层的就是泄露最多的地方.

10.右击某个calss选择ListObjects->incoming reference.

11.然后就可以看到在哪些地方有些路, 逐个排查对应的代码.

也可以使用下面的方法:

点击Dominator Tree，并按Package分组，选择自己所定义的Package 类点右键，在弹出菜单中选择List objects->With incomingreferences。这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots -> exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

由此发现的一些很搞笑的内存泄漏原因:

最后我的问题解决了, 很可笑的内存泄漏: B引用了A的实例, 我们在释放B的时候没有去释放对A的引用, 那么就会造成对A的泄露. 看下面代码解释.

错误的代码:

public class A extends Activity implments TestListener{

…………….

private B mTestClass

protected void onCreate( ){

mTestClass= new B(this);

testClass.setTestListener(this);//设置了Listener, 引用了Activity.

}

protected void onDestroy(){

mTestClass= null;//只是释放了对象, 实际上Listener还有对Activity的引用

}

…………….

}

 

public class B{

…………….

private TestListener mTestListener;

public B(Context Context){ …. }

….

public setTestListener( TestListener tl){

mTestListener = tl;

}

…………….

}

修改后的代码:

public class A extends Activity implments TestListener{

…………….

private B mTestClass

protected void onCreate( ){

mTestClass= new B(this);

testClass.setTestListener(this);//设置了Listener, 引用了Activity.

}

protected void onDestroy(){

mTestClass.removeTestListener();//释放引用

mTestClass= null;

}

…………….

}

 

public class B{

…………….

private TestListener mTestListener;

public B(Context Context){ …. }

….

public setTestListener( TestListener tl){

mTestListener = tl;

}

//加上注销Listener的方法.

public removeTestListener( ){

mTestListener = null;

}

…………….

}

总结:

在这个过程中, 发现了一个很好用的工具:

JvisualVm 这个工具可以打开hprof文件, 查看对象引用关系. 比MAT那个强大啊!!

这个工具就在JDK的根目录的bin文件夹里面.

 

Android的内存泄漏就这么回事.