Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task)，并且要避免可能的内存泄露。思考下面Activity的代码，在它启动的时候开启一个线程并循环执行任务。
1 /**
2 * 一个展示线程如何在配置变化中存活下来的例子（配置变化会导致创
3 * 建线程的Activity被销毁）。代码中的Activity泄露了，因为线程被实
4 * 例为一个匿名类实例，它隐式地持有外部Activity实例，因此阻止Activity
5 * 被回收。
6 */
7 public class MainActivity extends Activity {
8
9 @Override
10 protected void onCreate(Bundle savedInstanceState) {
11 super.onCreate(savedInstanceState);
12 exampleOne();
13 }
14
15 private void exampleOne() {
16 new Thread() {
17 @Override
18 public void run() {
19 while (true) {
20 SystemClock.sleep(1000);
21 }
22 }
23 }.start();
24 }
25 }
当配置发生变化（如横竖屏切换）时，会导致整个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内部类，如下所示:
1 /**
2 * 这个例子通过将线程实例声明为private static型的内部 类，从而避免导致Activity泄
3 * 露，但是这个线程依旧会跨越配置变化存活下来。DVM有一个指向所有运行中线程的
4 * 引用（无论这些线程是否 可以被垃圾回收），而线程能存活多长时间以及什么时候可
5 * 以被回收跟Activity的生命周期没有任何关系。
6 * 活动线程会一直运行下去，直到系统将你的应用程序销毁。
7 */
8 public class MainActivity extends Activity {
9
10 @Override
11 protected void onCreate(Bundle savedInstanceState) {
12 super.onCreate(savedInstanceState);
13 exampleTwo();
14 }
15
16 private void exampleTwo() {
17 new MyThread().start();
18 }
19
20 private static class MyThread extends Thread {
21 @Override
22 public void run() {
23 while (true) {
24 SystemClock.sleep(1000);
25 }
26 }
27 }
28 }
新的线程不会隐式地持有Activity的引用，并且Activity在配置发生变化后都会变得可以被回收。
怎么使一个Thread泄露
第二个问题是每当创建了一个新Activity，就会导致一个thread泄露并且不会被回收。在Java中，thread是GC Root也就是说在系统中的Dalvik Virtual Machine (DVM)保存对所有活动 中线程的强引用，这就导致了这些线程留存下来继续运行并且不会达到可以被回收的条件。因此你必须要考虑怎样停止后台线程。下面是一个例子：
1 /**
2 * 跟例子2一样，除了这次我们实现了取消线程的机制，从而保证它不会泄露。
3 * onDestroy()常常被用来在Activity推出前取消线程。
4 */
5 public class MainActivity extends Activity {
6 private MyThread mThread;
7
8 @Override
9 protected void onCreate(Bundle savedInstanceState) {
10 super.onCreate(savedInstanceState);
11 exampleThree();
12 }
13
14 private void exampleThree() {
15 mThread = new MyThread();
16 mThread.start();
17 }
18
19 /**
20 * 静态内部类不会隐式地持有他们外部类的引用，所以Activity实例不会在配置变化
21 * 中被泄露
22 */
23 private static class MyThread extends Thread {
24 private boolean mRunning = false;
25
26 @Override
27 public void run() {
28 mRunning = true;
29 while (mRunning) {
30 SystemClock.sleep(1000);
31 }
32 }
33
34 public void close() {
35 mRunning = false;
36 }
37 }
38
39 @Override
40 protected void onDestroy() {
41 super.onDestroy();
42 mThread.close();
43 }
44 }
在上面的代码中，我们在onDestroy()中关闭线程保证了线程不会意外泄露。如果你想要在配置变化的时候保存线程的状态（而不是每次都要关闭并重新创建一个新的线程）。考虑使用可留存（在配置变化中不会被销毁）、没有UI的fragment来执行长时间任务。看看我的博客,叫做《用Fragment解决屏幕旋转（状态发生变化）状态不能保持的问题》，里面有一个例子说明实现这点。API Demo中也一个全面的例子。
总结
在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下载。
译文链接：Activitys, Threads, & Memory Leaks