记一次Handler的优化

为什么要使用Handler


Handler是Android提供的一套消息机制。由于Android的开发规范限制(UI控件非线程安全),更新UI的操作必须在主线程完成。所以大部分人对Handler的理解主要是用来更新UI的,包括我一直以来也都是这样理解滴。但这仅仅是Handler的一个特殊使用场景。
和Handler一起为大家所知的还有它的两兄弟LooperMessageQueue,这三驾马车一起构成了Android的消息机制,但是本文只讨论Handler。

Handler是如何实现消息机制的


Handler重载了很多的构造方法,但是内部原理都一样。在创建时会使用当前线程的Looper来构建内部的消息循环系统。

public Handler(Callback callback, boolean async) {
        if (FIND_POTENTIAL_LEAKS) {// 写法校验
            final Class klass = getClass();
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                    (klass.getModifiers() & Modifier.STATIC) == 0) {
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                    klass.getCanonicalName());
            }
        }

        mLooper = Looper.myLooper();// 引用当前线程的Looper
        if (mLooper == null) {// mLooper什么时候会为空?只有当在子线程中创建Handler,又未提前调用Looper.prepare()
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;// 引用Looper中的消息队列
        mCallback = callback;// 这个是Handler.Callback对象,等会我们会详细讲解
        mAsynchronous = async;
    }

Handler创建完毕后,就可以通过这个handler对象发送一个消息,这个消息会进入消息队列,因为Looper的消息队列一直在循环,一旦消息到来,就会通过Handler的dispatchMessage()方法来进行分发处理。因为Looper是运行在创建Handler所在的线程,为什么这么说,看如下源码:

private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {// prepare在一个线程中只能调用一次
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));// 实例化的Looper被放入线程变量,接下来我们看看Looper的构造器做了什么工作
    }

private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);// 初始化了消息队列
        mThread = Thread.currentThread();// 关联了当前的线程
    }

所以这样一来Handler中的业务逻辑就被切换到创建Handler所在的线程中去执行了。
依据上述,纠正很多初学者的一点疑虑:Handler也可以在子线程中创建,只要姿势正确,先调用一下Looper.prepare()就可以。这样创建的子线程也能拥有消息机制,但这个Handler是不能做UI更新的。

Handler使用过程中问题


通常大家看到很多Handler实例化的过程是这样的:

Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            // 根据消息类别做处理
        }
};

这时候会看到编辑器友好善意的Warning: * This Handler class should be static or leaks might occur (anonymous android.os.Handler)*
这个问题是说Handler应该被声明称静态内部类,否则就可能会导致内存泄露。what the fu*k r u saying? 因为java中匿名类默认持有外部类对象的引用,不然你也不可能直接在内部类里面直接使用外部类的属性。如果外部类正欲销毁,而在handleMessage里面恰好有新的消息到达需要处理,匿名类持有外部类对象就不会被释放。另外,注意非静态内部类也默认持有外部类对象的引用。

解决方案


方案一:

只要将匿名类修改成静态的内部类,并将外部类改为弱引用,例如:

private static final class MyHandler extends Handler{
        private WeakReference mReference;
        public MyHandler(Activity activity){
            mReference = new WeakReference<>(activity);
        }
        @Override
        public void handleMessage(Message msg) {
            // 消息处理
            Activity activity = mReference.get();
            switch(msg.what){
                case XX:
                    if(activity != null){
                        // 做你的UI更新去吧
                    }
                    break;
            }
        }
    }

并在外部类销毁的时候调用Handler的removeCallbacksAndMessages(null)去释放当前handler发送到消息队列的消息。咦,这里为什么还有CallBack呢?因为handler还可以post一个Runnable对象,而这个对象会被包装成Message对象,这个是在消息分发的时候优先执行的。不信,你看

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {// post出去的Runnable
            handleCallback(msg);
        } else {
            if (mCallback != null) {// 这里我们可以实现Handler.Callback接口来处理消息
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);// 通常重新的handleMessage消息处理方法
        }
    }

方案二:

如果认真看以上Handler的消息分发dispatchMessage()的执行流程,不难发现,我们还可以这样安全的使用Handler。

private Handler mHandler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            // 根据消息类别做处理
            return false;
        }
    });

以上观点纯属个人见解,若有出入,欢迎各位书友一起探讨。

上一篇:一招搞定Android Activity的管理

你可能感兴趣的:(记一次Handler的优化)