Android Handler 机制：Handler 运行机制完整梳理
Posted 灰色飘零
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Android Handler 机制：Handler 运行机制完整梳理相关的知识，希望对你有一定的参考价值。
做android开发的都应该知道Handler的运行机制，这个问题属于老生常谈了。
这里再简单赘述一下：
- Handler 负责发送消息；
- Looper 负责接收 Handler 发送的消息，并在合适的时间将消息回传给Handler；
- MessageQueue是一个存储消息的队列容器。
本文我们会详细完整的将Handler的运行机制梳理一遍。
一、ActivityThread类和APP的启动过程
为什么要讲ActivityThread和App的启动过程，因为Handler、Looper都是在这个阶段进行创建和初始化的。
ActivityThread就是我们常说的主线程或UI线程，ActivityThread的main方法是一个APP的真正入口，MainLooper在它的main方法中被创建。
//ActivityThread的main方法 public static void main(String[] args) { ... Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); //在attach方法中会完成Application对象的初始化，然后调用Application的onCreate()方法 thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } ... Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); }
主线程的Handler作为ActivityThread的成员变量，是在ActivityThread的main方法被执行，ActivityThread被创建时进行初始化的。MessageQueue在Looper创建的时候作为成员变量被初始化创建。
二、Handler创建Message并发送给Looper
当我们创建一个Message并交给Handler发送的时候，内部调用的代码如下：
public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis); }
最终调用到的是MessageQueue的enqueueMessage方法，enqueueMessage 是核心处理方法。下面是MessageQueue.enqueueMessage方法的代码：
boolean enqueueMessage(Message msg, long when) {
...synchronized (this) {
...
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;
}
这段代码处理的事情就是将进入消息队列的Message插入到合适的位置，并通过needWake判断是否需要调用底层唤醒整个消息队列。
结合上述的代码，我们可以得出整体的逻辑如下所示：
+-------+ +------------+ +------------------+ +--------------+
|Handler| |MessageQueue| |NativeMessageQueue| |Looper(Native)|
+--+----+ +-----+------+ +---------+--------+ +-------+------+
| | | |
| | | |
sendMessage()| | | |
+----------> | | | |
| | | |
|enqueueMessage()| | |
+--------------> | | |
| | | |
| | | |
| | nativeWake() | |
| | wake() | |
| +------------------> | |
| | | |
| | | wake() |
| | +------------------> |
| | | |
| | | |
| | | |write(mWakeWritePipeFd, "W", 1)
| | | |
| | | |
+ + + +
三、Looper循环处理MessageQueue的Message
我们知道Loop循环处理Message调用的方法是 Looper.loop()。
而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(); ... 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); } ... } }
下面是MessageQueue的next方法的代码：
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;
}
}
这段代码处理的事情就是不断从MessageQueue中取出消息，如果没有消息的时候会给nativePollOnce的nextPollTimeoutMillis设置为-1，这时消息队列就处于阻塞状态了。
结合上述代码，可以得出逻辑如下图所示：
+------+ +------------+ +------------------+ +--------------+
|Looper| |MessageQueue| |NativeMessageQueue| |Looper(Native)|
+--+---+ +------+-----+ +---------+--------+ +-------+------+
| | | |
+-------------------------------------------------------------------------------+
|[msg loop] | next() | | | |
| +------------> | | | |
| | | | | |
| | | | | |
| | | nativePollOnce() | | |
| | | pollOnce() | | |
| | +----------------> | | |
| | | | | |
| | | | | |
| | | | | |
| | | | pollOnce() | |
| | | +-----------------> | |
| | | | | |
| | | | | epoll_wait()
| | | | +--------+ |
| | | | | | |
| | | | | | |
| | | | | <------+ |
| | | | | awoken() |
| + + + + |
+-------------------------------------------------------------------------------+
四、总结
1. 相关知识点
HandlerThread、ThreadLocal、Linux Epoll 机制。
HandlerThread:
HandlerThread相比Thread最大的优势在于引入MessageQueue概念，可以进行多任务队列管理。HandlerThread背后只有一个线程，所以任务是串行依次执行的。串行相对于并行来说更安全，各任务之间不会存在多线程安全问题。HandlerThread所产生的线程会一直存活，Looper会在该线程中持续的检查MessageQueue，并开启消息处理的循环。这一点和Thread()，AsyncTask都不同，thread实例的重用可以避免线程相关的对象的频繁重建和销毁。 getLooper().quit();来退出这个线程，其实原理很简单，就是改变在消息循环里面标志位，退出整个while循环，使线程执行完毕。
注意：要想更新界面内容，还是需要使用主线程的Looper，不然的话还是会抛错误。
2. 推荐文章：
1. Android Handler机制 - MessageQueue如何处理消息：https://blog.csdn.net/lovelease/article/details/81988696
2. ActivityThread的理解和APP的启动过程：https://blog.csdn.net/hzwailll/article/details/85339714
以上是关于Android Handler 机制：Handler 运行机制完整梳理的主要内容，如果未能解决你的问题，请参考以下文章