Android内存泄露之Handler

转载 2016年08月29日 16:10:45

Handler也是造成内存泄露的一个重要的源头,主要Handler属于TLS(Thread Local Storage)变量,生命周期和Activity是不一致的
,Handler引用Activity会存在内存泄露。

看一下如下代码

  1. public class HandlerActivity extends Activity {  
  2.   
  3.     private final Handler mHandler = new Handler() {  
  4.         @Override  
  5.         public void handleMessage(Message msg) {  
  6.             // ...  
  7.         }  
  8.     };  
  9.   
  10.     @Override  
  11.     public void onCreate(Bundle savedInstanceState) {  
  12.         super.onCreate(savedInstanceState);  
  13.         setContentView(R.layout.activity_main);  
  14.         mHandler.sendMessageDelayed(Message.obtain(), 60000);  
  15.   
  16.         //just finish this activity  
  17.         finish();  
  18.     }  
  19.   
  20. }  

是否您以前也是这样用的呢。

没有问题?

Eclipse 工具有这样的警告提示 警告: 

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

意思:class 使用静态声明否者可能出现内存泄露。

为啥出现这样的问题呢

Handler 的生命周期与Activity 不一致

  • 当Android应用启动的时候,会先创建一个UI主线程的Looper对象,Looper实现了一个简单的消息队列,一个一个的处理里面的Message对象。主线程Looper对象在整个应用生命周期中存在。
  • 当在主线程中初始化Handler时,该Handler和Looper的消息队列关联(没有关联会报错的)。发送到消息队列的Message会引用发送该消息的Handler对象,这样系统可以调用 Handler#handleMessage(Message) 来分发处理该消息。

handler 引用 Activity 阻止了GC对Acivity的回收

  • 在Java中,非静态(匿名)内部类会默认隐性引用外部类对象。而静态内部类不会引用外部类对象。
  • 如果外部类是Activity,则会引起Activity泄露 。

    当Activity finish后,延时消息会继续存在主线程消息队列中1分钟,然后处理消息。而该消息引用了Activity的Handler对象,然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完,这样就导致该Activity对象无法被回收,从而导致了上面说的 Activity泄露。

如何避免修?

  • 使用显形的引用,1.静态内部类。 2. 外部类
  • 使用弱引用 2. WeakReference

修改代码如下:

  1. public class HandlerActivity2 extends Activity {  
  2.   
  3.     private static final int MESSAGE_1 = 1;  
  4.     private static final int MESSAGE_2 = 2;  
  5.     private static final int MESSAGE_3 = 3;  
  6.     private final Handler mHandler = new MyHandler(this);  
  7.   
  8.     @Override  
  9.     public void onCreate(Bundle savedInstanceState) {  
  10.         super.onCreate(savedInstanceState);  
  11.         setContentView(R.layout.activity_main);  
  12.         mHandler.sendMessageDelayed(Message.obtain(), 60000);  
  13.   
  14.         // just finish this activity  
  15.         finish();  
  16.     }  
  17.   
  18.     public void todo() {  
  19.     };  
  20.   
  21.     private static class MyHandler extends Handler {  
  22.         private final WeakReference<HandlerActivity2> mActivity;  
  23.   
  24.         public MyHandler(HandlerActivity2 activity) {  
  25.             mActivity = new WeakReference<HandlerActivity2>(activity);  
  26.         }  
  27.   
  28.         @Override  
  29.         public void handleMessage(Message msg) {  
  30.             System.out.println(msg);  
  31.             if (mActivity.get() == null) {  
  32.                 return;  
  33.             }  
  34.             mActivity.get().todo();  
  35.         }  
  36.     }  

上面这样就可以了吗?

  当Activity finish后 handler对象还是在Message中排队。 还是会处理消息,这些处理有必要?
  正常Activitiy finish后,已经没有必要对消息处理,那需要怎么做呢?
  解决方案也很简单,在Activity onStop或者onDestroy的时候,取消掉该Handler对象的Message和Runnable。
  通过查看Handler的API,它有几个方法:removeCallbacks(Runnable r)和removeMessages(int what)等。

代码如下:

 
  1. /**  
  2.   * 一切都是为了不要让mHandler拖泥带水  
  3.   */  
  4.  @Override  
  5.  public void onDestroy() {  
  6.      mHandler.removeMessages(MESSAGE_1);  
  7.      mHandler.removeMessages(MESSAGE_2);  
  8.      mHandler.removeMessages(MESSAGE_3);  
  9.   
  10.      // ... ...  
  11.   
  12.      mHandler.removeCallbacks(mRunnable);  
  13.   
  14.      // ... ...  
  15.  }     

如果上面觉的麻烦,也可以如下面:

  1. @Override  
  2. public void onDestroy() {  
  3.     //  If null, all callbacks and messages will be removed.  
  4.     mHandler.removeCallbacksAndMessages(null);  
  5. }  

  • 什么是内存泄露?

    内存泄漏形象的比喻是“操作系统可提供给所有进程的存储空间正在被某个进程榨干”,最终结果是程序运行时间越长,占用存储空间越来越多,最终用尽全部存储空间,整个系统崩溃。Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任何引用所指向,则该对象会在被GC发现的时候被回收;另外,如果一组对象中只包含互相的引用,而没有来自它们外部的引用(例如有两个对象A和B互相持有引用,但没有任何外部对象持有指向A或B的引用),这仍然属于不可到达,同样会被GC回收。

    Android中使用Handler造成内存泄露的原因
    1
    2
    3
    4
    5
    6
    Handler mHandler = new Handler() {  
        @Override  
        public void handleMessage(Message msg) {  
            mImageView.setImageBitmap(mBitmap);  
        }  
    }  


    如下图所示:

    编译器便已提示:该程序类应该是静态的且可能会发生泄漏

    上面是一段简单的Handler的使用。当使用内部类(包括匿名类)来创建Handler的时候,Handler对象会隐式地持有一个外部类对象(通常是一个Activity)的引用(不然你怎么可能通过Handler来操作Activity中的View?)。
    而Handler通常会伴随着一个耗时的后台线程(例如从网络拉取图片)一起出现,这个后台线程在任务执行完毕(例如图片下载完毕)之后,通过消息机制通知Handler,然后Handler把图片更新到界面。

    然而,如果用户在网络请求过程中关闭了Activity,正常情况下,Activity不再被使用,它就有可能在GC检查时被回收掉,但由于这时线程尚未执行完,而该线程持有Handler的引用(不然它怎么发消息给Handler?),这个Handler又持有Activity的引用,就导致该Activity无法被回收(即内存泄露),直到网络请求结束(例如图片下载完毕)。另外,如果你执行了Handler的postDelayed()方法,该方法会将你的Handler装入一个Message,并把这条Message推到MessageQueue中,那么在你设定的delay到达之前,会有一条MessageQueue -> Message -> Handler -> Activity 的链,导致你的Activity被持有引用而无法被回收。

    内存泄露的危害

    只有一个,那就是虚拟机占用内存过高,导致OOM(内存溢出),程序出错。对于Android应用来说,就是你的用户打开一个Activity,使用完之后关闭它,内存泄露;又打开,又关闭,又泄露;几次之后,程序占用内存超过系统限制,FC。

    使用Handler导致内存泄露的解决方法

    方法一:通过程序逻辑来进行保护。

    1.在关闭Activity的时候停掉你的后台线程。线程停掉了,就相当于切断了Handler和外部连接的线,Activity自然会在合适的时候被回收。
    2.如果你的Handler是被delay的Message持有了引用,那么使用相应的Handler的removeCallbacks()方法,把消息对象从消息队列移除就行了。

    方法二:将Handler声明为静态类。

    静态类不持有外部类的对象,所以你的Activity可以随意被回收。代码如下:
    1
    2
    3
    4
    5
    6
    static class MyHandler extends Handler {  
        @Override  
        public void handleMessage(Message msg) {  
            mImageView.setImageBitmap(mBitmap);  
        }  
    }  

    但其实没这么简单。使用了以上代码之后,你会发现,由于Handler不再持有外部类对象的引用,导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    (WeakReference):
    [java] view plaincopyprint?
    static class MyHandler extends Handler {  
        WeakReference<Activity > mActivityReference;  
        MyHandler(Activity activity) {  
            mActivityReference= new WeakReference<Activity>(activity);  
        }  
       
        @Override  
        public void handleMessage(Message msg) {  
            final Activity activity = mActivityReference.get();  
            if (activity != null) {  
                mImageView.setImageBitmap(mBitmap);  
            }  
        }  
    }  
    将代码改为以上形式之后,就算完成了。

    延伸:什么是WeakReference?

    WeakReference弱引用,与强引用(即我们常说的引用)相对,它的特点是,GC在回收时会忽略掉弱引用,即就算有弱引用指向某对象,但只要该对象没有被强引用指向(实际上多数时候还要求没有软引用,但此处软引用的概念可以忽略),该对象就会在被GC检查到时回收掉。对于上面的代码,用户在关闭Activity之后,就算后台线程还没结束,但由于仅有一条来自Handler的弱引用指向Activity,所以GC仍然会在检查的时候把Activity回收掉。这样,内存泄露的问题就不会出现了。

相关文章推荐

android 内存泄露那些事情之Handler(一)

邮箱:zz7zz7zz@163.com微博:http://weibo.com/u/3209971935

Android Handler造成内存泄露的分析和解决

首先回顾下GC回收机制 : Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任...

Android——Handler内存泄露

之前听到这么一句话: Android内存泄露说白了就是长生命周期中存在短生命周期的变量。 内存泄露原因:Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一...

Android中使用Handler造成内存泄露的分析和解决

摘要 内存泄露,听起来很屌的样子?看了这篇文章,你会发现其实这个概念很简单。Android程序经常出现的一个现象是:内存占用越来越大,到最后用户不得不强行关闭程序来释放内存。导致内存越来越大的原因很多...

Android开发:详解Handler的内存泄露

前言 内存泄露在Android开发中非常常见 内存泄露的定义:本该被回收的对象不能被回收而停留在堆内存中 内存泄露出现的原因:当一个对象已经不再被使用时,本该被回收但却因为有另外一个正在使用的...

Android handler的Context内存泄露

Context内存泄露

Android中使用Handler造成内存泄露的分析和解决

什么是内存泄露? Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任何引...

Android中Handler引起的内存泄露

本文转载自博客:Android中Handler引起的内存泄露,谢谢作者的分享。Android中Handler引起的内存泄露在Android常用编程中,Handler在进行异步操作并处理返回结果时经常被...

Android中使用Handler造成内存泄露的分析和解决

Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任何引用所指向,则该对象会在被...

Android中使用Handler造成内存泄露的分析和解决

什么是内存泄露? Java使用有向图机制,通过GC自动检查内存中的对象(什么时候检查由虚拟机决定),如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收。也就是说,一个对象不被任何引...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)