【译】Activitys, Threads和 内存泄露

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

时间: 2024-10-06 04:49:27

【译】Activitys, Threads和 内存泄露的相关文章

*Activitys, Threads和 内存泄露

Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task),并且要避免可能的内存泄露.思考下面Activity的代码,在它启动的时候开启一个线程并循环执行任务. 1 /** 2 * 一个展示线程如何在配置变化中存活下来的例子(配置变化会导致创 3 * 建线程的Activity被销毁).代码中的Activity泄露了,因为线程被实 4 * 例为一个匿名类实例,它隐式地持有外部Activity实例,因此阻止Activity 5 * 被回收. 6 */ 7 pu

[转]Activitys, Threads, & Memory Leaks

转自:http://www.androiddesignpatterns.com/2013/04/activitys-threads-memory-leaks.html http://www.cnblogs.com/kissazi2/p/4125356.html A common difficulty in Android programming is coordinating long-running tasks over the Activity lifecycle and avoiding

android内存优化-Activity, Thread引起的内存泄露0

Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task),并且要避免可能的内存泄露.思考下面Activity的代码,在它启动的时候开启一个线程并循环执行任务. 1 /** 2 * 一个展示线程如何在配置变化中存活下来的例子(配置变化会导致创 3 * 建线程的Activity被销毁).代码中的Activity泄露了,因为线程被实 4 * 例为一个匿名类实例,它隐式地持有外部Activity实例,因此阻止Activity 5 * 被回收. 6 */ 7 pu

Java 程序的内存泄露问题分析

什么是内存泄露? 广义的Memory Leak:应用占用了内存,但是不再使用(包括不能使用)该部分内存 狭义的Memory Leak:应用分配了内存,但是不能再获取该部分内存的引用(对于Java,也不能被GC) 一个具体的例子: 应用创建了一个长时间运行的Thread 该Thread使用ClassLoader(可以是定制的也可以是默认的)加载了一个类 这个类有一个Static域,指向了一大块内存,然后该Thread的ThreadLocal变量保存了这个类的引用. 最后该Thread清理了对所有已

[Android Memory] App调试内存泄露之Context篇(下)

转载地址:http://www.cnblogs.com/qianxudetianxia/p/3655475.html 5. AsyncTask对象 我N年前去盛大面过一次试,当时面试官极力推荐我使用AsyncTask等系统自带类去做事情,当然无可厚非. 但是AsyncTask确实需要额外注意一下.它的泄露原理和前面Handler,Thread泄露的原理差不多,它的生命周期和Activity不一定一致. 解决方案是:在activity退出的时候,终止AsyncTask中的后台任务. 但是,问题是如

memwatch内存泄露检测工具

工具介绍 官网 http://www.linkdata.se/sourcecode/memwatch/ 其功能如下官网介绍,挑选重点整理: 1. 号称功能: 内存泄露检测 (检测未释放内存, 即 动态内存开辟未释放的情况) 2. 检测 多次调用free, 和 free 错误地址 3. 检测内存访问的 上越界 和 下越界 4. 检测对野指针进行的写操作 其他内存检测工具有 mtrace valgrind 参考 http://www.cnblogs.com/honglihua8688/p/37279

LeakCanary:检测所有的内存泄露

本文译自:https://corner.squareup.com/2015/05/leak-canary.html(LeakCanary是由Square公司刚刚开源用于查找Android内存泄露的库) java.lang.OutOfMemoryError at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2) at android.graphics.Bitmap.createBitmap(Bitmap.java:689) at com.sq

如何用Java编写一段代码引发内存泄露

Q:刚才我参加了面试,面试官问我如何写出会发生内存泄露的Java代码.这个问题我一点思路都没有,好囧. A1:通过以下步骤可以很容易产生内存泄露(程序代码不能访问到某些对象,但是它们仍然保存在内存中): 应用程序创建一个长时间运行的线程(或者使用线程池,会更快地发生内存泄露). 线程通过某个类加载器(可以自定义)加载一个类. 该类分配了大块内存(比如new byte[1000000]),在某个静态变量存储一个强引用,然后在ThreadLocal中存储它自身的引用.分配额外的内存new byte[

ThreadLocal深入理解与内存泄露分析

ThreadLocal 当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本.从线程的角度看,目标变量就象是线程的本地变量,这也是类名中"Local"所要表达的意思.可以理解为如下三点: 1.每个线程都有自己的局部变量 每个线程都有一个独立于其他线程的上下文来保存这个变量,一个线程的本地变量对其他线程是不可见的. 2.独立于变量的初始化副本 ThreadLocal