Handler的使用陷阱

前言

沈阳刚刚入职，最近在阅读之前同事的代码，因为他的架构设计中使用了Handler模型，所以再次总结一下Handler的使用问题，这也面试的常见问题之一。

本文中可能涉及到一些源码相关的问题，建议先了解一下Handler源码。

正文

问题一：构建Handler异常

Handler与Looper，MessageQueue协作，是Android线程切换的主要手段之一，官方推荐开发者自己指定Handler的执行线程，如果你使用的Handler构造函数是无参构造方法：

在这里插入图片描述

标记有删除线的方法，表示该方法已经废弃，如果在开发中遇到了这样的方法一定要了解具体api废弃的原因，这样可以帮助我们避免很多意想不到的问题，例如：

Default constructor associates this handler with the Looper for the current thread. If this thread does not have a looper, this handler won't be able to receive messages so an exception is thrown.
Deprecated
Implicitly choosing a Looper during Handler construction can lead to bugs where operations are silently lost (if the Handler is not expecting new tasks and quits), crashes (if a handler is sometimes created on a thread without a Looper active), or race conditions, where the thread a handler is associated with is not what the author anticipated. Instead, use an java.util.concurrent.Executor or specify the Looper explicitly, using Looper.getMainLooper, {link android.view.View#getHandler}, or similar. If the implicit thread local behavior is required for compatibility, use new Handler(Looper.myLooper()) to make it clear to readers.

大概的意思就是Handler默认的构造方法会使用Looper.myLooper()作为Handler的执行线程，如果当前线程没有调用过Looper.prepare()，就会抛出异常：

public Handler(@Nullable Callback callback, boolean async) {
       ...
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread " + Thread.currentThread()
                        + " that has not called Looper.prepare()");
        }
       ...
    }

所以为了避免这个异常，我们最好显式的指定Looper。除了提前调用Looper.prepare()，我们还可以使用HandlerThread帮助我们创建Looper，然后再绑定到Handler上：

val handlerThread = HandlerThread("test")
handlerThread.start()
val handler = Handler(handlerThread.looper)

到现在我还有疑问，HandlerThread仅仅是为当前线程创建了Looper，为什么不叫LooperThread？既然和Handler的关联如此密切，为什么getThreadHandler()没有开放？希望有心得朋友留言帮我解开这个问题。

@NonNull
public Handler getThreadHandler() {
    if (mHandler == null) {
        mHandler = new Handler(getLooper());
    }
    return mHandler;
}

问题二：内存泄漏

这个问题网上已经有了很多的讨论和分享，这个简单的总结一下问题的原因：

如果Handler作为Context（Activity/Service等等）的内部类，默认内部类持有外部类的引用；
通过Handler.post或Handler.postDelay执行一个任务之前，Context已经退出（Activity.finish）, MessageQueue仍然持有这个任务，在任务都完成之前，Activity因为强引用关系，无法立即回收，导致内存泄漏或是Context使用不当导致程序崩溃；

解决办法也非常的简单，首先通过静态内部类的方式解决强引用的问题，如果需要引用关系，通过WeakReference修改Handler与Activity的引用关系为弱引用，然后每次使用Handler的时候也去判断一下是否Activity已经被销毁了，防止意外操作：

    /**
     * Kotlin default is static inner class
     * */
    open class SafeHandler(looper: Looper, activity: Activity) : Handler(looper) {

        private val weakActivity = WeakReference(activity)

        override fun dispatchMessage(msg: Message) {
            // activity has destroyed, do not need dispatchMessage
            if (isActivityDestroyed()) {
                return
            }

            super.dispatchMessage(msg)
        }

        override fun sendMessageAtTime(msg: Message, uptimeMillis: Long): Boolean {
            // activity has destroyed, do not need sendMessageAtTime
            if (isActivityDestroyed()) {
                return false
            }
            return super.sendMessageAtTime(msg, uptimeMillis)
        }

        private fun isActivityDestroyed(): Boolean {
            // activity has recycled, do not need dispatchMessage
            if (weakActivity.get() == null) {
                return true
            }

            // activity has destroyed, do not need dispatchMessage
            if (weakActivity.get()!!.isFinishing || weakActivity.get()!!.isDestroyed) {
                return true
            }

            return false
        }

    }

    private val mSafeHandler = object : SafeHandler(Looper.getMainLooper(), this) {

        override fun handleMessage(msg: Message) {
            super.handleMessage(msg)
            // do some thing
        }

    }

上面的代码用的是Kotlin，默认内部类就是静态的，Java静态内部类请使用：

static class SafeHandler extends Handler 

除此之外，我们还应该在Activity销毁或Handler使用结束时，手动调用removeCallbacksAndMessages方法，及时清除掉残留的任务：

handler.removeCallbacksAndMessages(null)

问题三：任务执行时间的不稳定性

首先要明确一点：Handler的任务调度是单线程模型。对于某些延迟任务，例如我们需要500毫秒后，执行某个任务，可以使用Handler：

Handler.postDelay({ /**do some thing*/}, 500)

但是这个500毫秒准确吗？答案是非常不稳定，因为Handler是单线程模型，如果是中间等待的500ms中，Handler开启了一个耗时任务，只有它结束了，Looper才能继续继续取出下一个Message，例如下面的代码：

fun startPost() {
    // 10s task
    mHandler.post {
        Log.e("lzp", "Sleep Task start")
        Thread.sleep(10_000)
    }

    // 1s delay task
    mHandler.postDelayed({
        Log.e("lzp", "Delay Task start")
    }, 1000)
}

按照我的期望，应该是1s后就立刻执行延时任务，但是我不小心之前跑了一个10s的任务，看一下log：

在这里插入图片描述

中间正好间隔了10s，等10s任务结束，Looper发现延时的任务的时间戳早就过了，于是立刻执行了延时任务。这不符合我的期望，为了解决这个问题，必须将10s任务放入其他线程中，停止占用当前线程的资源。

除了单线程模型的问题，Handler的调度还会收到系统的影响，如果app在后台，Handler可能会执行慢或不执行，所以Handler也并不适合后台任务。

所以总结一句话：Handler适合执行短小精悍，反应迅速，执行时间要求不精确的任务，它是一个调度角色，而非执行角色。

总结

以上三个问题就是今天跟大家分享的内容，Handler作为Android线程调度老大哥，个人觉得它的解耦方式有点类似于观察者模式，阅读代码时反复横跳，对于阅读体验还是影响挺大的，所以Handler虽然好用，但是不要滥用。