1. 概述
Handler 即为Android异步消息处理机制,
问题
1，当我们把一个msg通过Handler发送，这个msg最终去了哪里，handleMessage又是怎么接受到消息的回调。
2，MessageQueue作为消息队列，是如何做到及时的存取消息，且能保障保证线程的不堵塞的？
3，Looper是如何保证了自己的唯一性，以及为什么要确保自己的唯一性呢？
2、 源码解析
1.Handler
对于Handler而言，我们使用Handler来发送消息，会使用两个方法，一个send系列，一个post系列，但无论我们怎么调用，handler内部最终都会跳转到enqueueMessage来完成，如图所示，所以对于Handler的发送消息来说，也就变成了：
enqueueMessage这个函数做了什么，又是谁来调用的?
要弄清上面这两个问题，我们可以看看 enqueueMessage这个函数内部实现。
从第740行和745行可以看出，最终handler将msg交给我了我们MessageQueue处理，因此也就引出了我们的消息队列MessageQueue
2. MessageQueue
MessageQueue是一个消息队列，里面有两个很重要的方法，enqueueMessage()和next(),一个存一个取。通过对handler的分析可以看出，handler负责将消息放入队列，那么谁在帮我们从队列中取出这个消息呢？ 在回答这个问题之前，我们先来看看上面的第二个问题：MessageQueue作为消息队列，是如何做到及时的存取消息，且能保障保证线程的不堵塞的？查看源码，我们来看看这两个方法的具体实现
首先我们来看看enqueueMessage()方法，
第9行，synchronized关键字来保证我们存取消息时候的线程安全，
第22行，判断Messages中是否还有消息，判断when(加入的msg的执行时间)当前传入的时间是否立即执行，判断当前传入的消息执行时间，是否小于Messages中第一个要执行消息的时间，
如果三个条件任意满足一个，就将msg赋值给 mMessages中第一个位置。然后将mBlocked赋值给needWake(后面会讲到什么时候mBlocked为true)
第33行，如果不满足，取队列中下一条消息，继续判断，直到满足跳出循环，然后将msg插入队列，等待执行。
第48行，如果needWake为true，唤醒线程执行消息
整个enqueueMessage就是这么一点逻辑，也就是去和当前消息队列中最快最先执行的消息对比，如果满足条件将传入的消息插在这个队列最前面，不满足以此类推判断与第二个，第三个消息直接的执行顺序。然后形成一个以时间排序的消息队列，时间一到，就会从这个队列中取出消息来执行。
然后我们来看一下，MessageQueue是如何取消息的。
第二行，pendingIdleHandlerCount = -1，用处下面会介绍到
第三行，nextPollTimeoutMillis = 0，线程block时间。
第五行，nativePollOnce()方法，这个方法传入nextPollTimeoutMillis，表明当前线程block，默认为0
第6行，synchronized关键字与上面存消息一样，保证了线程的安全
第16行，判断当前队列是否还有消息，如果没有nextPollTimeoutMillis赋值 -1，表示线程要一直block，然后我们顺着源码往下看第47行，系统又将nextPollTimeoutMillis赋值为0，显然这和我们的逻辑冲突，也就是说无论怎么样，即使当前消息队列中没有消息，线程也不会block，将永远占用资源嘛？其实并不是这样的，我们来看看第37行，这个判断保证了，nextPollTimeoutMillis赋值为0不会执行，且和我们上面mBlocked的赋值相对应，mBlocked = true，用enqueueMessage方法的第26 48行来唤醒线程。
第17行，队列中有消息，判断当前时间和消息执行时间，如果还没有到执行时间，通过算法将nextPollTimeoutMillis赋值，线程block nextPollTimeoutMillis这么长时间
第28行，都不满足以上条件，返回消息。(问题来了，这个消息返回到了哪里呢。于是我们的Looper闪亮登场)
3. Looper
前面说过了，MessageQuene是个消息队列负责存入消息和取出消息，那么这个消息是在什么时候取出来的呢，我们来看一下looper的loop()方法，在这个方法里面有个无限for循环：
第三行，queue.next就是我们取消息的地方，取出一条消息，如果没有消息则阻塞。
第36行，调用 msg.target.dispatchMessage(msg);把消息交给msg的target的dispatchMessage方法去处理。细心的朋友可能发现这个msg.targe就是我们在enqueueMessage方法第一句话赋的值，其实也就是我们的handler
第741行，把handle对象赋值给msg.targer. 这样在dispatchMessage中就可以完成我们的handler的回调 handleMessage。也就完成了我们的一次消息处理。最后我们来说一说，为什么looper能确保唯一性。 我们直接来看looper.prepare方法，（prepare在什么地方调用，我们可以查看AMS的源码，本文不做过多说明）
第5行，sThreadLocal通过源码可以发现，sThreadLocal是一个静态 final的成员变量，也就是说确保了sThreadLocal的唯一性。那么只需要sThreadLocal确保looper的唯一性即刻，关于ThreadLocal的源码，我们可以大概看一下：
其实ThreadLocal并不是以<key,value>的形式管理数据，其内部管理着一个Entry数组，通过上面的set方法我们可以看到通过把自身当作key，然后通过一个hash运算得到一个具体数值i，将tab[i]作为这个数据的key，tab[i+1]存储value，其实也就是我们的looper，所以我们只要保证ThreadLocal是唯一的那么我们的Looper也就唯一确定了，当我们调用prepare方法的时候，在第二行，sThreadLocal.get()如果不为空，说明我们的ThreadLocal已经存在，便不需要再重新创建。
