Android消息机制Handler,MessageQueue，Looper源码解析

首先我们先给大家介绍下Handler与Looper与MessageQueue整体运作

Handler：用于处理Message，可以有多个实例

Message：用于线程之间传递信息，发送的信息放入MessageQueue中

MessageQueue：是一个消息队列，用来存储Message信息，每个线程只有一个实例。

Looper：每个线程只有一个Looper，他是一个无限循环，不断地从MessageQueue中取出Message，发给handler处理

如图所示，我们通过handler发送一个消息，消息放入MessageQueue这个消息队列里面，Looper无限循环去检测MessageQueue是否有消息需要处理，looper将处理（ui更新）交至handler，也就实现了由子线程切换到主线程了。

带着这个主干，我们从源码方面进行解析：

Message

Message经常被用来传输，那么它可以传输哪些数据呢？

arg1，arg2整数类型

Object 类型obj

What 用户自定义的信息代码，每个handler都有自己的信息代码，所以不用担心多个handler发送信息冲突。

Bundle数据传输

Message中有几个属性先介绍下，后面会有用到，

next：下一个可用对象，可以访问下一个可用的Message

when：表示该消息的等待时间

target：一个Handler对象，looper中将信息处理由该对象传回主线程

我们平时创建Message对象都是通过Message msg=new Message（）；但是不推荐这种方式，推荐使用Message msg=Message.obtain();为什么呢？

/**
* Return a new Message instance from the global pool. Allows us to
* avoid allocating new objects in many cases.
*/
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内部有一个回收池，如果回收池部位null那

就直接重用回收池中的消息，不用重新分配空间，节省资源。sPoll是回收头的消息，next是下一个可用的消息，放置头部等待下次使用。

既然有个回收池，那就看看怎么回事吧，

/**
* Recycles a Message that may be in-use.
* Used internally by the MessageQueue and Looper when disposing of queued Messages.
*/
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;

synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}

注释说到：回收一个消息，可以使用，通过MessageQueue和Looper在处理消息队列内部消息时使用

通过recycleUnchecked方法对Message对象的回收，就是把这个消息标记为可使用，并且将其他信息（属性）初始化，最终这个Message会在MessageQueue和Looper中使用。

MessageQueue——一个线程只有一个

MessageQueue是一个消息队列，用来存储Message，虽然说MessageQueue是一个消息队列，但是它的底层实现是一个单链表，既然是存储的，那就涉及到了插入和删除，而正好聊表在增加和删除方面有着优势，

插入

boolean enqueueMessage(Message msg, long when) {
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.");
}

synchronized (this) {
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;
}

msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// Inserted within the middle of the queue.  Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
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;
}

// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}

既然是单链表的插入，那么大家可能就会有疑问了，是头插呢还是尾插。

从上述代码中我们发现这里的插入方法既有头插，也有插入链表中间，插入位置取决于当前插入信息的等待时间

msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = mBlocked;
}

当消息队列中没有消息或者当前消息的等待时间为0或者当前消息的等待时间小于链表头的消息的等待时间，就进行头插法。

否则根据当前消息的等待时间按照升序方式插入到指定位置（有点像插入排序有木有）

这个等待时间就是我们

public final boolean sendMessageDelayed(Message msg, long delayMillis)

平时使用的那个sendeMessageDelayed方法中的delayMillis

删除

Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr;
if (ptr == 0) {
return null;
}

int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}

nativePollOnce(ptr, nextPollTimeoutMillis);

synchronized (this) {
// Try to retrieve the next message.  Return if found.
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// Stalled by a barrier.  Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready.  Set a timeout to wake up when it is ready.
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;
}

// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}

// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
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);
}

// Run the idle handlers.
// We only ever reach this code block during the first iteration.
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);
}
}
}

// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;

// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}

可以发现next方法中是一个无限循环，如果消息队列中没有了消息，就会一直阻塞在那里，当有消息来时，next就会返回这条消息并从单链表中删除

Looper ——一个线程只有一个

Looper在消息机制中扮演的是消息循环的角色，它会不停地检索MessageQueue中是否有新的消息，如果有就立刻处理，没有就会阻塞在那里。

那么我们看下构造方法

private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}

Looper的构造方法就是对MessageQueue进行了初始化

因为Looper是处理消息的，所以就看看Looper中最重要的方法loop吧

/**
* Run the message queue in this thread. Be sure to call
* {@link #quit()} to end the 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;

// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();

for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}

// This must be in a local variable, in case a UI event sets the logger
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}

final long traceTag = me.mTraceTag;
if (traceTag != 0) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}

if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}

// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}

msg.recycleUnchecked();
}
}

主要的环节就在中间的一个for（；；）死循环

通过queue.next（）读取MessageQueue中的消息，并且从MessageQueue中移除，取得了Message，就可以对其进行处理了。

msg.target.dispatchMessage(msg);

处理完后对其进行回收

msg.recycleUnchecked();

这里我们发现从当前线程切换到了handler创建的线程中执行消息处理，

MessageQueue和Looper和Message的操作都是在子线程中进行，

而Handler是在主线程。

最终消息的处理还是回归到了UI线程，这正好符合在主线程更新UI的逻辑。

/**
* Handle system messages here.
*/
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}

这个就是处理消息的具体细节了。一说到处理消息的具体细节实现我们应该会想到接口或者抽象方法，没错在Handler中就存在着接口和需要子类实现的方法，等在子类去继承自己去实现（如何处理消息）。

在上述代码有三次处理

msg.Callback——–>handleCallback()

mCallback———->mCallback.handleMessage()

handleMessage()

Runnable callback;

在Message中callback 是一个Runnable,就是Handler中post（Runnable）的那个，

public interface Callback {
public boolean handleMessage(Message msg);
}

mCallback回调接口

/**
* Subclasses must implement this to receive messages.
*/
public void handleMessage(Message msg) {
}

子类必须实现此接收消息

具体的处理细节是我们自己去实现，而这些刚好都是些接口，回调的需要实现的方法，这里我们应该想起来我们平时创建Handler的几种方式了吧。

post(Runnable)

Handler handler2=new Handler();
handler2.post(new Runnable() {
@Override
public void run() {
mTextView.setText("post方式发送消息并处理消息");
Log.d(TAG, "CallBack");
}
});

2.Callback回调

Handler  handler1=new Handler(handlerCallBack);
handler1.sendEmptyMessage(1);

3.派生Handler类

MyHandler myHandler=new MyHandler();
myHandler.sendEmptyMessage(1);

4.实例化Handler

Handler handler=new Handler(){
@Override
public void handleMessage(Message msg) {
mTextView.setText("实例类实现接受消息");
super.handleMessage(msg);
}
};
handler.sendEmptyMessage(1);

这就是我们平时经常创建，使用Handler的方式。

这下我们应该理解Handler对消息的处理方式了吧

他会判断Message的回调事件(Runnable)是否为null,

如果不为null,执行handleCallback(msg)

如果是null，

判断Handler的Callback回调接口是否为null 如果不为null，执行handleMessage（msg）

如果是null，

则执行Handler的方法handleMessage(msg)

到此Message信息就处理完了。

因为Loooper的loop方法是无限循环，因此Looper中提供了两个退出方法quit和quitSafty，一个立刻退出Looper，一个是设置退出标记，等待MessageQueue中的任务执行完毕在完全退出。而这两个方法也会调用MessageQueue的quit和quitSafty方法将Message的next设置为null。

但是，

细心地人可会产生疑问

Handler只讲了发送消息。

MessageQueue是消息队列，进行存储消息

Looper中初始化MessageQueue，并且使用next处理消息队列中的消息

那么消息是怎么加入进去消息队列的，Looper又是在什么时候初始化的，存储在哪.

消息是如何加入消息队列的呢，前面讲了消息队列加入消息是MessageQueue中的enqueueMessage方法，其实我们post、sendMessage的时候最终都会调用到enqueueMessage（msg）

Looper是Handle中初始化的

Looper存储在ThreadLocal.Values localValues中的table数组中

到现在我们就要将最后两个类Handler和ThreadLocal

Handler

构造方法

public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}

mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}

从构造方法中明显就可以看出对Looper进行了初始化并且将Looper中的MessageQueue对象赋给了Handler中的MessageQueue 对象

。

我们看看Looper.myLooper（）是什么。

public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}

我们看到了我刚才提示的ThreadLocal，那么ThreadLocal是个什么东东呢。

ThreadLocal

ThreadLocal是一个线程内部的数据存储类，可以在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据。ThreadLocal可以用于哪些使用场景呢，一般来说，当某些数据是以线程为作用域，并且不同线程具有不同的数据副本，那么就可以考虑采用TreadLocal了，对于Handle来说，他要获取当前线程的Looper，通过Looper去进行消息循环处理，很显然，Looper的作用域就是当前线程，并且不同的线程具有不同的Looper，这个时候就可以通过ThreadLocal轻松存取Looper了。

如果我们不采用ThreadLocal，那么系统就得提供一个全局哈希表供Handler查找指定线程的Looper，这样就得创建一个类似LooperManager的管理类去进行管理，显然没有直接使用ThreadLocal好。

在Looper、ActivityThread以及AMS中都用到了ThreadLocal。

ThreadLocal的内部有一个ThreadLocal.Values localValues成员，该成员内部有一个数组table，Looper的值就存在这里面

通过put代码我们可以得出一个存储规则，那就是ThreadLocal的值是在ThreadLocal的reference字段所标识的对象的下一个位置。get中也是获取到ThreadLocal的reference字段的存储位置，返回数组的下一个元素。

从get 和put方法我们所操作的对象都是当前线程的localValues 对象的table数组，因此在不同的线程访问同一个ThreadLocal的get和set方法，它们对ThreadLocal所进行的读写操作仅限于各自线程的内部.

讲到这里基本也就结束了。

我们最后在捋一遍：

Handler在初始化的时候就获取到了当前线程的Looper，通过post（Runnable），Callback回调接口，派生子类来创建一个handler，然后发送消息，最终他们都会执行enqueueMessage(msg)把消息加入到消息队列MessageQueue里面去。

MessageQueue是一个消息队列用来存储消息，但是它的底层实现是单链表，因为单链表在插入和删除更有优势，，而且插入的时候是根据每个消息的等待时间when升序插入的，提高了效率。

之后通过Looper和MessageQueue的next方法进行一个读取消息的操作，最后loop方法中调用了msg.target.dispatchMessage，msg.target是一个handler对象，最终消息的处理还是交给了handler，进行三次判空处理，执行消息处理。