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>(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虽然好用,但是不要滥用。

推荐阅读更多精彩内容