当我们在主线程里面新建一个Handler的时候，是这么写的
新建一个Handler
看看源码
Handler的构造方法
看看Looper.myLooper方法
Looper.myLooper
既然有sThreadLocal.get方法，那么先看看sThreadLocal.set方法在哪
Looper的prepare方法
那么在Looper这个类中，只有Looper.prepare方法有设置sThreadLocal的值。
那么反过来推，假设在new Handler的时候抛出一个异常，Can't create handler inside thread that has not called Looper.prepare，根据Handler构造方法里面来看，肯定是mLooper为null，那么mLooper又是等于Looper.myLooper的。那Looper.myLooper是sThread.get而来，既然Looper.myLooper为null，那么说明sThread.set根本就没执行，好吧，这就说明Looper.prepare方法没执行。
那么真实情况是什么？我们只是new了一个Handler，程序正常运行，没有抛出异常啊，那么sThreadLocal.set肯定是执行过的，要不然Looper.myLooper也不会有值。那么这个Looper.prepare在哪里执行的？
在上一篇Android的启动流程里面提到过，在ActivityThread的main方法里
ActivityThread的main方法
好吧，在程序启动的时候，系统已经帮我们调用了Looper.prepareMainLooper方法了，所以啊，我们可以随意new Handler了
那我们的Handler是否可以在子线程里面new并使用呢？答案是可以的
new Thread里面new Handler
如果你是这么写的，那么恭喜你，程序要崩溃了。
不妨可参考一下上面的Handler构造方法，里面先取Looper对象，然后判读是不是null，如果是null，抛异常；如果不是，正常运行。
我们会发现这个时候Looper.myLooper是null的，为什么？因为在主线程中，有系统帮你调用了Looper.prepare方法，但是你新建了一个线程，可没有人帮你调用该方法；那我们加上该方法
加上了prepare和loop方法
程序正常运行。
总结：每一个线程都有且只有一个Looper对象，为什么
如果判断sThreadLocal.get不为null，那么就会抛异常了。message说的很清楚，每个线程只能有一个Looper对象。我们调用Looper.prepare方法的时候，发现sThreadLocal.get为null，很好，不会有异常，最下面的那句，直接new了一个Looper对象，并且用sThreadLocal给set进去了。
Looper的构造方法
那么消息队列MessageQueue在一个线程中有且也是只有一个的。因为new Looper只能执行一次，执行第二次就会判断不为null直接抛异常了。
接着，每个线程有且都只有一个Looper对象和MessageQueue对象，handle可以有多个，但是每个handle实例里面的looper和messageQueue还是同样那个。
在子线程中同样可以新建handler，但是必须手动创建子线程的Looper对象和MessageQueue对象，也就是要调用Looper.prepare方法。在子线程里面新建的Handler，不管在子线程里面发送消息也好还是在主线程里面发送消息也好，在回调dispatchMessage里面的线程还是和新建那个Handler的线程一样。也就是说，在哪个线程new的handler，最终回到哪个线程来处理回调。
示例1
示例1结果
示例1里面handler是在new Thread里面新建的，那么在前面要加上Looper.prepare方法，后面要加上Looper.loop方法，这个子线程是新建Handler的子线程，线程id为2193
紧接着，又新建了个线程，线程id为2194，并且在2194里面用2931线程new的handler发送了一条message，延时两秒。
两秒后，handler的dispatchMessage收到消息，线程id是2193，很显然，是新建这个handler的线程。
另外，MessageQueue虽然口头上称作消息队列，但是它内部实现是典型的单链表结构。为什么？看看message类的构造
Message类构造1
message类构造2
除了我么熟悉的what、arg1、arg2等属性，下半部分有个属性Message next，包含自己同类型的引用，并且取名为next，这是指向下个Message的“指针”
那么看看MessageQueue里面的操作，节选自hasMessage方法
MessageQueue里面的hasMessage方法
我们平常使用比较多的mHandler.hasMessage(int what)实际上就是调用了mQueue.hasMessage(handler, what, obj)来进行比较的，那么想想单链表结构里面，给定一个特定值，怎么找出相应的节点？自然而言就是想到用一个循环遍历这个链表，然后逐个比对。hasMessage这个方法也是这么做的。用了一个while循环，如果不符合的，那么将指针往下一个节点挪动一下，继续比较，直到最后一个节点。其中p = p.next就是这个思想。
那么看看这个链表怎么进行插入？转换成handler来说就是调用sendMessage往MessageQueue中插入数据
MessageQueue的enqueueMessage方法
mMessage可以看作是链表MessageQueue的头指针，那么判断p是不是等于null，就是判断这个MessageQueue是不是空的，如果是空的话，那么此时的msg就是成为第一个节点，
把msg赋值给mMessage，msg的next是p，而p又是null，所以msg的next是null，即msg也是最后一个节点。
如果p不是等于null，那么说明链表MessageQueue不是空的，那么首先判断当前的这个msg的执行时间即when如果是小于第一个节点的执行时间即p.when，那么相当于把msg插入到链表的第一个节点上去。因为msg这个消息要先被处理，所以就有了msg.next = p; prev.next = msg;如果当前的msg的执行时间即when比第一个节点的执行时间p.when要长，那么for循环继续，p再指向第二个节点，prev变成第一个节点。重复如此，知道找到一个when比较下的，结束循环，将msg插入到中间位置。可以说，MessageQueue是一个以时间为准则的有序单链表。那么可能有人问了，如果我每次用handler只调用sendMesage，不调用sendMessageDelayed或者sendMessageAtTime，那MessageQueue又如何控制顺序呢？我们看sendMessage最后调用的方法就知道了
Handler的sendMessageAtTime
无论是调用handler的哪个sendMessage方法，系统最终会调用sendMessageAtTime方法，这个方法第二参数是uptimeMillis，虽然我们调用了sendMessage没有特别指定时间，但是系统会自动给我们每条消息加上时间属性，精确到毫秒。这样，就能保证消息的分发不会乱了顺序。
总结：
每个线程只能有且只有一个Looper和MessageQueue对象
handler除了在主线程，都需要在new Handler之前调用Looper.prepare方法和在new Handler之后调用Looper.loop方法，主线程则不用且不能
handler在哪个线程新建的，那么不管是在哪个线程调用sendMessage方法，最终的dispatchMessage都会在新建handler的线程处理
消息队列MessageQueue是一个有序的以时间排列的单链表
网友评论