有关Handler机制原理的总结

Handler是线程与线程间进行通信的一套机制。

       Handler是常被开发者拿来更新UI的一种消息处理机制，它的运行机制需要底层的Looper和MessageQueue的支撑。

       一个Android应用程序被创建时就会创建一个进程，该进程用应用的包名作为进程名。该进程会启动主线程ActivityThread，也叫做UI主线程，但有时需要做些耗时操作，为了不能够去阻塞UI主线程的正常运行，我们将它放在子线程中进行操作，操作完成后需要绘制UI，但Android子线程不能直接操作UI线程的，所以通过Handler来进行通信。

      为什么Android子线程不能直接操作主线程？Android UI线程不是线程安全的，如果多线程并发的话就会造成界面混乱，不可控的状态。那为什么不能让主程序加上锁机制，这样就能够线程安全了？可上锁就会有造成访问的逻辑变得很麻烦、很复杂，并且会阻塞其他线程的执行。综上问题，Android采用单线程模型来处理UI操作。

Handler机制原理

       Handler机制是由Looper和MessageQueue来构建消息机制的。

       MessageQueue：消息队列。虽然名为队列，但事实上它的内部存储结构并不是真正的队列，而是采用单链表的数据结构来存储消息列表的，其中主要有插入enqueue()和从中拿走并删除next()两个方法。

       Looper：消息循环。MessageQueue来存储消息，Looper则是以无限循环的方式去查找是否有新消息，如有就去处理，若没有就standby(等待)。一个线程创建Handler时首先需要创建Looper的，不然报错：RuntimeException: No Looper; Looper.prepare() wasn't called on this thread，而且每个线程下只需要创建一个Looper，不然会报错：RuntimeException: Only one Looper
may be created per thread。

class TestThread extends Thread{

@Override
public void run() {
super.run();
Looper.prepare();
Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
//....
}
};
Looper.loop();
}
}

但是UI线程是不需要创建的，是因为ActivityTread创建时就初始化了Looper，所以在UI主线程就能直接使用Handler。

在特定的线程中Handler使用当前的Looper来构建消息循环系统，那handler是如何获取到当前线程的Looper的？是通过ThreadLocal来获取每个线程的Looper的，ThreadLocal是一个线程内部的数据存储类。它是一个泛型类，里面有set()和get()两个主要方法。有关ThreadLocal的了解可参考Blog：ThreadLocal

      Handler通过send Message或者post去将消息发送到messageQueue中，会调用enqueueMessage()方法，而Message Queue的next()方法会将该消息返回给Looper，Looper接收到消息，就会处理－－Looper就交由handler的dispatchMessage方法

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

接着，handler的dispatchMessage方法最终会调用handlerMessage方法来处理消息：

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

最后，就是我们经常见到的重写handlerMessage方法去处理消息及UI操作了。