Android消息机制是比较重要的一块，必须要掌握，消息机制主要是指Handler的运行机制，Handler的运行需要MessageQueue和Looper的支撑，MessageQueue表示消息队列，内部存储了一组消息，采用单链表的数据结构来实现，不过MessageQueue也只是一个存储单元，它并不具备处理消息的功能，Looper就是来干这事的，它会无限循环是否有新消息，有就处理，没有就等着。
Handler创建的时候会默认采用当前线程的Looper来构造消息循环系统，但线程默认是没有Looper的，如果要使用消息机制，必要要为线程创建Looper，但UI线程比较特殊，它会创建默认的Looper对象，所以Android中主线程是可以直接使用handler。
1.Looper和MessageQueue那些事
第一次使用Handler好紧张，听说在Android中更新UI必须要在主线程，我这暴脾气就不在，于是我在onCreate中写下了如下代码：
new Thread(new Runnable() {
@Override
public void run() {
Toast.makeText(MainActivity.this, "我是一个toast消息", Toast.LENGTH_SHORT).show();
}
}).start();
嗯，这段代码对于我来说就是小菜一碟，于是我一个后空翻，然后点击了运行按钮，尴尬的一腿，果然崩溃了：
这个错误我想大多数Androider都见过吧，看着真是亲啊，都不想清除它，但是问题还是要解决的，那么如何解决呢？崩溃日志里说的很清楚，要我们调用下Looper.prepare()，那我就不客气了！于是有了如下的代码：
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
Toast.makeText(MainActivity.this, "我是一个toast消息", Toast.LENGTH_SHORT).show();
}
}).start();
话不多说，运行一波，果然app成功启动，但是我的Toast消息并没有弹出啊，妈个鸡，看来问题并不是这么简单，于是我灵机一动，记得好像Looper.prepare()要和Looper.loop()方法一起使用，于是乎：
new Thread(new Runnable() {
@Override
public void run() {
Looper.prepare();
Toast.makeText(MainActivity.this, "我是一个toast消息", Toast.LENGTH_SHORT).show();
Looper.loop();
}
}).start();
你终于弹出来了，不容易啊：
这俩东西这么神奇，加上Looper.prepare()不崩溃了，加上Looper.loop()之后我的toast就弹出来了，来看看它们的真面目，先看看Looper.prepare()：
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));
}
从sThreadLocal.get()里的异常信息可以看出，sThreadLocal.get()是获取当前线程Looper的，如果已经存在，则抛出异常：每个线程仅可以创建一个Looper，如果sThreadLocal.get() == null，那就sThreadLocal.set(new Looper(quitAllowed))创建一个.
ThreadLocal类允许我们创建只能被同一个线程读写的变量。因此，如果一段代码含有一个ThreadLocal变量的引用，即使两个线程同时执行这段代码，它们也无法访问到对方的ThreadLocal变量，有点抽象，具体后面会介绍。
下面我们来看看Looper的构造方法：
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
也很简单，但是却很关键，在创建Looper的时候，默认创建了一个MessageQueue，MessageQueue消息队列就是存放消息的地方，此时Looper就有了一个消息仓库MessageQueue，存储消息的地方也就有了。
那什么时候往仓库里放东西呢？具体是怎么放的呢，咱们下面再说，先来看下Looper.loop()干了些啥：
public static void loop() {
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();
if (msg == null) {
return;
}
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
msg.recycleUnchecked();
}
}
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
首先通过myLooper()方法获取当前线程的looper对象，如果为null，则抛出异常：赶紧去调用Looper.prepare()去创建looper去，然后for(;;)，简单粗暴，开启一个死循环，然后通过queue.next()从队列中取出一条消息，如果此时消息队列中有Message，那么next方法会立即返回该Message，如果此时消息队列中没有Message，那么next方法就会阻塞式地等待获取Message。
取出了message之后呢，当然是找人处理掉它，于是执行msg.target.dispatchMessage(msg)开始分发消息，msg.target其实就是Handler实例，它是在消息入队列的时候被赋值的，下面会说到，看看dispatchMessage的代码：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
嗯，代码还挺简单，msg.callback != null就去执行handleCallback(msg)，msg.callback其实是Runnable callback类型，也就是我们平时调用Handler.post(Runnable r)里的r参数，handleCallback代码如下：
private static void handleCallback(Message message) {
message.callback.run();
}
直接去调用Runnable的run方法去了，else分支判断了下mCallback != null，mCallback哪来的呢，其实是我们创建Handler的时候可以选择传入的参数：
public Handler() {
this(null, false);
}
public Handler(Callback callback) {
this(callback, false);
}
public Handler(Looper looper) {
this(looper, null, false);
}
public Handler(Looper looper, Callback callback) {
this(looper, callback, false);
}
看到了吧，就是几个构造函数里的callback，接着如果mCallback != null就会调用mCallback.handleMessage(msg)，去处理消息，如果以上两个callback都没有设置的话，那就调用默认的handleMessage(msg)去处理消息，嗯，没错，还是它。
这个时候我们脑子里是不是已经很清晰了，当我们调用sendMessage发送消息的时候，消息就会被存入消息队列MessageQueue，在合适的时候就会被Looper取出来，通过dispatchMessage方法去调用handleMessage(msg)去处理该消息。
2.消息如何被存入消息队列MessageQueue中的？
说了半天，还不知道这个，莫慌，我们来追踪一下，就从Handler的sendMessage方法开始：
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(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);
}
经过层层调用，最终发现了enqueueMessage方法，没错，就是它了，它就是最终负责把消息放入MessageQueue中的，让我们来一睹它的尊荣：
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//注意这里注意这里：上面我们说了msg.target就是当前的Handler实例，看到了吧，在这里赋值的。
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
boolean enqueueMessage(Message msg, long when) {
//handler都没有你发个鬼的消息
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
//我是一次性的，被用过了（QAQ）
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
//终于轮到我了，我的身份标识为被使用
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
//p为null表示MessageQueue里还没有消息，或者msg的触发时间是队列中最早的， 则进入该分支。
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;
//把msg加入到链表中，按时间顺序从小到大排序
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p;
prev.next = msg;
}
//判断是否需要唤醒，如果需要唤醒则调用nativeWake(mPtr)来唤醒之前等待的线程。
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
mMessages其实代表消息队列的头部，如果mMessages为空，说明还没有消息，如果当前插入的消息不需要延时，或者说延时比mMessages头消息的延时要小，那么当前要插入的消息就需要放在头部，我们发送的message消息经过enqueueMessage过程后就被加入到了消息队列MessageQueue中。
3.Looper中next()方法分析
Looper通过loop()方法中的死循环不断的点用queue.next()获取MessageQueue中的消息，如果当前消息队列中没有消息，Loop线程就会阻塞，当其他线程插入消息时，就会唤醒当前线程，queue.next()源码如下：
Message next() {
int pendingIdleHandlerCount = -1;
int nextPollTimeoutMillis = 0;
for (;;) {
//是否需要阻塞等待，第一次一定不阻塞，当等待nextPollTimeoutMillis时长，或者消息队列被唤醒，都会返回
//nextPollTimeoutMillis =0 ：无需睡眠，直接返回
//nextPollTimeoutMillis >0 ：睡眠如果超过timeoutMillis，就返回
//nextPollTimeoutMillis =-1：一直睡眠，直到其他线程唤醒它
nativePollOnce(ptr, nextPollTimeoutMillis);
//同步
synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
//是否存在barrier，android中定义了一个Barrier的概念，当View在绘制和布局时会向Looper中添加了Barrier(监控器)，这样后续的消息队列中的同步的消息将不会被执行，以免会影响到UI绘制，此时只有异步消息才能被执行。
if (msg != null && msg.target == null) {
//do while循环遍历消息链表，跳出循环时，msg指向离表头最近的一个异步消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
//看取到的消息是不是需要立即执行，需要立即执行的就返回当前消息，如果需要等待，计算出等待时间
if (now < msg.when) {
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages，一直睡眠，直到其他线程唤醒它
nextPollTimeoutMillis = -1;
}
//没有可以即刻执行的Message，查看是否存在需要处理的IdleHandler，如果不存在，则返回，阻塞等待，如果存在则执行IdleHandler
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// 处理IdleHandler
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
//重置idle handler个数为0，以保证不会再次重复运行
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
next函数中，nextPollTimeoutMillis初始值=0 ，所以for循环第一次是一定不会阻塞的，如果能找到一个Delay倒计时结束的消息，就返回该消息，否则，执行第二次循环，睡眠等待，直到头部第一个消息Delay时间结束，所以next函数一定会返回一个Message对象。
接着会去查看是否存在barrier，存在就取出此异步消息，否则继续处理同步消息，然后会判断取到的消息是不是需要立即执行，需要立即执行的就返回当前消息，如果需要等待，计算出等待时间。最后，如果需要等待，还要查看，IdleHandler列表是否为空，不为空的话，需要处理IdleHandler列表，最后重新计算一遍。
nativePollOnce是阻塞操作，其中nextPollTimeoutMillis代表下一个消息到来前，还需要等待的时长；当nextPollTimeoutMillis = -1时，表示消息队列中无消息，会一直等待下去，当处于空闲时，往往会执行IdleHandler中的方法，当nativePollOnce()返回后，next()从mMessages中提取一个消息。
1.nativePollOnce更详细的解释点此处查看！
2.barrier相关知识点击此处查看！
3. IdleHandler相关知识点击此处查看！
4.ThreadLocal详解
ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据，对于其它线程来说无法获取到数据，下面来看一个例子：
private ThreadLocal<Boolean> mBooleanThreadLocal = new ThreadLocal<>();
mBooleanThreadLocal.set(true);
Log.e("handler","main----value = "+mBooleanThreadLocal.get());
new Thread("Thread1"){
@Override
public void run() {
mBooleanThreadLocal.set(false);
Log.e("handler","Thread1----value = "+mBooleanThreadLocal.get());
}
}.start();
new Thread("Thread2"){
@Override
public void run() {
Log.e("handler","Thread2----value = "+mBooleanThreadLocal.get());
}
}.start();
代码很简单，我们定义了一个ThreadLocal对象，在onCreate里设置为true，然后启动了两个子线程，一个设置false直接打印其值，一个不设置直接打印，看看运行结果：
我的天，这么神奇，主线程里为true没毛病，Thread1中为false看起来也像那么回事，Thread2中为null就有点过分了吧，但其实这正是ThreadLocal的神奇之处，我们来看看它为何可以这么吊，其实ThrealLocal 是一个泛型类，它的定义为 public class ThrealLocal，弄清楚 ThrealLocal 的 set() 和 get() 方法就可以明白它的工作原理了。
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
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;
}
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
Threadlocal的set方法以当前线程this为key，存储在一个ThreadLocalMap中，ThreadLocalMap内部存储其实使用的是一个Entry数组，数组的每一个值都是一个弱引用的ThreadLocal，里面保存着具体的value值，通过get方法，以当前线程为key，取出相应的value，各个线程之间互不影响。
5.如何正确使用Handler
我们知道，在Java中内部类的定义与使用一般为成员内部类与匿名内部类，他们的对象都会隐式持有外部类对象的引用，影响外部类对象的回收。所以我们平时这样的代码：
private Handler meHandler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
AS都看不下去了，会给我们一个警告：
当我们发送一个延时消息，此时如果在消息还没执行的时候就退出了Activity，此时就会内存泄露，下面给出一种解决方式：
private static class MyHandler extends Handler {
private WeakReference<MainActivity> weakReference;
MyHandler(MainActivity activity) {
weakReference = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
MainActivity activity = weakReference.get();
if (null != activity) {
//dosomething
}
}
}
private MyHandler handler = new MyHandler(this);
6.子线程真的不能更新UI吗？
先看个例子，我在onCrete中执行如下代码：
tvShow = findViewById(R.id.tv_show);
new Thread(new Runnable() {
@Override
public void run() {
tvShow.setText("我胖虎在子线程中···");
}
}).start();
运行结果：
这不是见鬼了吧，在子线程中竟然更新UI成功了！！！不要慌，基本操作，大家都坐下！我们来稍微该下代码：
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
tvShow.setText("我胖虎在子线程中···");
}
}).start();
运行结果如下：
嗯，这个才是我们想要的样子嘛，那么为啥呢，为啥呢，一路追踪源码：setText-->checkForRelayout-->requestLayout-->mParent.requestLayout()，此处的mParent是ViewParent类型，它是一个接口public interface ViewParent，它的实现类是ViewRootImpl，所以看下ViewRootImpl的requestLayout()方法：
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
终于找到你了，这个异常就是判断当前线程是否是主线程，此时如果不是主线程就会抛出这个异常，那么看来看去ViewRootImpl很关键，那么ViewRootImpl是在什么时候创建的呢？
你如果对Activity的启动流程有所了解，那么ActivityThread中的handleResumeActivity方法你一定不会陌生：
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
r = performResumeActivity(token, clearHide, reason);
r.activity.mVisibleFromServer = true;
mNumVisibleActivities++;
if (r.activity.mVisibleFromClient) {
r.activity.makeVisible();
}
ActivityManager.getService().finishActivity(token, Activity.RESULT_CANCELED, null,Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
}
r.activity.makeVisible()这里调用了Activity的makeVisible()：
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm = getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded = true;
}
mDecor.setVisibility(View.VISIBLE);
}
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mContext.getDisplay(), mParentWindow);
}
接着调用了WindowManagerImpl的addView方法，然后最终调用了WindowManagerGlobal的addView方法：
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
ViewRootImpl root;
synchronized (mLock) {
······
//ViewRootImpl最终是在这里初始化的
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
·····
}
}
绕来绕去终于发现ViewRootImpl最终是在WindowManagerGlobal的addView方法中初始化的，回到最初其实之所以onCreate可以更新Ui是因为ViewRootImpl尚未初始化成功，一旦ViewRootImpl初始化完成，checkThread开始工作，子线程就不能在进行Ui操作了。
7.总结
1.主线程默认创建Looper，直接使用handler不会出错，子线程必须要调用Looper.prepare()创建Looper，创建Looper的同时会创建MessageQueue，然后调用Looper.loop()开启消息循环。
2.Looper.loop()会让当前线程进入一个死循环，不断从MessageQueue中读取消息，然后回调msg.target.dispatchMessage(msg)方法。
3.平时我们使用Handler.post(runnable r)，runnable执行的线程就是调用其handler创建所在的线程，主线程handler.post就会在主线程执行，子线程创建的handler就会在子线程执行。
4.Looper死循环为什么不会把线程卡死：因为epoll和管道pipe，有消息就取出依次执行，没消息就阻塞等待，让出CPU，等有消息了，epoll会往pipe中写一个字符，把主线程唤起，主线程就继续开始循环消息。
参考资料：
1.Android Handler与Looper原理简析.
2.Android子线程真的不可以更新UI吗.
3.深入源码解析Android中的Handler,Message,MessageQueue,Looper.
