Android系统调试(03)OOM问题总结（android oom解决方案）

1 内存泄露框架

@1 为什么会有内存泄漏？

一个不会被使用的对象，因为另一个正在使用的对象持有该对象的引用,导致它不能正常被回收,而停留在堆内存中,内存泄漏就产生了，Android系统为每个应用分配的内存是有限的，内存泄漏会使我们的应用内存随着时间不断的增加,造成应用OOM(Out Of Memory)错误,使应用崩溃。

@2 如何解决内存泄漏?

在解决内存泄漏的时候常常使用LeakCanary工具,它是一个自动检测内存泄漏的开源工具,使用它我们就可以明确的知道那个地方发生了泄漏。

2 造成内存泄露的几种情况

2.1 持有Context造成的内存泄漏

@1 原因：在Android中有两种context对象:Activity和Application.当我们给一个类传递context的时候经常使用第一种,而这样就导致该类持有对Activity的全部引用,当Activity关闭的时候因为被其他类持有,而导致无法正常被回收,从而而导致内存泄漏。

@2 解决方案:在给其他给传递context的时候使用Application对象,和这个对象的生命周期共存亡,而不依赖activity的生命周期，而对context的引用不要超过他本身的生命周期,谨慎对context使用static关键字。

2.2 Handler造成的内存泄漏

关键代码如下所示：

C++
public class SampleActivity extends Activity {
private final Handler mLeakyHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ... 
}
}
}

这样来使用Handler会造成严重的内存泄漏。

@1 原因：假设Hanlder中有延迟的任务或是等在执行的任务队列过长,由于消息队列持有对handler的引用,而handler又持有activity的隐式引用,这个引用会保持到消息得到处理,而导致activity无法被垃圾回收器进行回收,而导致内存泄漏。

@2 解决方案：可以把Handler放到单独的类中,或者使用静态的内部类(静态内部类不会引用activity)避免泄漏。如果想要在handler内部去调用Activity中的资源,可以在Handler中使用弱引用的方式指向所在的Activity,使用static+WeakReference的方式断开handler与activity的关系，最终代码如下：

Java
public static class MyHandler extends Handler {
//声明一个弱引用对象
WeakReference<MainActivity> mReference;
MyHandler(MainActivity activity) {
//在构造器中传入Activity,创建弱引用对象
mReference = new WeakReference<MainActivity>(activity);
}
public void handleMessage(Message msg) {
//在使用activity之前先判空处理
if (mReference != null && mReference.get() != null) {
mReference.get().text.setText("hello word");
}
}
}

2.3 使用单利模式造成的内存泄漏

@1 在我们使用单利模式的时候如果使用不当也会造成内存泄漏。原因：单例模式的静态特征使得单例模式的生命周期和应用一样的长,这说明了当一个对象不需要使用了,而单例对象还存在该对象的引用,那么这个对象就不能正常的被回收，造成内存泄漏。

@2 解决方案如下：

Java
XXUtils.getInstance(this);

这句代码默认传入的是Activity的Context,而Activity是间接继承自Context的,当Activity退出之后,单例对象还持有它的引用,所以在为了避免传Activity的Context,在单例中通过传入的context获取到全局的上下文对象,而不使用Activity的Context就解决了这个问题

Java
public class XXUtils {
  private Context mContext;
  private XXUtils(Context context) {
  	mContext = context.getApplicationContext();
  }
  private static XXUtils instance;
  public static XXUtils getInstance(Context context) {
    if (instance == null) {
      synchronized (XXUtils.class) {
          if (instance == null) {
            instance = new XXUtils(context);
          }
  		}
  	}
  return instance;
  }
}

2.4 非静态内部类创建静态实例造成的内存泄漏

@1 在项目中我们为了避免多次的初始化资源,常常会使用静态对象去保存这些对象,这种情况也很容易引发内存泄漏，原因如下：

非静态的内部类默认会持有外部类的引用

而我们又使用非静态内部类创建了一个静态的实例

该静态实例的声明周期和应用一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity不能正常回收

@2 解决方案:

将内部类修改成静态的,这样它对外部类就没有引用，将该对象抽取出来封装成一个单例，最终代码:

Java
private static TestResource mTestResource;

protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      findViewById(R.id.btn).setOnClickListener(this);
}
private void initData() {
      if (mTestResource == null) {
            mTestResource = new TestResource();
      }
}
public void onClick(View v) {
      initData();
}
//非静态内部类默认会持有外部类的引用
//修改就可以正常被回收,是因为静态的内部类不会对Activity有引用
private static class TestResource {
}

2.5 线程造成的内存泄漏

@1 原因：在使用线程时,一般都使用匿名内部类,而匿名内部类会对外部类持有默认的引用,当Acticity关闭之后如果现成中的任务还没有执行完毕,就会导致Activity不能正常回收,造成内存泄漏。

@2 解决方案：创建一个静态的类,实现Runnable方法,在使用的时候实例化他。最终代码:

Java
private void loadData() {
	new Thread(new MyThread()).start();
}
private static class MyThread implements Runnable {
  public void run() {
    SystemClock.sleep(20000);
  }
}

资源未关闭造成的内存泄漏。对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的代码，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。

2.6 监听器没有注销造成的内存泄漏

@1 原因：在Android程序里面存在很多需要register与unregister的监听器，忘记unregister会导致内存泄露

@2 解决方案：我们需要确保及时unregister监听器。

2.7 集合中的内存泄漏

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。