Android中static有关的内存泄漏

一、Handler,Message,Runnable 

 考虑下面的代码：

 public class SampleActivity extends Activity {

privatefinal Handler mLeakyHandler = new Handler() {

     @Override

     public void handleMessage(Message msg) {

       // ...

      }

   }

}

 

虽然不明显，但是这段代码可能导致内存泄露。Android Lint会提示以下信息：

 

In Android, Handler classes should be static or leaksmight occur.

 

但是哪里有内存泄露，是怎么出现的呢？首先我们来了解下这些信息：

 

1.       当一个Android应用程序启动的时候，Anroid框架为这个程序的主线程即UI线程创建了一个Looper对象。Looper实现了一个简单的messagequeue，不断循环的处理其中的message。所有的应用程序框架的事件（比如Activity生命周期的调用，按钮的点击等）都被封装在这个Message对象里，然后被加入到Looper的Messagequeue，最后一个一个的处理这些Message。Looper在整个应用程序的生命周期中一直存在。

 

2.       当我们在主线程中实例化一个Handler对象的时候，和他关联了主线程的Looper的Messagequeue。被发送到这个Message queue的Message都保持了一个Handler对象的引用，这样框架就可以在处理这个Message的时候调用Handler.handleMessage(Message)来处理消息了。

 

3.       在Java中，非静态内部类和匿名内部类都隐式的保持了一个outerclass的引用。但是静态内部类不会有这个引用。

那么内存泄露到底在哪里呢？很难发现吧，让我们接着看下面的例子：

 

public class MainActivity extends Activity {

 

  private finalHandler mLeakyHandler = new Handler() {

    @Override

    public voidhandleMessage(Message msg) {

      // ...

    }

  };

 

  @Override

  protectedvoid onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

 

    // Post amessage and delay its execution for 10 minutes.

   mLeakyHandler.postDelayed(new Runnable() {

      @Override

      publicvoid run() { }

    }, 60 * 10* 1000);

 

    // Go backto the previous Activity.

    finish();

  }

}

 

Why

当Activity finished的时候，需要延迟处理的message将会继续存在于主线程的Message queue中10分钟。这个Message保持了一个对Activity中Handler的引用，Handler又保持了一个对outer class（这个例子中的MainActivity）的引用。这些引用在Message被处理完之前会一直存在，这就导致了Activity context不会被GC回收掉，导致程序的resources泄露。需要注意的是泄露同样发生在匿名的runnable类中，非静态的匿名类也保持了一个对outer class的引用，也会导致context 泄露。

Message->Handler->outerclass(MainActivity)

 

How

要解决这个问题，可以在另外一个文件中生成一个Handler的子类或者用静态内部类来替代之前的内部类。静态的内部类不会保持对outer class的引用，所以activity不会泄露。如果你需要在Handler中访问外部activity的方法，可以在Handler中保持一个对Activity的WeakReference，这样就不会发生context leak。要解决匿名Runnable 类的泄露，我们可以让使用静态的成员变量（静态的匿名类实例也不会保持对outer class的引用）。

 1、静态内部类+WeakReference<Activity>

public class MainActivity extends Activity {

 

  /**

   * Instancesof static inner classes do not hold an implicit

   * referenceto their outer class.

   */

  private static class MyHandler extends Handler {

    private final WeakReference<MainActivity> mActivity;

 

    public MyHandler(MainActivity activity) {

      mActivity= new WeakReference<MainActivity>(activity);

    }

 

    @Override

    public void handleMessage(Message msg) {

          MainActivity activity = mActivity.get();

      if(activity != null) {

        // ...

      }

    }

  }

 

  private final MyHandler mHandler = new MyHandler(this);

 

2、静态Runnable，避免对outerclass的引用

  /**

   * Instancesof anonymous classes do not hold an implicit

   * referenceto their outer class when they are "static".

   */

  private static final Runnable sRunnable = new Runnable() {

      @Override

      publicvoid run() { }

  };

 

  @Override

  protectedvoid onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

 

    // Post amessage and delay its execution for 10 minutes.

   mHandler.postDelayed(sRunnable, 60 * 10 * 1000);

   

    // Go backto the previous Activity.

    finish();

  }

}

 

静态内部类和非静态内部类的区别很微小，但是我们开发人员必须了解。那么底线是什么？当内部类可以独立于Activity的生命周期而存在的时候，我们应该避免使用非静态的内部类，应该用静态内部类并且使用WeakReference保持对Activity的引用。

****************************************************************************

二、Thread，AsyncTask

public class MainActivity extends Activity {

 

  @Override

  protected void onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

   exampleOne();

  }

 

  private voidexampleOne() {

    new thread() {

      @Override

      public void run() {

        while(true) {

         SystemClock.sleep(1000);

        }

      }

    }.start();

  }

}

 

当configuration 变化的时候（比如转屏），整个Activity被销毁并且被重新创建，我们可能认为Android会释放掉和之前Activity相关的内存和他里面的线程。但是，事实上不是这样的。在这个例子中，这两个都会导致泄露，并且再也不会被回收了。

 

在Java里面，非静态的匿名内部类保持了一个对outer class的引用。如果你不够小心，持有了这个引用，那么将导致这个Activity一直保留（本应该被垃圾回收器回收）。Activity对象保持了对整个View结构和所有这些Resources的引用，所以你LeakActivity，也就Leak了很多的内存。

 

在configuration不断变化的时候，即不断的销毁，再创建Activity的时候。比如，运行上面的代码，在旋转了10次屏幕之后，我们可以看见（使用Eclipse Memory Analyzer）每个Activity对象事实上都保存在内存中没有被释放掉:

在每次转屏后，Android系统创建一个新的Activity，然后老的Activity又没有被垃圾回收器回收（因为线程中保持了一个对Activity的引用）。结果就造成Activity泄漏，所有和Activity相关的资源都不会被释放掉。

 

要解决这个问题，我们可以声明线程为私有的静态内部类。

 

public class MainActivity extends Activity {

 

  @Override

  protected void onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

   exampleTwo();

  }

 

  private void exampleTwo() {

    newMyThread().start();

  }

 

  private static class MyThread extends Thread {

    @Override

    public voidrun() {

      while(true) {

       SystemClock.sleep(1000);

      }

    }

  }

}

 

第二个问题就是每个新的Activity都创建了一个线程，并且这些线程永远不会呗回收掉。在Java里线程位于GC的roots，而Dalvik Virtual Machine（DVM）保持对系统中所有活动线程的引用，这就导致这些一直活动的线程永远不会被回收。对于这种情况，你需要记住的就是适当的时候取消线程的运行！下面的例子讲解了怎么来做：

 

public class MainActivity extends Activity {

  privateMyThread mThread;

 

  @Override

  protected void onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

   exampleThree();

  }

 

  private void exampleThree() {

    mThread =new MyThread();

   mThread.start();

  }

 

  /**

   * Staticinner classes don't hold implicit references to their

   * enclosingclass, so the Activity instance won't be leaked across

   *configuration changes.

   */

  private static class MyThread extends Thread {

    private boolean mRunning = false;

 

    @Override

    public void run() {

      mRunning= true;

      while (mRunning) {

       SystemClock.sleep(1000);

      }

    }

 

    public void close() {

      mRunning= false;

    }

  }

 

  @Override

  protectedvoid onDestroy() {

   super.onDestroy();

   mThread.close();

  }

}

 

在上面的代码中，在Activity的onDestroy里面关闭线程，这样就不会导致Thread Leak了。如果你想在转屏的时候保持住一个线程（而不用关闭掉之前的线程再重新创建一个），考虑使用retained。可以查看这篇文章。

 

这里总结了一些要点来防止处理耗时操作的时候导致内存泄露。

 

1.       多使用静态内部类而不是非静态的。每个非静态内部类都保持了一个对outer Activity实例的引用。这个引用可能导致Activity不被垃圾回收器回收。如果你的静态内部类需要引用一个Activity，那么你可以使用WeakReference来保证这个Activity不会泄露。

 

2.       不要认为Java会为你清理runningthread。在上面的例子中，我们会很容易的就想象当用户离开这个Activity的时候，Activity实例会被垃圾回收器回收，所有在这个Activity中开启的running thread也会被清理掉。事实上不是这样的。Java线程将会一直存在，直到他们被显示的关闭或者处理结束，或者被杀掉整个进程。所以，你需要完成可被取消的线程机制，在Activity的生命周期的某个地方做适当的处理。

 

3.       考虑你是否需要使用Thread。Android应用程序框架提供了很多类来处理后台线程。比如，考虑使用Loader替代Thread来处理短时间的异步任务。同时，如果后台线程并没有和Activity有紧密的联系，可以考虑使用Service，用BroadcastReceiver来更新UI。最后，这篇文章讨论的所有关于Thread的问题，也同样会发生在AsyncTask上面。但是，假设AsyncTask只使用在一些短时间的任务上（只有几秒），Activity或者Thread的Leak将不会是很大的问题。因为最终在这个Thread处理完任务之后，Activity和Thread都会被释放掉。

*************************************************************************