一、引言
距离上一次阅读
Handler源码已经半年多过去了，当时读源码的目的更多的是忙于毕业找工作，为面试做准备，现在则是想更多地了解Android相关机制。半年多过去了，回头看当时的源码解读笔记（当时不写博客），发现有很多地方并没有很好地解释清楚，于是想趁着这2018结束之际再次根据自己的想法整理一遍，感兴趣的童鞋可以看看。
所谓Handler机制，实际是线程切换机制。在我们日常开发中用的最多的是通过Handler来更新UI视图，而Handler除了用于线程切换外，Handler、Looper、ThreadLocal、MessageQueue、Message如何融合、构成一个成熟框架的思想更值得我们学习，这也是写本文的目的：比较深入全面地理解Handler机制。
二、预热知识
通常，我们使用Handler是这样的：
private Handler mHandler1;
mHandler1 = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
// 操作 UI
textView.setText(String.valueOf(msg.obj));
return false;
}
});
又如这样手动建立一个消息循环：
Handler mHandler;
Looper mLooper;
private void createHandlerLoop() {
Thread looperThread = new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
mLooper = Looper.myLooper();
mHandler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
// 操作UI时异常
// Looper不执行于UI线程，不能直接操作View控件
// textView.setText(String.valueOf(msg.obj));
Toast.makeText(MainActivity.this, String.valueOf(msg.obj), Toast.LENGTH_SHORT).show();
return true;
}
});
Looper.loop();
}
});
looperThread.start();
}
然后我们给两个Handler发送消息，这里我们从非主线程发送消息：
private ExecutorService mExecutorService = Executors.newCachedThreadPool();
public void sendMessage(View view) {
mExecutorService.submit(new Runnable() {
@Override
public void run() {
if (mHandler != null)
mHandler.obtainMessage(1, "" + Math.random()).sendToTarget();
if (mHandler1 != null)
mHandler1.obtainMessage(1, "`from mHandler1::" + Math.random()).sendToTarget();
}
});
}
我们知道Handler运行于Looper，而Looper运行于创建它的线程中，因此可以说Handler运行于创建它的线程，这里刚好验证一下，我们给mHandler1和mHandler发消息，然后在其中更新UI，此时mHandler1正常更新，而mHandler则报非主线程更新UI的异常，可见 mHandler1的Looper运行于主线程，而mHander则运行于looperThread。
当然，这些只是表象上，我们来看看为啥它运行在创建它的线程。
首先来看看Handler的构造方法
public Handler``(Callback callback, boolean async) {
// ...
mLooper = Looper.myLooper();
// ...
}
这里主要关注到Looper.myLooper()，它是从ThreadLocal中获取到的，而之所以能得到，是因为在执行Looper.prepare()方法时会创建一个Looper实例存入其中，这也就是为什么我们在手动建立消息循环时必须要执行Looper.prepare()的原因了。
//
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
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));
}
注意到上面sThreadLocal被static final所修饰，也就是说它以常量的形式存在于进程中，所以我们应用进程中的所有Looper实例都会独立存储在其中，无论运行在主线程还是其他线程。ThreadLocal#get()源码如下：
public T get() {
// 1. 拿到当前线程
Thread t = Thread.currentThread();
// 2. 取出当前线程的独立数据
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
// 3. 取出运行在当前线程的 Looper 实例
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
可以看出，从ThreadLocal取出Looper实例时会根据当前运行的线程去取，也就是说在Handler执行于的线程决定于Looper所执行于的线程，也就是创建它的，并执行了Looper#prepare()的线程。
好了，接下来将结合源码分析Handler、Looper、ThreadLocal、MessageQueue、Message的具体运作原理。
三、 Looper 源码分析
在Looper对象创建时会创建一个消息队列，并记录当前线程信息
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
而实际上调用Looper.prepare()时才会真正意义上的创建Looper对象，Looper对象会记录在ThreadLocal中，而ThreadLocal在这里是个static final常量，意味着会在运行时以常量形式记录在常量池，从而保证使用到Looper的线程都只对应这唯一的ThreadLocal常量，也就保证不同使用到Looper消息循环的线程中都对应着唯一的Looper，且相互之间是独立的。
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));
}
loop()方法则是个死循环，所以执行之后，会使得创建它的线程就处于阻塞状态，此时会一直处于从MessageQueue中提取Message的状态，直到调用Looper.quit()方法退出消息队列。Looper.quit()执行后使得queue.next()返回Message为null,Looper也随即退出，线程最终执行结束。
在消息循环正常执行过程中，会将每个从消息队列中提取到的消息分发给handler#dispatchMessage(msg)处理，这里的msg.target就是Message记录下来的发送它的那个Handler。
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
// . . .
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) { // 拿到的消息为null了，说明消息队列已经退出了，因而退出消息循环
return;
}
try { // 分发消息给handler处理
msg.target.dispatchMessage(msg);
} finally {
// ...
}
}
}
执行mQueue.quit(false)后消息队列会删除队列内的所有消息，并把根节点Message设置为null（MessageQueue是个单向链表结构，后面会讲到）,所以上面如果queue.next()拿到的消息为null了，就说明消息队列已经退出，因而就会退出Looper#loop()，也就是退出消息循环。
public void quit() {
mQueue.quit(false);
}
void quit(boolean safe) {
// ...
synchronized (this) {
// ...
if (safe) {
removeAllFutureMessagesLocked();
} else {
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr);
}
}
private void removeAllMessagesLocked() {
Message p = mMessages;
while (p != null) {
Message n = p.next;
p.recycleUnchecked();
p = n;
}
mMessages = null;
}
至于Handler.dispatchMessage()，源码如下，可见它首先会看看是否给Message设置了回调，如果有，那执行Message的回调方法，如果没有，则看看自己的回调，如果没有再就执行自己的方法；所以Message自身的回调是优先级最高的，其次是自身回调，最后才是自身的方法。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
以上整个分析流程下来就可以得出如下草图，其中包含了线程切换的概念在内：
Handler机制.png
以上便是Handler机制的核心内容，也可以说是Looper的运行流程，当然这还没完，因为我们在分析过程中依然存在其他疑问，比如以单向链表结构为基础的Messagequque为啥这么设计、ThreadLocal为啥能够独立存储线程数据等。
三、MessageQueue 源码分析
消息队列顾名思义是用来存放Message的队列，但实际上它不是使用队列，而是以Message为节点的单链表结构；它提供enqueueMessage(Message msg, long when)方法用来插入消息，next()来提取消息，它是一个阻塞方法，只有当Looper.quit调用后它才会退出。
这里重点分析一下它的next()方法，它采用了线程安全设计，并且它也是阻塞式的，我们先来看看源码：
Message next() {
// ...
for (;;) {
// ...
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 1. 遍历单向链表，也就是消息队列，查找尾部节点
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
// 2. 根据消息的执行时间判定是否要返回、处理这条消息
if (now < msg.when) {
// 还没轮到它
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else { // 时间到，就是它了
mBlocked = false;
if (prevMsg != null) { // 删除队尾节点
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
// 3. 这条消息可以处理了，则标记为正在使用并返回
msg.next = null;
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// 检查消息循环是否退出
if (mQuitting) {
dispose();
return null;
}
// 其他情况，则继续循环等待
}
// ...
}
}
由于是基于单向链表的设计，因而每次如果想要得到队尾节点都需要遍历整个队列，直到定位到队尾。一旦定位到了队尾，且它不为null，那么就会根据消息的执行时间判定是否要返回、处理这条消息，如果还没到点，那么继续循环（也可看成是在等待，如果是异步isAsynchronous的,那么就直接使用这个消息，而不需要定位到队尾），直到达到了执行时间，而达到执行时间后，说明这条消息可以处理了，则标记为已用，并返回给Looper进行分发。
MessageQueue#next.png
至此，是不是有些明白为什么不用查找效率更高的数组或查找树来设计了呢？首先是额外内存损耗的问题，单向链表的空间复杂度肯定比模板库中的队列（需要额外建立Entry）要低；然后是这里的执行时间等待问题，实际这里并不需要查找时间复杂度上的最优，因为反正都可能需要等待执行时间，那么遍历就完事了，多耗点时间也无所谓。
再来看看插入消息，与取消息类似，线程安全设计，具体看看注释就行。
boolean enqueueMessage(Message msg, long when) {
// . . .
synchronized (this) {
if (mQuitting) { // quit()方法调用后，消息循环已经退出
msg.recycle();
return false;
}
// 标记为正在使用
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// 如果没到执行时间，则直接插在队头
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else { // 其他则插入到队尾，比如已经到了执行时间了，那么直接插入到队头，这样就能在下次取消息时执行了
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
// 插入消息到队尾
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// ...
}
return true;
}
四、ThreadLocal 源码分析
特点： 当多个线程使用同一个ThreadLocal时，它可以独立地记录各个线程的数据。
ThreadLocal#set(...)源码如下，可见每当执行ThreadLocal#set(...)保存线程数据时，会先查看当前线程是否已经绑定了ThreadLocalMap数据集合，如果不存在则创建一个绑定在这个线程。
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
再来看看ThreadLocalMap的主要构成，看到这样的构成是不是可以联想到HashTable和HashMap呢？当然，不过不同之处在于，它并没有像HashTable那样采用数组+单向链表的设计，也没有像HashMap那样采用数组+单向链表+红黑树的设计，而仅仅是一个数组，不过原理都是类似的。
也就是说，实际上ThreadLocal本身并不存储数据，而ThreadLocal之所以能够实现单独记录每个使用到它的线程的数据，是因为它为每一个线程都建立了一个独立的ThreadLocalMap数据存储对象，并把这个数据存储对象绑定在对应的线程上，当我们需要设置或者获取某一个线程的数据时，那么只需要从这个线程中取出这个数据存储对象，然后写/读数据即可，你看这是不是既简便又能保证数据的独立性。
static class ThreadLocalMap {
// 真正线程存储数据的地方
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
private Entry[] table;
private int size = 0;
private int threshold; // Default to 0
// ...
}
ThreadLocal#get()源码如下:
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t); //1. 取出当前线程所绑定的的ThreadLocalMap
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this); //2. 取出 ThreadLocalMap.Entry
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value; //3. 取出值
return result;
}
}
return setInitialValue();
}
五、设计思想
至此，我们已经结合源码分析了Handler机制中所有核心，可能有的童鞋会有所怀疑，Handler机制的核心居然不是Handler？哈哈，确实不是，Handler只是作为整个框架的入口而已，要说核心，那非Looper莫属了。
纵观整个机制的执行过程及协作关系，不难发现它实际是基于生产者-消费者模型的设计：
生产者-消费者.png
为了方便对比，我把前面的Handler机制那张图粘过来这里：
Handler机制.png
然后对号入座一下，不难发现，这里的生产者指的是Thread 2，任务队列就是我们的MessageQueue，而消费者就是Looper也就是Thread 1，然后你会发现，Handler还真的只是个入口。
总结
本文从Handler的基本使用着手，结合源码分析了Handler机制中的几个核心类，并总结和下它的设计思想，水平有限，欢迎指正。
网友评论