Android中的Activitys, Threads和内存泄露

阅读目录

• 怎么样让一个Activity泄露
• 怎么使一个Thread泄露
• Hanlder泄露
• 总结

Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task)，并且要避免可能的内存泄露。思考下面Activity的代码，在它启动的时候开启一个线程并循环执行任务。

/**
 * 一个展示线程如何在配置变化中存活下来的例子（配置变化会导致创
 * 建线程的Activity被销毁）。代码中的Activity泄露了，因为线程被实
 * 例为一个匿名类实例，它隐式地持有外部Activity实例，因此阻止Activity
 * 被回收。
 */
public class MainActivity  extends Activity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super .onCreate(savedInstanceState);
    exampleOne();
  }

  private void exampleOne() {
    new Thread() {
      @Override
      public void run() {
        while ( true ) {
          SystemClock.sleep( 1000 );
        }
      }
    }.start();
  }
}

当配置发生变化（如横竖屏切换）时，会导致整个Activity被销毁并重新创建,很容易假定Android将会为我们清理和回收跟Activity相关的内存及它运行中的线程。然而,这并非如此。这两者都会导致内存泄露而且不会被回收, 后果是性能可能显著地下降。

怎么样让一个Activity泄露

如果你读过我前一篇关于Handler和内部类的文章，那么第一种内存泄露应该很容易理解。在Java中,非静态匿名类隐式地持有他们的外部类的引 用。如果你不小心，保存这个引用可能导致Activity在可以被GC回收的时候被保存下来。Activity持有一个指向它们整个View继承树和它所 持有的所有资源的引用，所以如果你泄露了一个，很多内存都会连带着被泄露。

配置发生变化只加剧了这个问题，它发出一个信号让Activity销毁并重新创建。比如，基于上面的代码进行10次横竖屏变化后，我们可以看到（使用Eclipse Memory Analyzer）由于那些隐式的引用，每一个Activity对象其实都留存在内存中:

                 图1.在10次配置发生变化后，存留在内存中的Activity实例

每一次配置发生变化后，Android系统都会创建一个新的Activity并让旧的Activity可以被回收。然而，隐式持有旧Activity引用的线程，阻止他们被回收。所以每次泄露一个新的Activity，都会导致所有跟他们关联的资源都没有办法被回收。

解决方法也很简单，在我们确定了问题的根源，那么只要将线程定义为private static内部类，如下所示:

/**
 * 这个例子通过将线程实例声明为private static型的内部 类，从而避免导致Activity泄
 * 露，但是这个线程依旧会跨越配置变化存活下来。DVM有一个指向所有运行中线程的
 * 引用（无论这些线程是否 可以被垃圾回收），而线程能存活多长时间以及什么时候可
 * 以被回收跟Activity的生命周期没有任何关系。
 * 活动线程会一直运行下去，直到系统将你的应用程序销毁。
 */
public class MainActivity  extends Activity {

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super .onCreate(savedInstanceState);
    exampleTwo();
  }

  private void exampleTwo() {
    new MyThread().start();
  }

  private static class MyThread  extends Thread {
    @Override
    public void run() {
      while ( true ) {
        SystemClock.sleep( 1000 );
      }
    }
  }
}

新的线程不会隐式地持有Activity的引用，并且Activity在配置发生变化后都会变得可以被回收。

回到顶部

怎么使一个Thread泄露

第二个问题是每当创建了一个新Activity，就会导致一个thread泄露并且不会被回收。在Java中，thread是GC Root也就是说在系统中的Dalvik Virtual Machine (DVM)保存对所有活动 中线程的强引用，这就导致了这些线程留存下来继续运行并且不会达到可以被回收的条件。因此你必须要考虑怎样停止后台线程。下面是一个例子：

/**
 * 跟例子2一样，除了这次我们实现了取消线程的机制，从而保证它不会泄露。
 * onDestroy()常常被用来在Activity推出前取消线程。
 */
public class MainActivity  extends Activity {
  private MyThread mThread;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super .onCreate(savedInstanceState);
    exampleThree();
  }

  private void exampleThree() {
    mThread =  new MyThread();
    mThread.start();
  }

  /**
    * 静态内部类不会隐式地持有他们外部类的引用，所以Activity实例不会在配置变化
    * 中被泄露
   */
  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
  protected void onDestroy() {
    super .onDestroy();
    mThread.close();
  }
}

在上面的代码中，我们在onDestroy()中关闭线程保证了线程不会意外泄露。如果你想要在配置变化的时候保存线程的状态（而不是每次都要关闭 并重新创建一个新的线程）。考虑使用可留存（在配置变化中不会被销毁）、没有UI的fragment来执行长时间任务。看看我的博客,叫做《用Fragment解决屏幕旋转（状态发生变化）状态不能保持的问题》，里面有一个例子说明实现这点。API Demo中也一个全面的例子。

Handler是造成内存泄露的一个重要的源头。

　　看一下如下代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class HandlerActivity extends Activity { private final Handler mHandler = new Handler() { public void handleMessage(Message msg) { // ... } }; public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // 发送一个消息，60秒后处理。 mHandler.sendMessageDelayed(Message.obtain(), 60000); // 关闭Activity。 finish(); } }

　　猛地一看并没有什么问题，但是Eclipse或Android Studio却会有如下警告：

This Handler class should be static or leaks might occur (com.example.ta.HandlerActivity.1)

　　大体的意思是：Handler应该使用静态声明，不然可能导致HandlerActivity被泄露。

　　为啥出现这样的问题呢？这是因为：

- 首先，当在主线程中初始化Handler时，该Handler会和主线程中的Looper的消息队列关联。 - 然后，通过Handler发送的消息，会被发送到Looper的消息队列里，直到消息被处理。 - 接着，但是通过Handler对象发送的消息会反向持有Handler的引用，这样系统可以调用Handler#handleMessage(Message)来分发处理该消息。 - 最后，由于消息会延迟60秒处理，因此Message对象的引用会被一直持有，同时导致Handler无法回收，又因为Handler是实例内部类，所以最终会导致Activity被泄漏。

　　也许你会说“我不去执行这种延期的Message不就行了”，但是：

- 首先，你不会执行但你不能保证你同事也不会执行。 - 然后，由于程序中可以存在多个Handler，并且一般情况下都是在主线程中处理消息，因此你也不能保证在其他地方的Handler对象不会阻塞主线程，进而导致你的Message被迫延迟处理等。 - 因此，为了避免这些未知的情况，我们尽量不要这么写代码。

如何避免呢？
　　最简单的方法就是把Handler写成一个外部类，不过这样一来就会多出很多文件，也难以查找和管理。

　　另一个方法就是使用静态内部类+软引用：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

public class HandlerActivity2 extends Activity { private static final int MESSAGE_1 = 1; private static final int MESSAGE_2 = 2; private static final int MESSAGE_3 = 3; private final Handler mHandler = new MyHandler( this); @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mHandler.sendMessageDelayed(Message.obtain(), 60000); finish(); } private static class MyHandler extends Handler { private final SoftReference<HandlerActivity2> mActivity; public MyHandler(HandlerActivity2 activity) { mActivity = new SoftReference<HandlerActivity2>(activity); } @Override public void handleMessage(Message msg) { // 如果当前Activity被GC回收了，则就不处理这个消息了，直接返回。 if (mActivity.get() == null) { return; } } } }

语句解释：
- 本范例中创建了一个名为MyHandler的静态内部类，与实例内部类不同的是，静态内部类不会默认持有其外部类的引用。 - 在构造MyHandler类的对象时，虽然仍需要传递一个HandlerActivity2的引用过去，但MyHandler类不会持有它的强引用，因而不会阻止HandlerActivity2回收。

上面这样就可以了吗？
　　当Activity被finish后Handler对象还是在Message中排队，还是会处理消息，但这些处理已经没有必要了。
　　我们可以在Activity的onStop或者onDestroy的时候，取消掉该Handler对象的Message和Runnable，代码如下：

1 2 3 4 5 6

public void onDestroy() { mHandler.removeMessages(MESSAGE_1); mHandler.removeMessages(MESSAGE_2); mHandler.removeMessages(MESSAGE_3); mHandler.removeCallbacks(mRunnable); }

回到顶部

总结

在Android中处理Activity生命周期与长时间运行的任务的关系可能很困难并且可能导致内存泄露。下面有一些值得考虑的通用建议：
    优先使用静态内部类而不是非静态的。非静态内部类的每个实例都会有一个对它外部Activity实例的引用。 当Activity可以被GC回收时，存储在非静态内部类中的外部Activity引用可能导致垃圾回收失败。如果你的静态内部类需要宿主 Activity的引用来执行某些东西，你要将这个引用封装在一个WeakReference中，避免意外导致Activity泄露。

    不要假定Java最后总会为你清理运行中的线程。在上面的例子中，很容易错误地认为用户退出 Activity后，Activity就会被回收，任何跟这个Activity关联的线程也都将一并被回收。事实上不是这样的。Java线程会继续运行下 去，直到他们被显式地关闭或者整个process被Android系统杀掉。因此，一定要记得记得为后台线程实现对应的取消策略，并且在Activity 生命周期事件发生的时候使用合理的措施。

    考虑你是否真的应该使用线程。Android Framework提供了很多旨在为开发者简化后台线程开发的类。比如，考虑使用Loader而不是线程当你需要配合Activity生命周期做一些短时 间的异步后台任务查询类任务。考虑使用使用Service，然后向使用BrocastReceiver向UI反馈进度、结果。最后，记住本篇文章中一切关 于线程的讨论也适用于AsyncTask（因为Asynctask类使用ExecutorService来执行它的任务）。然而，鉴于AsyncTask 只应该用于短时间的操作（最多几秒钟，参照文档），它倒不至于会导致像Activity或线程泄露那么大的问题。

这篇文章中的源代码都可以从github下载。文章中的示例程序可以从Google play下载。