前言
沈阳刚刚入职，最近在阅读之前同事的代码，因为他的架构设计中使用了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虽然好用，但是不要滥用。
