Handler消息机制关键类详解
Posted 小陈乱敲代码
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Handler消息机制关键类详解相关的知识，希望对你有一定的参考价值。
Handler机制关键类
一、ThreadLocal
概述
ThreadLocal是Java中一个用于线程内部存储数据的工具类。
ThreadLocal是用来存储数据的，但是每个线程只能访问到各自线程的数据。我们一般的用法是：
ThreadLocal<String> stringLocal = new ThreadLocal<>();
stringLocal.set("java");
String s = stringLocal.get();
不同的线程之间访问到的数据是不一样的：
public static void main(String[] args)
ThreadLocal<String> stringLocal = new ThreadLocal<>();
stringLocal.set("java");
System.out.println(stringLocal.get());
new Thread()
System.out.println(stringLocal.get());
结果：
java
null
线程只能访问到自己线程存储的数据。
ThreadLocal的作用
ThreadLocal的特性适用于同样的数据类型，不同的线程有不同的备份情况，如我们这篇文章一直在讲的Looper。每个线程都有一个对象，但是不同线程的Looper是不一样的，这个时候就特别适合使用ThreadLocal来存储数据，这也是为什么这里要讲ThreadLocal的原因
ThreadLocal内部结构
ThreadLocal的内部机制结构如下：
每个Thread，也就是每个线程内部维护有一个ThreadLocalMap，ThreadLocalMap内部存储多个Entry。Entry可以理解为键值对，他的本质是一个弱引用，内部有一个object类型的内部变量。
Entry是ThreadLocalMap的一个静态内部类，这样每个Entry里面就维护了一个ThreadLocal和ThreadLocal泛型对象。每个线程的内部维护有一个Entry数组，并通过hash算法使得读取数据的速度达到O(1)。由于不同的线程对应的Thread对象不同，所以对应的ThreadLocalMap肯定也不同，这样只有获取到Thread对象才能获取到其内部的数据，数据就被隔离在不同的线程内部了。
ThreadLocal工作流程
那ThreadLocal是怎么实现把数据存储在不同线程中的？先从他的set方法入手：
TheadLocal.class
public void set(T value)
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
逻辑不是很复杂，首先获取当前线程的Thread对象，然后再获取Thread的ThreadLocalMap对象，如果该map对象不存在则创建一个并调用他的set方法把数据存储起来。我们继续看ThreadLocalMap的set方法：
ThreadLocalMap.class
private void set(ThreadLocal<?> key, Object value)
// 每个ThreadLocalMap内部都有一个Entry数组
Entry[] tab = table;
int len = tab.length;
// 获取新的ThreadLocal在Entry数组中的下标
int i = key.threadLocalHashCode & (len-1);
// 判断当前位置是否发生了Hash冲突
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)])
ThreadLocal<?> k = e.get();
// 如果数据存在且相同则直接返回
if (k == key)
e.value = value;
return;
if (k == null)
replaceStaleEntry(key, value, i);
return;
// 若当前位置没有其他元素则直接把新的Entry对象放入
tab[i] = new Entry(key, value);
int sz = ++size;
// 判断是否需要对数组进行扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
这里的逻辑和HashMap是很像的，我们可以直接使用HashMap的思维来理解ThreadLocalMap:ThreadLocalMap的key是ThreadLocal，value是ThreadLocal对应的泛型。他的存储步骤如下：
根据自身的threadLocalHashCode与数组的长度进行相与得到下标
如果此下标为空，则直接插入
如果此下标已经有元素，则判断两者的ThreadLocal是否相同，相同则更新value后返回，否则找下一个下标
直到找到合适的位置把entry对象插入
最后判断是否需要对entry数组进行扩容
是不是和HashMap非常像？和HashMap的不同是：hash算法不一样，以及这里使用的是开发地址法，而HashMap使用的是链表法。ThreadLocalMap牺牲一定的空间来换取更快的速度。具体的Hash算法这里就不再深入了，有兴趣的读者可以阅读这篇文章ThreadLocal传送门
然后继续看ThreadLocal的get方法：
ThreadLocal.class
public T get()
// 获取当前线程的ThreadLocalMap
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
// 根据ThreadLocal获取Entry对象
ThreadLocalMap.Entry e = map.getEntry(this);
// 如果没找到也会执行初始化工作
if (e != null)
@SuppressWarnings("unchecked")
// 把获取到的对象进行返回
T result = (T)e.value;
return result;
return setInitialValue();
前面讲到ThreadLocalMap其实非常像一个HashMap，他的get方法也是一样的。使用ThreadLocal作为key获取到对应的Entry，再把value返回即可。如果map尚未初始化则会执行初始化操作。下面继续看下ThreadLocalMap的get方法：
ThreadLocalMap.class
private Entry getEntry(ThreadLocal<?> key)
// 根据hash算法找到下标
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
// 找到数据则返回，否则通过开发地址法寻找下一个下标
if (e != null && e.get() == key)
return e;
else
return getEntryAfterMiss(key, i, e);
利用ThreadLocal的threadLocalHashCode得到下标，然后根据下标找到数据。没找到则根据算法寻找下个下标。
内存泄露问题
我们会发现Entry中，ThreadLocal是一个弱引用，而value则是强引用。如果外部没有对ThreadLocal的任何引用，那么ThreadLocal就会被回收，此时其对应的value也就变得没有意义了，但是却无法被回收，这就造成了内存泄露。怎么解决？在ThreadLocal回收的时候记得调用其remove方法把entry移除，防止内存泄露。
ThreadLocal总结
ThreadLocal适合用于在不同线程作用域的数据备份
ThreadLocal机制通过在每个线程维护一个ThreadLocalMap，其key为ThreadLocal，value为ThreadLocal对应的泛型对象，这样每个ThreadLocal就可以作为key将不同的value存储在不同Thread的Map中，当获取数据的时候，同个ThreadLocal就可以在不同线程的Map中得到不同的数据。
ThreadLocalMap类似于一个改版的HashMap，内部也是使用数组和Hash算法来存储数据，使得存储和读取的速度非常快。
同时使用ThreadLocal需要注意内存泄露问题，当ThreadLocal不再使用的时候，需要通过remove方法把value移除。
二、Message
概述
Message是负责承载消息的类，主要是关注他的内部属性：
// 用户自定义，主要用于辨别Message的类型
public int what;
// 用于存储一些整型数据
public int arg1;
public int arg2;
// 可放入一个可序列化对象
public Object obj;
// Bundle数据
Bundle data;
// Message处理的时间。相对于1970.1.1而言的时间
// 对用户不可见
public long when;
// 处理这个Message的Handler
// 对用户不可见
Handler target;
// 当我们使用Handler的post方法时候就是把runnable对象封装成Message
// 对用户不可见
Runnable callback;
// MessageQueue是一个链表，next表示下一个
// 对用户不可见
Message next;
循环利用Message
当我们获取Message的时候，官方建议是通过Message.obtain()方法来获取，当使用完之后使用recycle()方法来回收循环利用。而不是直接new一个新的对象：
public static Message obtain()
synchronized (sPoolSync)
if (sPool != null)
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize--;
return m;
return new Message();
Message维护了一个静态链表，链表头是sPool,Message有一个next属性，Message本身就是链表结构。sPoolSync是一个object对象，仅作为解决并发访问安全设计。当我们调用obtain来获取一个新的Message的时候，首先会检查链表中是否有空闲的Message，如果没有则新建一个返回。
当我们使用完成之后，可以调用Message的recycle方法进行回收：
public void recycle()
if (isInUse())
if (gCheckRecycle)
throw new IllegalStateException("This message cannot be recycled because it "
+ "is still in use.");
return;
recycleUnchecked();
如果这个Message正在使用则会抛出异常，否则则调用recycleUnchecked进行回收：
void recycleUnchecked()
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync)
if (sPoolSize < MAX_POOL_SIZE)
next = sPool;
sPool = this;
sPoolSize++;
这个方法的逻辑也非常简单，把Message中的内容清空，然后判断链表是否达到最大值（50），然后插入链表中。
Message总结
Message的作用就是承载消息，他的内部有很多的属性用于给用户赋值。同时Message本身也是一个链表结构，无论是在MessageQueue还是在Message内部的回收机制，都是使用这个结构来形成链表。同时官方建议不要直接初始化Message，而是通过Message.obtain()方法来获取一个Message循环利用。一般来说我们不需要去调用recycle进行回收，在Looper中会自动把Message进行回收，后面会讲到。
三、MessageQueue
概述
每个线程都有且只有一个MessageQueue，他是一个用于承载消息的队列，内部使用链表作为数据结构，所以待处理的消息都会在这里排队。前面讲到ThreadLocalMap是一个“修改版的HashMap”，而MessageQueue就是一个“修改版的LinkQueue”。他也有两个关键的方法：入队（enqueueMessage）和出队（next）。这也是MessageQueue的重点所在。
Message还涉及到一个关键概念：线程休眠。当MessageQueue中没有消息或者都在等待中，则会将线程休眠，让出cpu资源，提高cpu的利用效率。进入休眠后，如果需要继续执行代码则需要将线程唤醒。当方法暂时无法直接返回需要等待的时候，则可以将线程阻塞，即休眠，等待被唤醒继续执行逻辑。这部分内容也会在后面详细讲。
关键方法
出队 – next()
next方法主要是做消息出队工作。
Message next()
// 如果looper已经退出了，这里就返回null
final long ptr = mPtr;
if (ptr == 0)
return null;
...
// 阻塞时间
int nextPollTimeoutMillis = 0;
for (;;)
if (nextPollTimeoutMillis != 0)
Binder.flushPendingCommands();
// 阻塞对应时间
nativePollOnce(ptr, nextPollTimeoutMillis);
// 对MessageQueue进行加锁，保证线程安全
synchronized (this)
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
...
if (msg != null)
if (now < msg.when)
// 下一个消息还没开始，等待两者的时间差
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
else
// 获得消息且现在要执行，标记MessageQueue为非阻塞
mBlocked = false;
// 链表操作
if (prevMsg != null)
prevMsg.next = msg.next;
else
mMessages = msg.next;
msg.next = null;
msg.markInUse();
return msg;
else
// 没有消息，进入阻塞状态
nextPollTimeoutMillis = -1;
...
代码很长，其中还涉及了同步屏障和IdleHandler，这两部分内容我放在后面讲，这里先讲主要的出队逻辑。代码中我都加了注释，这里还是再讲一下。next方法目的是获取MessageQueue中的一个Message，如果队列中没有消息的话，就会把方法阻塞住，等待新的消息来唤醒。主要步骤如下：
如果Looper已经退出了，直接返回null
进入死循环，直到获取到Message或者退出
循环中先判断是否需要进行阻塞，阻塞结束后，对MessageQueue进行加锁，获取Message
如果MessageQueue中没有消息，则直接把线程无限阻塞等待唤醒；
如果MessageQueue中有消息，则判断是否需要等待，否则则直接返回对应的message。
可以看到逻辑就是判断当前时间Message中是否需要等待。其中nextPollTimeoutMillis表示阻塞的时间，-1表示无限时间，只有通过唤醒才能打破阻塞。
入队 -- enqueueMessage()
MessageQueue.class
boolean enqueueMessage(Message msg, long when)
// Hanlder不允许为空
if (msg.target == null)
throw new IllegalArgumentException("Message must have a target.");
if (msg.isInUse())
throw new IllegalStateException(msg + " This message is already in use.");
// 对MessageQueue进行加锁
synchronized (this)
// 判断目标thread是否已经死亡
if (mQuitting)
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
// 标记Message正在被执行，以及需要被执行的时间，这里的when是距离1970.1.1的时间
msg.markInUse();
msg.when = when;
// p是MessageQueue的链表头
Message p = mMessages;
boolean needWake;
// 判断是否需要唤醒MessageQueue
// 如果有新的队头，同时MessageQueue处于阻塞状态则需要唤醒队列
if (p == null || when == 0 || when < p.when)
msg.next = p;
mMessages = msg;
needWake = mBlocked;
else
...
// 根据时间找到插入的位置
Message prev;
for (;;)
prev = p;
p = p.next;
if (p == null || when < p.when)
break;
...
msg.next = p;
prev.next = msg;
// 如果需要则唤醒队列
if (needWake)
nativeWake(mPtr);
return true;
这部分的代码好像也很多，但是逻辑也是不复杂，主要就是链表操作以及判断是否需要唤醒MessageQueue，代码中我加了一些注释，下面再总结一下：
首先判断message的目标handler不能为空且不能正在使用中
对MessageQueue进行加锁
判断目标线程是否已经死亡，死亡则直接返回false
初始化Message的执行时间以及标记正在执行中
然后根据Message的执行时间，找到在链表中的插入位置进行插入
同时判断是否需要唤醒MessageQueue。有两种情况需要唤醒：当新插入的Message在链表头时，如果messageQueue是空的或者正在等待下个任务的延迟时间执行，这个时候就需要唤醒MessageQueue。
MessageQueue总结
Message两大重点：阻塞休眠和队列操作。基本都是围绕着两点来展开。而源码中还涉及到了同步屏障以及IdleHandler，这两部分内容我分开到了最后一部分的相关问题中讲。平时用的比较少，但也是比较重要的内容。
四、Looper
概述
Looper可以说是Handler机制中的一个非常重要的核心。Looper相当于线程消息机制的引擎，驱动整个消息机制运行。Looper负责从队列中取出消息，然后交给对应的Handler去处理。如果队列中没有消息，则MessageQueue的next方法会阻塞线程，等待新的消息的到来。每个线程有且只能有一个“引擎”，也就是Looper，如果没有Looper，那么消息机制就运行不起来，而如果有多个Looper，则会违背单线操作的概念，造成并发操作。
每个线程仅有一个Looper，由不同Looper分发的Message运行在不同的线程中。Looper的内部维护一个MessageQueue，当初始化Looper的时候会顺带初始化MessageQueue。
Looper使用ThreadLocal来保证每个线程都有且只有一个相同的副本。
关键方法
prepare ： 初始化Looper
Looper.class
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
public static void prepare()
prepare(true);
// 最终调用到了这个方法
private static void prepare(boolean quitAllowed)
if (sThreadLocal.get() != null)
throw new RuntimeException("Only one Looper may be created per thread");
sThreadLocal.set(new Looper(quitAllowed));
每个线程使用Handler之前，都必须调用Looper.prepare()方法来初始化当前线程的Looper。参数quitAllowed表示该Looper是否可以退出。主线程的Looper是不能退出的，不然程序就直接终止了。我们在主线程使用Handler的时候是不用初始化Looper的，为什么？因为Activiy在启动的时候就已经帮我们初始化主线程Looper了，这点在后面再详细展开。所以在主线程我们可以直接调用Looper.myLooper()获取当前线程的Looper。
prepare方法重点在sThreadLocal.set(new Looper(quitAllowed));，可以看出来这里使用了ThreadLocal来创建当前线程的Looper对象副本。如果当前线程已经有Looper了，则会抛出异常。sThreadLocal是Looper类的静态变量，前面我们介绍过了ThreadLocal了，这里每个线程调用一次prepare方法就可以初始化当前线程的Looper了。
接下来再看到Looper的构造方法：
private Looper(boolean quitAllowed)
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
逻辑很简单，初始化了一个MessageQueue，再把当前的线程的Thread对象赋值给mThread。
myLooper() ： 获取当前线程的Looper对象
获取当前线程的Looper对象。这个方法就是直接调用ThreadLocal的get方法：
public static @Nullable Looper myLooper()
return sThreadLocal.get();
loop() : 循环获取消息
当Looper初始化完成之后，他是不会自己启动的，需要我们自己去启动Looper，调用Looper的loop()方法即可:
public static void loop()
// 获取当前线程的Looper
final Looper me = myLooper();
if (me == null)
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
final MessageQueue queue = me.mQueue;
...
for (;;)
// 获取消息队列中的消息
Message msg = queue.next(); // might block
if (msg == null)
// 返回null说明MessageQueue退出了
return;
...
try
// 调用Message对应的Handler处理消息
msg.target.dispatchMessage(msg);
if (observer != null)
observer.messageDispatched(token, msg);
dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
...
// 回收Message
msg.recycleUnchecked();
loop()方法就是Looper这个“引擎”的核心所在。首先获取当前线程的Looper对象，没有则抛出异常。然后进入一个死循环：不断调用MessageQueue的next方法来获取消息，然后调用message的目标handler的dispatchMessage方法来处理Message。
前面我们了解过了MessageQueue，next方法是可能会进行阻塞的：当MessageQueue为空或者目前没有任何消息需要处理。所以Looper就会一直等待，阻塞在里，线程也就不会结束。当我们退出Looper的时候，next方法会返回null，那么Looper也就会跟着结束了。
同时，因为Looper是运行在不同线程的逻辑，其调用的dispatchMessage方法也是运行在不同的线程，这就达到了切换线程的目的。
quit/quitSafely : 退出Looper
quit是直接将Looper退出，quitSafely是将MessageQueue中的不需要等待的消息处理完成之后再退出，看一下代码：
public void quit()
mQueue.quit(false);
// 最终都是调用到了这个方法
void quit(boolean safe)
// 如果不能退出则抛出异常。这个值在初始化Looper的时候被赋值
if (!mQuitAllowed)
throw new IllegalStateException("Main thread not allowed to quit.");
synchronized (this)
// 退出一次之后就无法再次运行了
if (mQuitting)
return;
mQuitting = true;
// 执行不同的方法
if (safe)
removeAllFutureMessagesLocked();
else
removeAllMessagesLocked();
// 唤醒MessageQueue
nativeWake(mPtr);
我们可以发现最后都调用了quitSafely方法。这个方法先判断是否能退出，然后再执行退出逻辑。如果mQuitting==true，那么这里会直接方法，我们会发现mQuitting这个变量只有在这里被执行了赋值，所以一旦looper退出，则无法再次运行了。之后执行不同的退出逻辑，我们分别看一下：
private void removeAllMessagesLocked()
Message p = mMessages;
while (p != null)
Message n = p.next;
p.recycleUnchecked();
p = n;
mMessages = null;
这个方法很简单，直接把当前所有的Message全部移除。再看一下另一个方法：
private void removeAllFutureMessagesLocked()
final long now = SystemClock.uptimeMillis();
Message p = mMessages;
if (p != null)
// 如果都在等待，则全部移除，直接退出
if (p.when > now)
removeAllMessagesLocked();
else
Message n;
// 把需要等待的Message全部移除
for (;;)
n = p.next;
if (n == null)
return;
if (n.when > now)
break;
p = n;
p.next = null;
do
p = n;
n = p.next;
p.recycleUnchecked();
while (n != null);
这个方法逻辑也不复杂，就是把需要等待的Message全部移除，当前需要执行的Message则保留。最终在MessageQueue的next方法中，会进行判断后返回null，表示退出，Looper收到这个返回值之后也跟着退出了。
Looper总结
Looper作为Handler消息机制的“动力引擎”，不断从MessageQueue中获取消息，然后交给Handler去处理。Looper的使用前需要先初始化当前线程的Looper对象，再调用loop方法来启动它。
同时Handler也是实现切换的核心，因为不同的Looper运行在不同的线程，他所调用的dispatchMessage方法则运行在不同的线程，所以Message的处理就被切换到Looper所在的线程了。当looper不再使用时，可调用不同的退出方法来退出他，注意Looper一旦退出，线程则会直接结束。
五、Handler
概述
我们整个消息机制称为Handler机制就可以知道Handler我们的使用频率之高，一般情况下我们的使用也是围绕着Handler来展开。Handler是作为整个消息机制的消息发起者与处理者，消息在不同的线程通过Handler发送到目标线程的MessageQueue中，然后目标线程的Looper再调用Handler的dispatchMessage方法来处理消息。
创建Handler
一般情况下我们使用Handler有两种方式： 继承Handler并重写handleMessage方法，直接创建Handler对象并传入callBack，这在前面使用Handler部分讲过就不再赘述。
需要注意的一点是：创建Handler必须显示指明Looper参数，而不能直接使用无参构造函数，如：
Handler handler = new Handler(); //1
Handler handler = new Handler(Looper.myLooper())//2
1是错的，2是对的。避免在Handler创建过程中Looper已经退出的情况。
发送消息
Handler发送消息有两种系列方法 ： postxx 和 sendxx。如下：
public final boolean post(@NonNull Runnable r);
public final boolean postDelayed(@NonNull Runnable r, long delayMillis);
public final boolean postAtTime(@NonNull Runnable r, long uptimeMillis);
public final boolean postAtFrontOfQueue(@NonNull Runnable r);
public final boolean sendMessage(@NonNull Message msg);
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis);
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis);
public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg)
这里我只列出了比较常用的两类方法。除了插在队列头的两个方法，其他方法最终都调用到了sendMessageAtTime。我们从post方法跟源码分析一下：
public final boolean post(@NonNull Runnable r)
return sendMessageDelayed(getPostMessage(r), 0);
post方法把runnable对象封装成一个Message，再调用sendMessageDelayed方法，我们看看他是如何封装的：
private static Message getPostMessage(Runnable r)
Message m = Message.obtain();
m.callback = r;
return m;
可以看到逻辑很简单，把runnable对象直接赋值给callBack属性。接下来回去继续看
sendMessageDelayed：
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis)
if (delayMillis < 0)
delayMillis = 0;
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis)
MessageQueue queue = mQueue;
if (queue == null)
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
return enqueueMessage(queue, msg, uptimeMillis);
sendMessageDelayed把小于0的延迟时间改成0，然后调用sendMessageAtTime。这个方法主要是判断MessageQueue是否已经初始化了，然后再调用enqueueMessage方法进行入队操作：
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis)
// 这里把target设置成自己
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
// 异步handler设置标志位true，后面会讲到同步屏障
if (mAsynchronous)
msg.setAsynchronous(true);
// 最后调用MessageQueue的方法入队
return queue.enqueueMessage(msg, uptimeMillis);
可以看到Handler的入队操作也是很简单，把Message的target设置成本身，这样这个Message最后就是由自己来处理。最后调用MessageQueue的入队方法来入队，这在前面讲过就不再赘述。
其他的发送消息方法都是大同小异，读者感兴趣可以自己去跟踪一下源码。
处理消息
上面讲Looper处理消息的时候，最后就是调用handler的dispatchMessage方法来处理。我们来看一下这个方法：
public void dispatchMessage(@NonNull Message msg)
if (msg.callback != null)
handleCallback(msg);
else
if (mCallback != null)
if (mCallback.handleMessage(msg))
return;
handleMessage(msg);
private static void handleCallback(Message message)
message.callback.run();
他的逻辑也不复杂。首先判断Message是否有callBack，有的话就直接执行callBack的逻辑，这个callBack就是我们调用handler的post系列方法传进去的Runnable对象。否则判断Handler是否有callBack，有的话执行他的方法，如果返回true则结束，如果返回false则直接Handler本身的handleMessage方法。这个过程可以用下面的图表示一下：
dispatchMessage逻辑
内存泄露问题
当我们使用继承Handler方法来使用Handler的时候，要注意使用静态内部类，而不要用非静态内部类。因为非静态内部类会持有外部类的引用，而从上面的分析我们知道Message在被入队之后他的target属性是指向了Handler，如果这个Message是一个延迟的消息，那么这一条引用链的对象就迟迟无法被释放，造成内存泄露。
一般这种泄露现象在于：我们在Activity中发送了一个延迟消息，然后退出了activity，但是由于无法释放，这样activity就无法被回收，造成内存泄露。
Handler总结
Handler作为消息的处理和发送者，是整个消息机制的起点和终点，也是我们接触最多的一个类，因为我们称此消息机制为Handler机制。Handler最重要的就是发送和处理消息，只要熟练掌握这两方面的内容就可以了。同时注意内存泄露问题，不要使用非静态内部类去继承Handler。
六、HandlerThread
概述
有时候我们需要开辟一个线程来执行一些耗时的任务。一般情况下可以通过新建一个Thread，然后再在他的run方法里初始化该线程的Looper，这样就可以用他的Looper来切线程处理消息了。如下（这里是kotlin代码，和java差不多相信可以看得懂的）：
val thread = object : Thread()
lateinit var mHandler: Handler
override fun run()
super.run()
Looper.prepare()
mHandler = Handler(Looper.myLooper()!!)
Looper.loop()
thread.start()
Thread()
Thread.sleep(10000)
thread.mHandler.sendMessage(Message.obtain())
.start()
执行一下，诶，没有报错了果然可以。但是！！！ ，这样的代码显得特别的难堪和臃肿，还要再开启一个线程来延迟处理。那有没有更好的解决方案？有，HandlerThread。
HandlerThread本身是一个Thread，他继承自Thread，他的代码并不复杂，看一下（代码还是有点多，可以选择看或者不看，我下面会讲重点方法）：
public class HandlerThread extends Thread
// 依次是：线程优先级、线程id、线程looper、以及内部handler
int mPriority;
int mTid = -1;
Looper mLooper;
private @Nullable Handler mHandler;
// 两个构造器。name是线程名字，priority是线程优先级
public HandlerThread(String name)
super(name);
mPriority = Process.THREAD_PRIORITY_DEFAULT;
public HandlerThread(String name, int priority)
super(name);
mPriority = priority;
// 在Looper开始运行前的方法
protected void onLooperPrepared()
// 初始化Looper
@Override
public void run()
mTid = Process.myTid();
Looper.prepare();
synchronized (this)
mLooper = Looper.myLooper();
// 通知初始化完成
notifyAll();
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
// 获取当前线程的Looper
public Looper getLooper()
if (!isAlive())
return null;
// 如果尚未初始化则会一直阻塞知道初始化完成
synchronized (this)
while (isAlive() && mLooper == null)
try
// 利用Object对象的wait方法
wait();
catch (InterruptedException e)
return mLooper;
// 获取handler，该方法被标记为hide，用户无法获取
@NonNull
public Handler getThreadHandler()
if (mHandler == null)
mHandler = new Handler(getLooper());
return mHandler;
// 两种不同类型的退出，前面讲过不再赘述
public boolean quit()
Looper looper = getLooper();
if (looper != null)
looper.quit();
return true;
return false;
public boolean quitSafely()
Looper looper = getLooper();
if (looper != null)
looper.quitSafely();
return true;
return false;
// 获取线程id
public int getThreadId()
return mTid;
整个类的代码不是很多，重点在run()和getLooper()方法。首先看到getLooper方法：
public Looper getLooper()
if (!isAlive())
return null;
// 如果尚未初始化则会一直阻塞知道初始化完成
synchronized (this)
while (isAlive() && mLooper == null)
try
// 利用Object对象的wait方法
wait();
catch (InterruptedException e)
return mLooper;
和我们前面自己写的不同，他有一个wait()，这个是Java中Object类提供的一个方法，类似于我们前面讲的MessageQueue阻塞。等到Looper初始化完成之后就会唤醒他，就可以顺利返回了，不会造成Looper尚未初始化完成的情况。然后再看到run方法：
// 初始化Looper
@Override
public void run()
mTid = Process.myTid();
Looper.prepare();
synchronized (this)
mLooper = Looper.myLooper();
// 通知初始化完成
notifyAll();
Process.setThreadPriority(mPriority);
onLooperPrepared();
Looper.loop();
mTid = -1;
常规的Looper初始化，完成之后调用了notifyAll()方法进行唤醒，对应了上面的getLooper方法。
HandlerThread的使用
HandlerThread的使用范围很有限，开个子线程不断接受消息处理耗时任务。所以他的使用方法也是比较固定：
HandlerThread ht = new HandlerThread("handler");
Handler handler = new Hander(ht.getLooper());
handler.sendMessage(msg);
获取到他的Looper，外部自定义Handler来使用即可。
七、总结
Handler，MessageQueue，Looper三者共同构成了android消息机制，各司其职。其中Handler主要负责发送和处理消息，MessageQueue主要负责消息的排序以及在没有需要处理的消息的时候阻塞代码，Looper负责从MessageQueue中取出消息给Handler处理，同时达到切换线程的目的。
以上是关于Handler消息机制关键类详解的主要内容，如果未能解决你的问题，请参考以下文章
深入源码分析Handler 消息机制 LooperMessageQueue 消息同步屏障IdleHandlerMessage 复用