美文网首页面试汇总Android 踩坑记Android内存泄露
Android之Handler内存泄漏分析及解决

Android之Handler内存泄漏分析及解决

作者: wingjay | 来源:发表于2015-06-02 10:16 被阅读13406次

    一、介绍

    首先,请浏览下面这段handler代码:

    public class SampleActivity extends Activity {
      private final Handler mLeakyHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
          // ... 
        }
      }
    }
    

    在使用handler时,这是一段很常见的代码。但是,它却会造成严重的内存泄漏问题。在实际编写中,我们往往会得到如下警告:

     ⚠ In Android, Handler classes should be static or leaks might occur.
    

    那么,handler是如何造成内存泄漏的呢?

    二、分析

    1、 Android角度

    当Android应用程序启动时,framework会为该应用程序的主线程创建一个Looper对象。这个Looper对象包含一个简单的消息队列Message Queue,并且能够循环的处理队列中的消息。这些消息包括大多数应用程序framework事件,例如Activity生命周期方法调用、button点击等,这些消息都会被添加到消息队列中并被逐个处理。
    另外,主线程的Looper对象会伴随该应用程序的整个生命周期。

    然后,当主线程里,实例化一个Handler对象后,它就会自动与主线程Looper的消息队列关联起来。所有发送到消息队列的消息Message都会拥有一个对Handler的引用,所以当Looper来处理消息时,会据此回调[Handler#handleMessage(Message)](http://developer.android.com/reference/android/os/Handler.html#handleMessage(android.os.Message)方法来处理消息。

    2、 Java角度

    在java里,非静态内部类匿名类 都会潜在的引用它们所属的外部类。但是,静态内部类却不会。

    三、泄漏来源

    请浏览下面一段代码:

    public class SampleActivity extends Activity {
    
      private final Handler mLeakyHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
          // ...
        }
      }
    
      @Override
      protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    
        // Post a message and delay its execution for 10 minutes.
        mLeakyHandler.postDelayed(new Runnable() {
          @Override
          public void run() { /* ... */ }
        }, 1000 * 60 * 10);
    
        // Go back to the previous Activity.
        finish();
      }
    }
    

    当activity结束(finish)时,里面的延时消息在得到处理前,会一直保存在主线程的消息队列里持续10分钟。而且,由上文可知,这条消息持有对handler的引用,而handler又持有对其外部类(在这里,即SampleActivity)的潜在引用。这条引用关系会一直保持直到消息得到处理,从而,这阻止了SampleActivity被垃圾回收器回收,同时造成应用程序的泄漏
    注意,上面代码中的Runnable类--非静态匿名类--同样持有对其外部类的引用。从而也导致泄漏。

    四、泄漏解决方案

    首先,上面已经明确了内存泄漏来源:

    1. 只要有未处理的消息,那么消息会引用handler,非静态的handler又会引用外部类,即Activity,导致Activity无法被回收,造成泄漏;
    2. Runnable类属于非静态匿名类,同样会引用外部类。
      为了解决遇到的问题,我们要明确一点:静态内部类不会持有对外部类的引用。所以,我们可以把handler类放在单独的类文件中,或者使用静态内部类便可以避免泄漏。
      另外,如果想要在handler内部去调用所在的外部类Activity,那么可以在handler内部使用弱引用的方式指向所在Activity,这样统一不会导致内存泄漏。
      对于匿名类Runnable,同样可以将其设置为静态类。因为静态的匿名类不会持有对外部类的引用。
    public class SampleActivity extends Activity {
    
      /**
       * Instances of static inner classes do not hold an implicit
       * reference to their outer class.
       */
      private static class MyHandler extends Handler {
        private final WeakReference<SampleActivity> mActivity;
    
        public MyHandler(SampleActivity activity) {
          mActivity = new WeakReference<SampleActivity>(activity);
        }
    
        @Override
        public void handleMessage(Message msg) {
          SampleActivity activity = mActivity.get();
          if (activity != null) {
            // ...
          }
        }
      }
    
      private final MyHandler mHandler = new MyHandler(this);
    
      /**
       * Instances of anonymous classes do not hold an implicit
       * reference to their outer class when they are "static".
       */
      private static final Runnable sRunnable = new Runnable() {
          @Override
          public void run() { /* ... */ }
      };
    
      @Override
      protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    
        // Post a message and delay its execution for 10 minutes.
        mHandler.postDelayed(sRunnable, 1000 * 60 * 10);
    
        // Go back to the previous Activity.
        finish();
      }
    }
    

    五、小结

    虽然静态类与非静态类之间的区别并不大,但是对于Android开发者而言却是必须理解的。至少我们要清楚,如果一个内部类实例的生命周期比Activity更长,那么我们千万不要使用非静态的内部类。最好的做法是,使用静态内部类,然后在该类里使用弱引用来指向所在的Activity。

    六、译文原文

    多谢:How to Leak a Context: Handlers & Inner Classes

    相关文章

      网友评论

      • 景阳_jy:handler声明为static后,那handleMessage方法中需要处理的变量都得设置成static了,这样会不会有其他影响?
      • 蛋西:文章写的是不错的,其实最好是在onDestory的时候,把本activity加入的消息队列清空,这样就不用搞这么多静态内部类和静态对象了,楼主觉得咋样
        大棋17: @蛋西 好的 非常感谢😬
        蛋西:@大棋17 亲测有效的,我项目中就是这么用
        大棋17:最后你发现这个清空队列比那个静态内部类有效吗,还有在onDestory()中退出子线程+onDestoryView()清空队列能不能解决这内存泄漏问题
      • Dragon_Boat:那在Activity中的点击事件 很容易就是内部类啊?view.setOnClickListener(new OnClickListener)这种怎么办
        一个不熬夜的孩子:额,handler会出现内存泄漏的主要原因有两个吧:
        1. 例如文章说的,Handler 发送的Message在MessageQueue中逗留的时间过长,因为Message是保存了Handler的,而Handler持有了Activity
        2. 子线程长时间持有了Handler

        而你说的onclicke的话,他也是发送到MessageQueue中处理的,但是逗留的时间不会长,所以不会因为OnClickListener而导致内存泄漏
        wingjay:@Dragon_Boat 不是内部类导致泄漏,而是内部类的实例的生命周期太长。比如handler里的延时消息,当退出activity而消息仍未处理时才会泄漏
      • 8a32830db390:为什么不是private static Handler mHandler = new Handler(){……};这样可以嘛?
        塘泥:这样岂不是更差了,静态变量也是导致内存泄漏的一大元凶啊
      • EdwdChen: 我想问一下, private final MyHandler mHandler = new MyHandler(this);
        为什么mHandler要加final关键字呢,不加的话会有什么影响吗?
        一个不熬夜的孩子:@曾是放牛娃 final 这样添加不会提高效率吧(我觉得),我认为作者在这里给handler添加一个final是因为不让其他地方修改这个引用吧。也就是说在其他方法可以放心的使用他,因为他没有改变过也不会被改变
        曾是放牛娃:就是final关键字本身的含义,加不加final都可以,加了final可以提高性能
      • 小城探路者:还有问题是这么解决的话我在handmessage中或者runnable的run方法中的方法都必须是静态的了?这个有没有办法解
        3d6d8d2a9740:@小城探路者 你好,这是我的邮箱请问这个问题你是怎么解决的呢 natobww@gmail.com
        3d6d8d2a9740:@小城探路者 同问我也是的,方法全得变成静态的否则就是编译不过去的
      • 754cbca61901:感谢分享,有了新的认识
      • 获取失败:你好 请问下 handler postDelayed之后 message queue里面的message被处理了 这时handler就没有被引用了 相应activity也没有被引用了 最终GC还是可以回收掉activity? 只不过是暂时无法回收 最终都会被回收掉吗?
        feel_ing:@先不设置 暂时的,message被处理了就不会持有handler的引用,handler就可以被回收了继而引用的Activity也可以被回收
      • smallwind:叙述调理清楚,小白表示收获极大。
      • chonrp27512:楼主,能否说说,为什么会潜在的引用外部类
        chonrp27512:@iam_wingjay 原因是java在生成内部类的时候,原本没有构造器的内部类会被生成一个带外部类参数的构造器,就是因为这个内部类才持有了外部类的隐式引用。
        wingjay:@chonrp27512 内部类是依赖于外部类的,你可以看生成的class文件
        chonrp27512:@chonrp27512 怎么去观测?用什么手段方法或者工具?
      • c4563f36939c:其实还有点小问题,onDestroy之后还是可以操作Activity实例
        http://blog.csdn.net/card361401376/article/details/51493352
      • 蔡奇奇:讲的很有逻辑性!点到为止,想看的可以点开链接详细看,不想仔细看的可以略过并不影响阅读体验
        wingjay:@苹方 你好,麻烦看仔细点,我这篇是翻译的,底部有译文原文。http://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.html
        vincgao:@蔡奇奇 抄袭可耻http://droidyue.com/blog/2014/12/28/in-android-handler-classes-should-be-static-or-leaks-might-occur/

      本文标题:Android之Handler内存泄漏分析及解决

      本文链接:https://www.haomeiwen.com/subject/muldqttx.html