Weak Handler 与 内存泄露

最新推荐文章于 2021-03-06 13:53:16 发布
最新推荐文章于 2021-03-06 13:53:16 发布
阅读量1.8k 收藏
点赞数 1

一个通用的场景是 使用 匿名内部类 实例 作为某个 行为/动作的 回调,如果该行为/动作 是异步的,则其返回时间往往无法确定,有造成内存泄露风险.

使用静态内部类,或者妥善处理生命周期,都不会造成内存泄露,反过来,当没有内存泄露风险时,一般直接匿名内部类即可.

这其实是一个特别矛盾的说法.

因为这要求程序员能 能了解到 回调行为是在何时发生的.

而相反,我们设计接口回调的时候总是尽力屏蔽内部实现细节.

而面对不确定的行为,当然也可以使用静态内部类,或者removeCallback去取消回调(特指Handler),然而这样代码变得繁琐,或者添加不必要的代码.

对于Handler,一个简单的第三方解决方案是使用 android-weak-handler ,该库尝试使用WeakReference解决这个问题,然而却引入新的问题.

https://github.com/badoo/android-weak-handler

核心代码如下:

public class WeakHandler {
    private final Handler.Callback mCallback; // hard reference to Callback. We need to keep callback in memory
    private final ExecHandler mExec;
    private Lock mLock = new ReentrantLock();
    @SuppressWarnings("ConstantConditions")
    @VisibleForTesting
    final ChainedRef mRunnables = new ChainedRef(mLock, null);

    public WeakHandler() {
        mCallback = null;
        mExec = new ExecHandler();
    }

    public WeakHandler(@Nullable Handler.Callback callback) {
        mCallback = callback; // Hard referencing body
        mExec = new ExecHandler(new WeakReference<>(callback)); // Weak referencing inside ExecHandler
    }

    public WeakHandler(@NonNull Looper looper) {
        mCallback = null;
        mExec = new ExecHandler(looper);
    }

    public WeakHandler(@NonNull Looper looper, @NonNull Handler.Callback callback) {
        mCallback = callback;
        mExec = new ExecHandler(looper, new WeakReference<>(callback));
    }

    public final boolean post(@NonNull Runnable r) {
        return mExec.post(wrapRunnable(r));
    }

    public final boolean postAtTime(@NonNull Runnable r, long uptimeMillis) {
        return mExec.postAtTime(wrapRunnable(r), uptimeMillis);
    }

    public final boolean postAtTime(Runnable r, Object token, long uptimeMillis) {
        return mExec.postAtTime(wrapRunnable(r), token, uptimeMillis);
    }

    public final boolean postDelayed(Runnable r, long delayMillis) {
        return mExec.postDelayed(wrapRunnable(r), delayMillis);
    }

    public final boolean postAtFrontOfQueue(Runnable r) {
        return mExec.postAtFrontOfQueue(wrapRunnable(r));
    }

    public final void removeCallbacks(Runnable r) {
        final WeakRunnable runnable = mRunnables.remove(r);
        if (runnable != null) {
            mExec.removeCallbacks(runnable);
        }
    }

    public final void removeCallbacks(Runnable r, Object token) {
        final WeakRunnable runnable = mRunnables.remove(r);
        if (runnable != null) {
            mExec.removeCallbacks(runnable, token);
        }
    }

    public final boolean sendMessage(Message msg) {
        return mExec.sendMessage(msg);
    }

    public final boolean sendEmptyMessage(int what) {
        return mExec.sendEmptyMessage(what);
    }

    public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
        return mExec.sendEmptyMessageDelayed(what, delayMillis);
    }

    public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) {
        return mExec.sendEmptyMessageAtTime(what, uptimeMillis);
    }

    public final boolean sendMessageDelayed(Message msg, long delayMillis) {
        return mExec.sendMessageDelayed(msg, delayMillis);
    }

    public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        return mExec.sendMessageAtTime(msg, uptimeMillis);
    }

    public final boolean sendMessageAtFrontOfQueue(Message msg) {
        return mExec.sendMessageAtFrontOfQueue(msg);
    }

    public final void removeMessages(int what) {
        mExec.removeMessages(what);
    }

    public final void removeMessages(int what, Object object) {
        mExec.removeMessages(what, object);
    }

    public final void removeCallbacksAndMessages(Object token) {
        mExec.removeCallbacksAndMessages(token);
    }

    public final boolean hasMessages(int what) {
        return mExec.hasMessages(what);
    }

    public final boolean hasMessages(int what, Object object) {
        return mExec.hasMessages(what, object);
    }

    public final Looper getLooper() {
        return mExec.getLooper();
    }

    private WeakRunnable wrapRunnable(@NonNull Runnable r) {
        //noinspection ConstantConditions
        if (r == null) {
            throw new NullPointerException("Runnable can't be null");
        }
        final ChainedRef hardRef = new ChainedRef(mLock, r);
        mRunnables.insertAfter(hardRef);
        return hardRef.wrapper;
    }

    private static class ExecHandler extends Handler {
        private final WeakReference<Handler.Callback> mCallback;

        ExecHandler() {
            mCallback = null;
        }

        ExecHandler(WeakReference<Handler.Callback> callback) {
            mCallback = callback;
        }

        ExecHandler(Looper looper) {
            super(looper);
            mCallback = null;
        }

        ExecHandler(Looper looper, WeakReference<Handler.Callback> callback) {
            super(looper);
            mCallback = callback;
        }

        @Override
        public void handleMessage(@NonNull Message msg) {
            if (mCallback == null) {
                return;
            }
            final Handler.Callback callback = mCallback.get();
            if (callback == null) { // Already disposed
                return;
            }
            callback.handleMessage(msg);
        }
    }

    static class WeakRunnable implements Runnable {
        private final WeakReference<Runnable> mDelegate;
        private final WeakReference<ChainedRef> mReference;

        WeakRunnable(WeakReference<Runnable> delegate, WeakReference<ChainedRef> reference) {
            mDelegate = delegate;
            mReference = reference;
        }

        @Override
        public void run() {
            final Runnable delegate = mDelegate.get();
            final ChainedRef reference = mReference.get();
            if (reference != null) {
                reference.remove();
            }
            if (delegate != null) {
                delegate.run();
            }
        }
    }

    static class ChainedRef {
        @Nullable
        ChainedRef next;
        @Nullable
        ChainedRef prev;
        @NonNull
        final Runnable runnable;
        @NonNull
        final WeakRunnable wrapper;

        @NonNull
        Lock lock;

        public ChainedRef(@NonNull Lock lock, @NonNull Runnable r) {
            this.runnable = r;
            this.lock = lock;
            this.wrapper = new WeakRunnable(new WeakReference<>(r), new WeakReference<>(this));
        }

        public WeakRunnable remove() {
            lock.lock();
            try {
                if (prev != null) {
                    prev.next = next;
                }
                if (next != null) {
                    next.prev = prev;
                }
                prev = null;
                next = null;
            } finally {
                lock.unlock();
            }
            return wrapper;
        }

        public void insertAfter(@NonNull ChainedRef candidate) {
            lock.lock();
            try {
                if (this.next != null) {
                    this.next.prev = candidate;
                }

                candidate.next = this.next;
                this.next = candidate;
                candidate.prev = this;
            } finally {
                lock.unlock();
            }
        }

        @Nullable
        public WeakRunnable remove(Runnable obj) {
            lock.lock();
            try {
                ChainedRef curr = this.next; // Skipping head
                while (curr != null) {
                    if (curr.runnable == obj) { // We do comparison exactly how Handler does inside
                        return curr.remove();
                    }
                    curr = curr.next;
                }
            } finally {
                lock.unlock();
            }
            return null;
        }
    }
}

这个类的实现有个问题,为了避免持有Runnable的引用,使用WeakRunnable作为Wrapper,为了能够在Activity销毁时释放Runnable,这里使用的WeakReference去持有Runnable引用.
从目的上看,它确实解决了由于Runnable隐式持有Activity强引用而导致Acticity实例无法销毁的问题

但是

作为匿名内部类被传入的Runnable对象如果只存在一个WeakReference,那意味着,任何一次GC操作都将导致其被回收.
看看这个例子

import com.badoo.mobile.util.WeakHandler;

public class ExampleActivity extends Activity {

    private WeakHandler mHandler; // We still need at least one hard reference to WeakHandler

    protected void onCreate(Bundle savedInstanceState) {
        mHandler = new WeakHandler();
        ...
    }

    private void onClick(View view) {
        mHandler.postDelayed(new Runnable() {
            view.setVisibility(View.INVISIBLE);
        }, 5000);
    }
}

如果在这5s内系统触发了一次GC操作会怎么样? Runnable会被回收?

将Demo简单修改一下

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    WeakHandler  mHandler = new WeakHandler();
    mHandler.postDelayed(new Runnable() {


        @Override
        public void run() {
            System.out.println("####################### Do Something");
            );
        }
    }, 10000);

    mHandler.postDelayed(new Runnable() {


        @Override
        public void run() {
            System.out.println("#######################GC");

            System.gc();
        }
    }, 5000);

}

看看运行结果,GC操作发生了,而Do Something并没有执行,因为 GC动作发生时, WeakReference持有的Runnable已经被释放了.

通常来讲,GC操作发生的时间不可预料的,你无法预期等待回调的这几秒种内用户做了什么操作,而一旦触发了GC,则回调会被立刻取消

注意,Activity并未被关闭,Runnable回调也会被释放!

如果在大型项目中遇到这样的问题,排查一定是灾难性的.因为GC的不确定性,出现了回调丢失情况一定是随机的,难以预测的,难以重现的.

而处理这个问题的办法是,将mHandler从临时变量 换成 成Activity的一个实例变量.

然而通常程序员不一定意识这2种写法的区别,而且使用系统提供的Handler时,这2种写法是没有区别的.

最后我检查了下文档,作者还是写了一句话作为提示

We still need at least one hard reference to WeakHandler

至于使用者是否能意识到问题所在我持怀疑态度.

第三方库就是容易出现这种问题,使用起来能很方便的解决很多问题,然而又很容易挖几个隐蔽的坑给你.

richie0006
关注
专栏目录
对于handler内存泄漏分析解决+实例
携墨的博客
07-17 1741
先说说什么是内存泄漏？ 内存泄漏是简单意义来讲就是长生命周期对象引用短生命周期的对象，导致GC无法回收，会一直占用内存。那么就有可能导致内存溢出 内存泄漏最终会导致内存溢出，程序就崩掉了，没有正确的使用handler就会导致这样的问题发生 比如：当A对象，被B对象所引用，当B对象没有释放时，A对象不能被回收（A短B长）,A对象可能造成内存泄漏 什么是内存溢出? 当一个程序内存泄漏过多或者内
Android播放动画内存泄露,详解Android性能优化之内存泄漏
weixin_28797725的博客
05-25 1056
综述内存泄漏(memory leak)是指由于疏忽或错误造成程序未能释放已经不再使用的内存。那么在Android中，当一个对象持有Activity的引用，如果该对象不能被系统回收，那么当这个Activity不再使用时，这个Activity也不会被系统回收，那这么以来便出现了内存泄漏的情况。在应用中内出现一次两次的内存泄漏获取不会出现什么影响，但是在应用长时间使用以后，若是存在大量的Activity...
Android代码-android-weak-handler
08-07
Android Weak Handler Memory safer implementation of android.os.Handler Problem Original implementation of Handler always keeps hard reference to handler in queue of execution. Any object in Message or Runnable posted to android.os.Handler will be hard referenced for some time. If you create anonymous Runnable and call to postDelayed with large timeout, that Runnable will be held in memory until timeout passes. Even if your Runnable seems small, it indirectly references owner class, which is us
Android Weak Handler：可以避免内存泄漏的Handler库
u011494050的专栏
11-24 1524
android使用java作为其开发环境。java的跨平台和垃圾回收机制已经帮助我们解决了底层的一些问题。但是尽管有了垃圾回收机制，在开发android的时候仍然时不时的遇到out of memory的问题，这个时候我们不禁要问，垃圾回收机器去哪儿了？ 我们主要讲的是handler引起的泄漏，并给出三种解决办法，其中最后一种方法就是我们想介绍的WeakHandler 库。 可能导致泄漏
WeakHandler
Qw的博客
03-06 164
public class WeakHandler { private final Handler.Callback mCallback; // hard reference to Callback. We need to keep callback in memory private final ExecHandler mExec; private final Lock mLock = new ReentrantLock(); @VisibleForTesting p
Weak Handler
云淡风轻的博客
03-21 1300
注：如何对内存要求优化非常高的app 可以干掉系统的handler 用Weak Handler 处理 package com.systoon.business.home.holder; import android.os.Handler; import android.os.Looper; import android.os.Message; import android.support....
android 中Handler 对内存造成溢出和泄露的优化方案 使用 Weak Handler Memory safer implementation of android.os.Handler
qq_30519365的博客
06-10 1313
github 地址 学习地址 https://github.com/badoo/android-weak-handler 注：如何对内存要求优化非常高的app 可以干掉系统的handler 用Weak Handler 处理 dependencies { compile 'com.badoo.mobile:android-weak-handler:1.1' } import
浅谈Android应用的内存优化及Handler的内存泄漏问题
01-20
本文主要探讨Android应用的内存优化以及Handler可能导致的内存泄漏问题。 首先，理解Android内存的基础至关重要。Android系统在运行应用时，会为每个应用启动一个Dalvik或ART虚拟机进程，并分配一定的内存空间，这...
iOS WKWebView中MessageHandler内存泄漏问题的完美解决过程
08-27
本文将详细讲解如何解决iOS WKWebView中MessageHandler内存泄漏的问题。 首先，我们需要理解问题的根源。当我们在`WKUserContentController`中添加`ScriptMessageHandler`，例如`addScriptMessageHandler:self name...
支持避免内存泄漏的Handler库
04-04
源码android-weak-handler，android使用java作为其开发环境。java的跨平台和垃圾回收机制已经帮助我们解决了底层的一些问题。但是尽管有了垃圾回收机制，在开发android的时候仍然时不时的遇到out of memory的问题，...
android-weak-handler:android.os.Handler的内存安全实现
04-05
Android弱处理程序 android.os.Handler的内存安全实现 问题 Handler的原始实现始终在执行队列中始终保持对处理程序的硬引用。 张贴到android.os.Handler Message或Runnable中的任何对象将在一段时间内被硬引用。 如果创建匿名Runnable并以较大的超时调用postDelayed ，则该Runnable将保留在内存中，直到超时为止。 即使您的Runnable看起来很小，它也会间接引用所有者类，该类通常与Activity或Fragment一样大。 您可以 阅读更多 。 解决方案 WeakHandler比android.os.Handler棘手，它将WeakReferences保留到可运行对象和消息中，一旦不再引用WeakHandler实例，GC便可以收集它们。 用法 将JitPack存储库添加到您的build.gradle中： re
Android apk开发：不重复造轮子，抽象泛型基类WeakHandler
Android
03-07 270
说起Handler，我们都知道在开发中为了避免内存泄漏，要采取静态内部类+弱引用的形式，并且在onDestroy中调用mHandler.removeCallbacksAndMessages(null);方法移除全部消息。本着不重复造轮子的原则，特意整了一个抽象泛型基类AbstractWeakHandler，便于快速使用。 public abstract class AbstractWeakHand...
Android WeakReference的应用：自定义Handler : WeakHandler
欢迎来到Cozing的博客
08-16 2415
背景：     WeakReference（弱引用）作用：防止被强引用的对象的内存不被释放。     android开发中使用Handler出现的情况，比如在Activity内部new一个Handler： Handler mHandler = new Handler(){ @Override public void handl...
Handler使用WeakReference
u010588886的专栏
08-15 924
public class HandlerActivity extends Activity {private String string = "string";@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);new Thread(new Runnable(
ViewPager+Fragment收集研究
Long的专栏
12-13 240
这里写链接内容这里写链接内容
Handler还需要用到弱引用(WeakReference)吗?
alcoholdi的专栏
02-09 4147
网上很多文章都说写Hanlder，需要用static声明为静态的，还需要用弱引用包裹构造函数传来的Activity实例。 比如这篇英文博客 http://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.html 里面的Sample是这样写的 public class SampleAct...
Activity Handler 使用 WeakReference
shion1986_0514的专栏
10-24 303
public class MainActivity extends FragmentActivity { private final mHandler mhandler = new mHandler(this); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreat
Android Handler WeakReference 处理
yorkfan019的专栏
01-29 712
在Android开发过程中使用Handler 经常会看到如下提示 ”This Handler class should be static or leaks might occur: IncomingHandler“  这个警告是什么意思呢？？ 同一个线程中的Handler对象共享同一个用于读写消息的Looper对象，由于message 包含目标Handler，只要该message
使用Eclipse MAT插件检测与解决Android内存泄漏
"Android内存泄漏解决方案，通过Eclipse的MAT插件进行内存分析，排查内存泄漏问题" 在Android开发中，内存泄漏是一个重要的性能优化问题，它可能导致应用消耗过多内存，甚至引发应用崩溃。Android ADT虽然提供了...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值