今天遇到一些关于在子线程中操作Handler的问题，感觉又要研究源代码了，但是关于Handler的话，我之前研究过，可以参考这篇文章：http://blog.csdn.net/jiangwei0910410003/article/details/17021809。但是这篇文章没有说的那么深入了，所以这次就更深入的解读一下。

摘要

Android中的应用程序都是通过消息驱动的，系统为每一个应用程序维护一个消息队列（MessageQueue)，应用程序的主线程不断的从这个消息队列中获取消息(Looper),然后对这些消息进行处理(Handler)，所以这里有三个重要的角色：

*MessageQueue:存放消息(Message)的消息队列

*Looper:轮循从消息队列中取出消息然后分发

*Handler:发送消息和处理消息

他们三者的关系是：MessageQueue和Looper是一一对应的，一个Looper可以对应多个Handler。同时这里还有一个角色就是线程Thread.后面在分析源码的时候会说到这点，当然Thread和Looper的关系也是一一对应的。

下面就从源码中分析一下流程吧(有时候看源码真的能够明白好多事~~)

第一、分析MessageQueue源码

首先来看一下MessageQueue类：

private native static long nativeInit();
private native static void nativeDestroy(long ptr);
private native static void nativePollOnce(long ptr, int timeoutMillis);
private native static void nativeWake(long ptr);
private native static boolean nativeIsIdling(long ptr);

当然这些本地方法肯定是在MessageQueue中的上层方法中调用的：

*构造方法中调用nativeInit

*获取消息方法next中调用nativePollOnce(其实相当于是处理消息)

*把消息加入到消息队列中的enqueueMessage方法中调用了nativeWake(其实相当于发送消息)

下面来看一下这些本地方法(这里主要是参考了老罗的文章：http://blog.csdn.net/luoshengyang/article/details/6817933)

1、nativeInit

它是在MessageQueue的构造方法中调用的

这个JNI方法定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：

static void android_os_MessageQueue_nativeInit(JNIEnv* env, jobject obj) {
    NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
    if (! nativeMessageQueue) {
        jniThrowRuntimeException(env, "Unable to allocate native queue");
        return;
    }

    android_os_MessageQueue_setNativeMessageQueue(env, obj, nativeMessageQueue);
}

NativeMessageQueue::NativeMessageQueue() {
    mLooper = Looper::getForThread();
    if (mLooper == NULL) {
        mLooper = new Looper(false);
        Looper::setForThread(mLooper);
    }
}

这个Looper的创建过程也很重要，不过我们暂时放一放，先分析完android_os_MessageQueue_nativeInit函数的执行，它创建了本地消息队列NativeMessageQueue对象之后，接着调用android_os_MessageQueue_setNativeMessageQueue函数来把这个消息队列对象保存在前面我们在Java层中创建的MessageQueue对象的mPtr成员变量里面：

static void android_os_MessageQueue_setNativeMessageQueue(JNIEnv* env, jobject messageQueueObj,
        NativeMessageQueue* nativeMessageQueue) {
    env->SetIntField(messageQueueObj, gMessageQueueClassInfo.mPtr,
             reinterpret_cast<jint>(nativeMessageQueue));
}

我们再回到NativeMessageQueue的构造函数中，看看JNI层的Looper对象的创建过程，即看看它的构造函数是如何实现的，这个Looper类实现在frameworks/base/libs/utils/Looper.cpp文件中：

Looper::Looper(bool allowNonCallbacks) :
	mAllowNonCallbacks(allowNonCallbacks),
	mResponseIndex(0) {
	int wakeFds[2];
	int result = pipe(wakeFds);
	......

	mWakeReadPipeFd = wakeFds[0];
	mWakeWritePipeFd = wakeFds[1];

	......

#ifdef LOOPER_USES_EPOLL
	// Allocate the epoll instance and register the wake pipe.
	mEpollFd = epoll_create(EPOLL_SIZE_HINT);
	......

	struct epoll_event eventItem;
	memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
	eventItem.events = EPOLLIN;
	eventItem.data.fd = mWakeReadPipeFd;
	result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);
	......
#else
	......
#endif

	......
}

int wakeFds[2];
int result = pipe(wakeFds);
......

mWakeReadPipeFd = wakeFds[0];
mWakeWritePipeFd = wakeFds[1];

插播一、Linux中的通信机制

要使用Linux系统的epoll机制，首先要通过epoll_create来创建一个epoll专用的文件描述符：

mEpollFd = epoll_create(EPOLL_SIZE_HINT);

接着还要通过epoll_ctl函数来告诉epoll要监控相应的文件描述符的什么事件：

struct epoll_event eventItem;
memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
eventItem.events = EPOLLIN;
eventItem.data.fd = mWakeReadPipeFd;
result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem);

       A. 在Java层，创建了一个Looper对象，这个Looper对象是用来进入消息循环的，它的内部有一个消息队列MessageQueue对象mQueue；

       B. 在JNI层，创建了一个NativeMessageQueue对象，这个NativeMessageQueue对象保存在Java层的消息队列对象mQueue的成员变量mPtr中；

       C. 在C++层，创建了一个Looper对象，保存在JNI层的NativeMessageQueue对象的成员变量mLooper中，这个对象的作用是，当Java层的消息队列中没有消息时，就使Android应用程序主线程进入等待状态，而当Java层的消息队列中来了新的消息后，就唤醒Android应用程序的主线程来处理这个消息。

到这里nativeInit方法就介绍完了，看来这个方法中做的事情还是很多的。

插播二、面试题

插播移到面试题：说说Handler机制的底层实现原理。

这个问题就是上面的解释，使用Linux中的epoll机制进行消息处理的。

2、nativePollOnce

这个方法是在MessageQueue中的next方法中调用的，其实这个方法会在后面说到Looper类中被调用，主要是从MessageQueue中取出一个Message，然后进行处理。

final Message next() {  
	int pendingIdleHandlerCount = -1; // -1 only during first iteration  
	int nextPollTimeoutMillis = 0;  

	for (;;) {  
		if (nextPollTimeoutMillis != 0) {  
			Binder.flushPendingCommands();  
		}  
		nativePollOnce(mPtr, nextPollTimeoutMillis);  

		synchronized (this) {  
			// Try to retrieve the next message.  Return if found.  
			final long now = SystemClock.uptimeMillis();  
			final Message msg = mMessages;  
			if (msg != null) {  
				final long when = msg.when;  
				if (now >= when) {  
					mBlocked = false;  
					mMessages = msg.next;  
					msg.next = null;  
					if (Config.LOGV) Log.v("MessageQueue", "Returning message: " + msg);  
					return msg;  
				} else {  
					nextPollTimeoutMillis = (int) Math.min(when - now, Integer.MAX_VALUE);  
				}  
			} else {  
				nextPollTimeoutMillis = -1;  
			}  

			// If first time, then get the number of idlers to run.  
			if (pendingIdleHandlerCount < 0) {  
				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("MessageQueue", "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;  
	}  
} 

我们就要深入分析一下JNI方法nativePollOnce了，看看它是如何进入等待状态的，这个函数定义在frameworks/base/core/jni/android_os_MessageQueue.cpp文件中：

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
        jint ptr, jint timeoutMillis) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->pollOnce(timeoutMillis);
}

void NativeMessageQueue::pollOnce(int timeoutMillis) {
    mLooper->pollOnce(timeoutMillis);
}

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
	int result = 0;
	for (;;) {
		......

		if (result != 0) {
			......

			return result;
		}

		result = pollInner(timeoutMillis);
	}
}

函数pollInner的定义如下：

int Looper::pollInner(int timeoutMillis) {
	......

	int result = ALOOPER_POLL_WAKE;

	......

#ifdef LOOPER_USES_EPOLL
	struct epoll_event eventItems[EPOLL_MAX_EVENTS];
	int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
	bool acquiredLock = false;
#else
	......
#endif

	if (eventCount < 0) {
		if (errno == EINTR) {
			goto Done;
		}

		LOGW("Poll failed with an unexpected error, errno=%d", errno);
		result = ALOOPER_POLL_ERROR;
		goto Done;
	}

	if (eventCount == 0) {
		......
		result = ALOOPER_POLL_TIMEOUT;
		goto Done;
	}

	......

#ifdef LOOPER_USES_EPOLL
	for (int i = 0; i < eventCount; i++) {
		int fd = eventItems[i].data.fd;
		uint32_t epollEvents = eventItems[i].events;
		if (fd == mWakeReadPipeFd) {
			if (epollEvents & EPOLLIN) {
				awoken();
			} else {
				LOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
			}
		} else {
			......
		}
	}
	if (acquiredLock) {
		mLock.unlock();
	}
Done: ;
#else
	......
#endif

	......

	return result;
}

int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);

if (eventCount == 0) {
    ......
    result = ALOOPER_POLL_TIMEOUT;
    goto Done;
}

for (int i = 0; i < eventCount; i++) {
	int fd = eventItems[i].data.fd;
	uint32_t epollEvents = eventItems[i].events;
	if (fd == mWakeReadPipeFd) {
		if (epollEvents & EPOLLIN) {
			awoken();
		} else {
			LOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
		}
	} else {
			......
	}
}

函数awoken的实现很简单，它只是把管道中的内容都读取出来：

void Looper::awoken() {
	......

	char buffer[16];
	ssize_t nRead;
	do {
		nRead = read(mWakeReadPipeFd, buffer, sizeof(buffer));
	} while ((nRead == -1 && errno == EINTR) || nRead == sizeof(buffer));
}

这样，消息的循环过程就分析完了，这部分逻辑还是比较复杂的，它利用Linux系统中的管道（pipe）进程间通信机制来实现消息的等待和处理，不过，了解了这部分内容之后，下面我们分析消息的发送和处理就简单多了。

3、nativeWake

在enqueueMessage方法中调用的，这个方法会在后面说到的Handler类中发送消息时调用的

final boolean enqueueMessage(Message msg, long when) {  
	......  

	final boolean needWake;  
	synchronized (this) {  
		......  

		msg.when = when;  
		//Log.d("MessageQueue", "Enqueing: " + msg);  
		Message p = mMessages;  
		if (p == null || when == 0 || when < p.when) {  
			msg.next = p;  
			mMessages = msg;  
			needWake = mBlocked; // new head, might need to wake up  
		} else {  
			Message prev = null;  
			while (p != null && p.when <= when) {  
				prev = p;  
				p = p.next;  
			}  
			msg.next = prev.next;  
			prev.next = msg;  
			needWake = false; // still waiting on head, no need to wake up  
		}  

	}  
	if (needWake) {  
		nativeWake(mPtr);  
	}  
	return true;  
}  

第一种情况比较简单，只要把消息放在消息队列头就可以了：

msg.next = p;
mMessages = msg;
needWake = mBlocked; // new head, might need to wake up

Message prev = null;
while (p != null && p.when <= when) {
	prev = p;
	p = p.next;
}
msg.next = prev.next;
prev.next = msg;
needWake = false; // still waiting on head, no need to wake up

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jobject obj, jint ptr) {
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    return nativeMessageQueue->wake();
}

void NativeMessageQueue::wake() {
    mLooper->wake();
}

void Looper::wake() {
	......

	ssize_t nWrite;
	do {
		nWrite = write(mWakeWritePipeFd, "W", 1);
	} while (nWrite == -1 && errno == EINTR);

	.......
}

这时候既然管道中有内容可读了，应用程序的主线程就会从这里的Looper类的pollInner函数返回到JNI层的nativePollOnce函数，最后返回到Java层中的MessageQueue.next函数中去，这里它就会发现消息队列中有新的消息需要处理了，于就会处理这个消息。

第二、分析Looper源码

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static Looper sMainLooper;  // guarded by Looper.class
final MessageQueue mQueue;

sTreadLocal是一个ThreadLocal类型，关于ThreadLocal类型就是为每一个线程保存一下他所拥有的变量，没有任何玄乎的东西，具体可以查看一下他的源代码，这里就不做介绍了。

sMainLooper是一个Looper,从名字定义上来看，他应该和主线程相关联的

mQueue是一个MessageQueue消息队列，这个就是我们上面已经介绍了他的所有的知识

1、构造方法

看一下他的构造方法：

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

2、prepare方法

在来看一下他的一个prepare方法

public static void prepare() {
	prepare(true);
}

为什么要说这个方法呢？

因为这个方法我可以在特定场景下会用到，其实这个方法的作用就是将一个线程和Looper进行绑定。

@Override
public void run() {
	mTid = Process.myTid();
	Looper.prepare();
	synchronized (this) {
		mLooper = Looper.myLooper();
		notifyAll();
	}
	Process.setThreadPriority(mPriority);
	onLooperPrepared();
	Looper.loop();
	mTid = -1;
}

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));
}

3.loop方法

继续看还有一个重要的方法：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
		Printer logging = me.mLogging;
		if (logging != null) {
			logging.println(">>>>> Dispatching to " + msg.target + " " +
					msg.callback + ": " + msg.what);
		}

		msg.target.dispatchMessage(msg);

		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.recycle();
	}
}

Message msg = queue.next(); // might block

msg.target.dispatchMessage(msg);

第二行代码就是将取出来的消息进行处理(这里可以查看一下Message类他的target变量其实就是一个Handler)

所以我们这里就可以看出来，Looper的loop方法就是开始从MessageQueue中去消息然后处理消息了的功能。

继续：

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

在来看一下

public static void prepareMainLooper() {
	prepare(false);
	synchronized (Looper.class) {
		if (sMainLooper != null) {
			throw new IllegalStateException("The main Looper has already been prepared.");
		}
		sMainLooper = myLooper();
	}
}

这里就得说到说到了。我们知道一般一个Android应用对应一个进程，在这个进程中可能会有多个线程，有一个线程很重要那就是主线程(或者就是我们经常说的UI线程，那么这个线程到底是什么呢？他是否和Looper进行绑定呢？)，其实我们搜一下就知道这个UI线程就是ActivityThread,我们可以查看一下他的源代码(frameworks/base/core/java/android/app/ActivityThread.java)：

public final class ActivityThread {
	......

	public static final void main(String[] args) {
		......

		Looper.prepareMainLooper();

		......

		ActivityThread thread = new ActivityThread();
		thread.attach(false);
		
		......

		Looper.loop();

		......

		thread.detach();

		......
	}
}

继续：

public static Looper getMainLooper() {
	synchronized (Looper.class) {
		return sMainLooper;
	}
}

这样我们就介绍完了Looper类，其实这个类中最主要的就是三个方法：

*构造方法：初始化MessageQueue对象，然后将这个MessageQueue和Looper进行绑定，即一一对应的

*prepare方法：初始化一个Looper对象，然后存入到ThreadLocal中，即将Looper和当前线成进行绑定，也是一一对应的

*loop方法：进入循环开始消息的处理，会调用MessageQueue的next方法

其他都是些辅助的方法，当然也是有很多用途的，比如我现在想判断当前线程是不是主线程该怎么做？

这里我们就可以使用myLooper()方法获取当前线程的Looper对象，然后在使用getMainLooper()方法获取主线程的Looper对象，两者就行比较就可以了，当然这里myLooper()方法返回的值可能会为null,因为如果这个线程并没有和Looper进行绑定(就是没有调用prepare方法)，那么就是为null，但是getMainLooper()方法返回肯定不为null,因为主线程在初始化的时候就已经绑定了一个Looper。这个是系统执行的。

第三、分析Handler源码

这个类我们之前解释过了，其实他的作用就是用来发送消息和处理消息的，等我们分析完源码之后会发现，其实这个步骤底层并不是他做的，而是MessageQueue对象和底层打交道，底层的Looper对象做的,这个如果还是不理解的话，可以在看看之前的内容。

1、构造方法

首先还是来看一下他的构造方法：

他的构造方法很多，默认构造方法：

public Handler() {
	this(null, false);
}

public Handler(Callback callback) {
	this(callback, false);
}

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的消息队列。

他还有一个构造方法：

public Handler(Looper looper) {
	this(looper, null, false);
}

但是我们一般在使用Handler的时候，都是使用它的无参构造方法，并且是在主线程中定义的，所以说这个Handler是和主线程对应的，当然我们可以在主线程中定义多个Handler都是可以的

插播面试题

插播一个面试题：一个线程可以对应多个Handler,又因为一个Looper对应一个MessageQueue,那么多个Handler对应一个MessageQueue,问题来了，多个Handler在发送消息以及在处理消息的时候，为什么能做到有条不紊，不会出错呢?

其实这个答案我们可以在Looper中的loop方法中找到，之前在看这个方法的时候，看到他会取出消息然后处理，那时候代码是这样的：

msg.target.dispatchMessage(msg);

回来继续，主线程默认是绑定了一个Looper的，所以在主线程中定义Handler是没有问题的，当然如果我们想在子线程中定义Handler的话，那么就必须将当前线程绑定一个Looper,调用Looper.prepare()方法就可以了。

插播面试题

面试题问题：如果我现在在子线程中定义了一个Handler,但是我又不想让这个线程绑定一个Looper(即不想额外的调用prepare方法)，这时候我们就要用到Looper中的一个方法getMainLooper(),这个就是获取主线程的Looper,然后在用Handler指定的构造方法实例化一下即可

Handler handler = new Handler(Looper.getMainLooper()){
		@Override
		public void dispatchMessage(Message msg){
			//handle message...
		}
	}

2、dispatchMessage方法

继续看一下Handler的处理消息的方法dispatchMessage

public void dispatchMessage(Message msg) {
	if (msg.callback != null) {
		handleCallback(msg);
	} else {
		if (mCallback != null) {
			if (mCallback.handleMessage(msg)) {
				return;
			}
		}
		handleMessage(msg);
	}
}

这里会做判断，如果callback不为null的话，就调用handleCallback方法：

private static void handleCallback(Message message) {
	message.callback.run();
}

如果callback不为null.在做一次判断mCallback是否为null

这个mCallback变量其实就是个回调接口类型CallBack：

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

public void handleMessage(Message msg) {
}

总结一下dispatchMessage方法的执行流程：

1.首先判断msg变量中的callback是否为null,如果不为null,就执行他的run方法(Runnable)，然后结束,如果为null，转入2

2.判断mCallback变量是否为null,如果不为null,就调用他的handleMessage(...)回调方法，然后结束，如果为null,注入3

3.执行Handler本身的handleMessage(...)方法

所以我们如果想在在dispatchMessage方法中执行我们自己的逻辑有很多种方式：

1.直接定义子类覆盖dispatchMessage方法

2.定义Handler的时候，传入一个CallBack接口，外部实现他的handleMessage回调方法

3.在发送消息的时候，实例化Message的callback变量(Runnable),将代码放到run方法中

4.直接重写父类的handleMessage方法

3、sendMessage方法

下面继续看一下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);
}

再看一下sendMessageAtTime方法：

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方法：

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
	msg.target = this;
	if (mAsynchronous) {
		msg.setAsynchronous(true);
	}
	return queue.enqueueMessage(msg, uptimeMillis);
}

好吧，这里才是重点，这里有两部分内容，第一部分是我们需要将当前的Handler对象赋值给Message中的target,就是每个消息必须

要有一个target，这样就不会发生混乱了(上面讲到的那个面试题中提到的知识就在这里)

还有就是最终会调用消息队列的enqueueMessage方法，这个在之前介绍MessageQueue类的时候已经说过了。

4、postXXX方法

最后在看一个重要的方法：

public final boolean post(Runnable r){
	return  sendMessageDelayed(getPostMessage(r), 0);
}

private static Message getPostMessage(Runnable r) {
	Message m = Message.obtain();
	m.callback = r;
	return m;
}

但是post这个方法其实是非常重要的，后面会说到

总结

到这里把Handler就讲解完了，那么Handler,Looper,MessageQueue都讲解完了，下面来总结一下吧，来张图：

1.首先是Handler，Looper，MessageQueue，Thread之间的关系：

Looper和Message以及Thread他们三个之间是一一对应的关系，一个Looper对应多个Handler

2.在MessageQueue的构造方法中调用了nativeInit方法，这个方法在本地创建了Looper和MessageQueue对象，这个和Java中的Looper，MessageQueue是不一样的，但是你可以把他们看成是一一对应。

拓展

我们在使用Handler的时候主要是因为主线程中不能做耗时的操作，而子线程中又不能刷新控件，所以会使用到Handler.

其实我们如果想在子线程中刷新View的话可以有很多种方式：

1.Handler机制通信(最基础的)

2.Activity类中的runOnUiThread(...)方法

这个又得看源码了：

public final void runOnUiThread(Runnable action) {
	if (Thread.currentThread() != mUiThread) {
		mHandler.post(action);
	} else {
		action.run();
	}
}

3.View类中的postXXX方法

这个还得看源码：

public boolean postDelayed(Runnable action, long delayMillis) {
	final AttachInfo attachInfo = mAttachInfo;
	if (attachInfo != null) {
		return attachInfo.mHandler.postDelayed(action, delayMillis);
	}
	// Assume that post will succeed later
	ViewRootImpl.getRunQueue().postDelayed(action, delayMillis);
	return true;
}

所以说，当我们在主线程中定义了控件，然后使用这些方法来刷新就是通过Handler来实现的。之前也是说对的，Android中的应用就是消息驱动的，后面在分析其他的源码的时候还会发现到处都用到了Handler机制。所以说Handler机制是多么的重要呀~~

(Ps：哎，终于写完了，累死人了，之前解读过一次Handler机制的源码，但是那时候没有这么深入)

Android中对消息机制(Handler)的再次解读