(注:本文源码基于Android7.1)
如果读者做过Android开发,相信对Android中Handler这个类并不陌生。通常情况下,Handler是线程与UI线程交互的工具。本文希望通过Android的源代码,让大家能更加深刻地体会到Handler相关类的实现原理和内部机制。
我们知道,通过Handler发送消息,大致有两种方式:
1.Handler.post(Runnable)
2.Handler.sendMessage(Message)
其实,这两种方式是一种方式,因为我们通过postRunnable最终也会转化为sendMessage。
//code android/os/Handler.java
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r)/*将Runnable类型转化为Message类型*/, 0);
}
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}
通过上面的Handler的源码,我们可以看出,不论上层的接口是怎么样的,最终的Handler所抛出的类型永远是Message。而当我们通过Handler.send方法发送一个Message的时候,最终都会调用到Handler的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);
}
这里,引出我们的一个新的主角:MessageQueue,通过类名,我们也能见名知意,就是一个消息队列。消息队列是一种生产消费的设计模式,Handler作为生产者通过enqueueMessage方法往queue中入队消息。那么,这个MessageQueue又是如何生成的呢？
public Handler(Callback callback, boolean async) {
....
mLooper = Looper.myLooper();
....
mQueue = mLooper.mQueue;//获取一个Queue
....
}
我们通过Handler的构造器可以看出,Handler中的MessageQueue对象,实际上是来源于Looper对象。那么又带来另外一个问题,Looper对象又是从哪里来的呢？我们这篇文章开始没多久,没想到各大主角就集聚一堂。从上面的代码中,我们可以看出,Handler对象中的Looper对象源于Looper.myLooper()方法。
//code Looper.java
static final ThreadLocal sThreadLocal = new ThreadLocal();
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}
myLooper方法中,将通过一个全局静态量sThreadLocal来获取当前线程中唯一的Looper,而这个Looper是当前线程调用Looper.prepare方法生成并放入sThreadLocal中的。
public static void prepare() {
prepare(true);
}
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));
}
那么又有另外一个问题,UI线程中,我们并没有调用Looper.prepare方法,那么UI线程中的Looper又是在哪儿生成的呢？
实际上,要回答合格问题,需要从UI线程的生成开始说起:UI线程伴随着Android进程的启动而启动,入口在ActivityThread.main中。而ActivityThread的main方法中,将通过Looper.prepareMainLooper()方法来生成UI线程的Looper:
//code ActivityThread.java
public static void main(String[] args){
....
Looper.prepareMainLooper();
....
}
// code Looper.java
public static void prepareMainLooper() {
prepare(false);
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
Looper类中,prepareMainLooper方法和prepare方法的差别就是是否需要对sMainLooper这个静态量置位。各位看官是否被绕懵了？不要紧,非墨带大家在屡一下思路。
- 首先,Android进程启动的时候,会调用Looper.prepareMainLooper()方法来给UI线程准备一个默认Looper
- 当我们直接生成一个Handler对象的时候(UI线程下),Handler会通过调用Looper.myLooper();获取当前线程中的Looper对象,并存在自己的成员变量Looper中
- Handler对象获取Looper对象中的MessageQueue对象,并存在自己的mQueue变量
- 当外界通过Handler发送消息的时候,实际上就是往这个mQueue中入队消息
//code Handler.java
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
Handler通过enqueueMessage方法将消息加入消息队列,而MessageQueue通过enqueueMessage来接受消息。上面我们提到了,Handler系统的总体结构是要完成一个生产者消费者的消息队列机制,而Handler在实现这个机制的方案，非常类似我们的BlockQueue。当时Handler和MessageQueue系统很明显没有直接采用BlockQueue的API。那么MessageQueue是怎么做的呢？
boolean enqueueMessage(Message msg, long when) {
....
synchronized (this) {
....
Message p = mMessages;//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 {
....
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;
}
上面代码很好理解,大致就是将你的消息放入一个单向链表队列中去。最后通过nativeWake(mPtr)唤醒一个东西。那么mPtr是什么呢？为何要唤醒它？
实际上mPtr是一个native层的一个指针变量,为了说明MessageQueue的消息队列机制,我们只读Java层的代码是不够的,我们先来看下MessageQueue的java层代码:
//code MessageQueue.java
MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
mPtr = nativeInit();
}
我们看到,实际上,mPtr是通过调用nativeInit方法返回的一个native指针,我们来看下native层MessageQueue的代码:
static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();//生成一个NativeMessageQueue对象
if (!nativeMessageQueue) {
jniThrowRuntimeException(env, "Unable to allocate native queue");
return 0;
}
nativeMessageQueue->incStrong(env);
return reinterpret_cast(nativeMessageQueue);
//返回NativeMessageQueue对象指针
}
可以看出,在我们的native层,实际上生成了一个NativeMessageQueue对象,而这个对象的指针,由native方法返回给上层。那么NativeMessageQueue对象又做了什么呢？
NativeMessageQueue::NativeMessageQueue() :
mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {
....
mLooper = Looper::getForThread();//线程内唯一的Looper对象
if (mLooper == NULL) {
mLooper = new Looper(false);
Looper::setForThread(mLooper);
}
}
各位看官是否似曾相识,NativeMessageQueue又写了一个Looper对象,而且也是线程内唯一的。希望大家一定要滤清这两个Looper对象,他们不在同一个层次,但是在同一个进程中,且都线程唯一。当上面我们只是说了生产者这边的情况,如果我们脱离了消费者,其实我们并不能说明MessageQueue的消息队列是如何完成消息传递通讯的。那么MessageQueue的消费者是谁呢？
实际上,我们一直在说它,就是Java层的Looper对象,它就像它的名字一样,就是一个始终循环的对象,而这种循环是通过loop方法实现：
//code Looper.java
public static void loop() {
...
for (;;) {
Message msg = queue.next(); // 消费消息
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
....
msg.target.dispatchMessage(msg);
...
}
....
msg.recycle();
}
...
}
我们看到,Looper对象通过MessageQueue的next方法来获取并消费消息:
//code MessageQueue.java
Message next() {
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
for (;;) {
....
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;
}
....
}
....
}
}
Java层的MessageQueue通过调用native层的nativePollOnce方法来获取消息,而在native层的代码又调用了我们上面所说的NativeMessageQueue对象的pollOnce方法,而NativeMessageQueue又会调用native层的Looper对象的pollOnce方法:
static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jlong ptr, jint timeoutMillis) {
....
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}
void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
...
mLooper->pollOnce(timeoutMillis);
....
}
//code Looper.h
int pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData);
inline int pollOnce(int timeoutMillis) {
return pollOnce(timeoutMillis, NULL, NULL, NULL);
}
pollOnce(int)方法最终会调用到 pollOnce(int, int, int, void**),在pollOnce(int)方法中会将后面的参数都给默认NULL,pollOnce中又会调用pollInner方法
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
....
result = pollInner(timeoutMillis);
}
int Looper::pollInner(int timeoutMillis) {
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
// No longer idling.
mPolling = false;
// Acquire lock.
mLock.lock();
....
}
不知道看官们累了没有,我们似乎终于找到了一点门路:epoll_wait函数。这是属于linux中epoll族中的函数。该函数类似Java中的nio机制,mEpollFd是epoll文件描述符，而epoll_wait用于监听发生在描述符mEpollFd上的事件。返回值代表所监听到的事件数目。
//code pollInner();
for (int i = 0; i < eventCount; i++) {
int fd = eventItems[i].data.fd;
uint32_t epollEvents = eventItems[i].events;
if (fd == mWakeEventFd) {
if (epollEvents & EPOLLIN) {
awoken();//等待ing
} else {
....
}
} else {
....
}
}
void Looper::awoken() {
uint64_t counter;
TEMP_FAILURE_RETRY(read(mWakeEventFd, &counter, sizeof(uint64_t)));//通过read mWakeEventFd中的数据陷入等待
}
在Epoll收到EPOLLIN陷入awoken等待中,等待的方式,是通过读取mWakeEventFd文件中的64位数据。笔者再给大家回顾一下这个过程:
- Looper对象通过loop方法消费MesssageQueue中的消息,而获取消息的方法是通过MesssageQueue.next()方法
- MesssageQueue.next()方法中会调用native层NativeMessageQueue对象的pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) 方法
- NativeMessageQueue调用Native层Looper对象的pollInner()方法
- Looper通过监听epoll文件描述符来监听事件
- Looper中的Epoll得到EPOLLIN信号,将调用awoken()等待
那么消费者陷入等待,生产者是如何通知消费者的呢？上面我们提到了生产者是Handler对象,因为是它往MessageQueue中增加消息的,而增加消息的方法是通过调用MessageQueue的boolean enqueueMessage(Message msg, long when)方法。
boolean enqueueMessage(Message msg, long when) {
...
if (needWake) {
nativeWake(mPtr);
}
...
}
在MessageQueue的enqueueMessage方法中会调用nativeWake方法,而native层的nativeWake会调用native层Looper的wake方法。
void NativeMessageQueue::wake() {
mLooper->wake();
}
而通过往mWakeEventFd文件中写入数据,实现了上面Looper对象的唤醒
void Looper::wake() {
....
uint64_t inc = 1;
ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
....
}
好了,我们费了那么大的周折讲了在Android中消息队列如何实现阻塞和释放效果。我们再回头看看Java层的Looper对象,获取了一个Message对象以后,又是如何处理的:
public static void loop() {
...
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
....
try {
msg.target.dispatchMessage(msg);//target is Handler
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
...
msg.recycleUnchecked();
}
....
}
当Looper(Java)从消息队列MessageQueue中通过next方法获取一个消息Message后,将调用Message.target的dispatchMessage方法。那么这个target变量又是什么呢？其实,这个target变量就是我们最早登场的主角Handler。我们看下这个Handler是如何被记录在Message变量中的:
//code Handler.java
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;//记录Handler到Message对象的target属性中去
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
如上面代码所示,Handler在调用自身的enqueueMessage方法的时候,会将自己作为target记录到需要放入MessageQueue的Message对象中去。我们再回到Looper的代码中去,Looper调用了Handler的dispatchMessage(Message)方法来处理消息：
public void dispatchMessage(Message msg) {
if (msg.callback != null) {//通过Handler.post(Runnable方式执行)
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
当消息通过Handler.post(Runnable)方式发出的时候,Runnable对象会被记录成Message的callback成员。如果以其他的方式进行,那么将被Handler自己的mCallback对象拦截。如果没有这个对象,或者mCallback不处理这个消息,将调用handleMessage(Message)处理消息。而这个方法是一个空方法,将由子类完成消息处理。实际上,文章到这里,Handler,MessageQueue,Message,Looper几个对象间的关系已经很清楚了,基本就是Handler为生产者,MessageQueue为生产队列,Message为产品,Looper为消费。而阻塞和唤醒操作由native的Looper对象通过epoll方式实现。那么还有一个问题:
我们的Handler作为target变量被存放在Message对象中,Message对象如何保证我们的Handler对象的正常释放的呢？
- 回答这个问题我们需要回到Looper(java)的loop代码中去寻找：
//code Looper.loop
...
msg.target.dispatchMessage(msg);
...
msg.recycleUnchecked();//执行回收操作
当msg被处理完成之后,msg将调用recycleUnchecked方法进行回收,就是在这个函数中,Message对象被清空,并且放入缓冲池中:
void recycleUnchecked() {
....
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {//放入缓冲池,减少碎片
next = sPool;
sPool = this;
sPoolSize++;
}
}
....
}