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操作了。