Android消息机制，从Java层到Native层剖析

由Handler、MessageQueue、Looper构成的线程消息通信机制在Android开发中非常常用，不过大部分人都只粗浅地看了Java层的实现，对其中的细节不甚了了，这篇博文将研究Android消息机制从Java层到Native层的实现。

消息机制由于更贴近抽象设计，所以整个结构更简单，只包含了消息的产生、分发，不像Input子系统那样还有归类、过滤等环节。整体的结构如下图：

Android Java层消息机制

消息的产生

在Java层中消息的产生都来源于用户创建的Message对象，经过封装的Runnable对象，或调用obtainMessage从Message Pool中获得，Message Pool指的是Message类内的Message循环队列，队头是静态的Message对象sPool，该队列最大容纳MAX_POOL_SIZE（50）个Message：

MessagePool对Message的复用节省了不断创建Message带来的开销，如果当前50个Message都已经被用过，由于MessagePool是循环队列，则会回到队头并请空该Message，向下复用。

BlockingRunnable

看Java层Handler的源码的时候发现了一个奇怪的东西：BlockingRunnable，基本上没有用过的东西，也没看别人讲过，于是我就来钻研一下吧：

private static final class BlockingRunnable implements Runnable {
    private final Runnable mTask;
    private boolean mDone;

    public BlockingRunnable(Runnable task) {
        mTask = task;
    }

    @Override
    public void run() {
        try {
            mTask.run();
        } finally {
            synchronized (this) {
                mDone = true;
                notifyAll();
            }
        }
    }

    public boolean postAndWait(Handler handler, long timeout) {
        if (!handler.post(this)) {
            return false;
        }

        synchronized (this) {
            if (timeout > 0) {
                final long expirationTime = SystemClock.uptimeMillis() + timeout;
                while (!mDone) {
                    long delay = expirationTime - SystemClock.uptimeMillis();
                    if (delay <= 0) {
                        return false; // timeout
                    }
                    try {
                        wait(delay);
                    } catch (InterruptedException ex) {
                    }
                }
            } else {
                while (!mDone) {
                    try {
                        wait();
                    } catch (InterruptedException ex) {
                    }
                }
            }
        }
        return true;
    }
}

我们可以看到，BlockingRunnable是一个“包裹”构造方法中传入的Runnable的Runnable，调用BlockingRunnable的postAndWait会做以下事情：

1. 如果投递BlockingRunnable失败，返回false
2. 锁住投递BlockingRunnable的线程
3. 如果timeout大于0，计算参数Runnable的到期时间，只要参数Runnable还没处理完，则一直轮询还剩多少时间，并调用wait(delay)让投递BlockingRunnable的线程继续等待，直参数Runnable处理完（mDone为true）这个过程才结束
4. 如果timeout小于等于0，而且参数Runnable还没处理完，则一直等待直到参数Runnable处理完（mDone为true）

这个东西的说明书和使用风险可以在runWithScissors方法的注释里看到，我在这里就不当翻译工了。

消息的投递和处理

得到Message后，就会通过Handler的sendMessageAtTime调用MessageQueue的enqueueMessage将Message投递到MessageQueue中，在往下学习之前必须先了解Handler的创建，因为后面的知识和它有关联。

Handler的创建和初始化

其实Handler的初始化没什么好看的，就是保存Callback、mLooper的MessageQueue的引用，以及声明Handler是否异步投递所有Message。但是里面有一个内存泄露的检查，可以学习一下，就是如果打开了FIND_POTENTIAL_LEAKS，就会进行内存泄露的检查，它会做以下事情：

1. 获取当前Handler类
2. 如果Handler是匿名内部类，或成员类，或局部类，且Handler的修饰符不是static
3. 那么就会打出log提示可能会发生内存泄露

public Handler(Callback callback, boolean async) {
    if (FIND_POTENTIAL_LEAKS) {
        final Class 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;
}

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

既然Handler的创建这么简单，为什么说后面要学习的内容和它相关呢？原因就出在Looper中，我们可以看到Looper是通过sThreadLocal返回的，这个ThreadLocal是什么呢？

ThreadLocal - 维持线程内对象的唯一性

ThreadLocal是一个关于创建线程局部变量的类。

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。而使用ThreadLocal创建的变量只能被当前线程访问，其他线程则无法访问和修改。它的实现原理如下：

如图所示，ThreadLocalRef其实是同一个ThreadLocal对象的引用，为了不让线看起来很乱我分别用了两个方块表示ThreadLocal对象，但其实是同一个对象。ThreadLocal同时是ThreadA、ThreadB甚至ThreadN内ThreadLocalMap的Key，但取出来的对象时不一样的，因为Map不一样对应的键值对也不一样嘛。

ThreadLocalMap

ThreadLocalMap是仅用于维护ThreadLocal值的自定义HashMap，只在Thread类内使用。为了避免ThreadLocalMap的Key->ThreadLocal在GC时无法被回收，里边的元素都是用WeakReference封装的。ThreadLocalMap除了这点以外，没有什么特别的，就不细讲了。

需要注意的一点是：ThreadLocalMap是可能带来内存泄露的，但root cause不是ThreadLocalMap本身，而是代码质量不够高。首先，由于作为Map的Key的ThreadLocal是弱引用，那么GC时ThreadLocal会被回收，此时Map内存在一对Key为null的键值对，而Value仍然被线程强引用着，那么如果用完ThreadLocal后不主动移除，就会内存泄露了。但事实上，ThreadLocal用完后主动调remove就能规避这个问题，本来也该这样做。

Entry

Entry作为ThreadLocalMap的元素，表示的是一对键值对：ThreadLocal的弱引用为键，将要用ThreadLocal存储的对象为值。

static class Entry extends WeakReference {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal k, Object v) {
        super(k);
        value = v;
    }
}

ThreadLocal总结

换句话说，所谓的不可被其他线程修改的局部变量，表示的是：每个线程中都会维护一个ThreadLocalMap，里边以ThreadLocal为键，对应的局部变量为值，通过键值对来控制访问和数据的一致性，而不是通过锁来控制。

Looper

既然一个线程只有一个Looper，那么Looper里面有什么呢？从源码可以看到，Looper的构造方法是私有的，也就意味着获得Looper对象基本都是单例，这一点和线程<->Looper的一对一映射关系切合。

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

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

从Looper的成员变量我们可以知道Looper包含了以下东西：

• sMainLooper：应用主线程的Looper，创建其他线程的Looper时为null
• mQueue：Looper关联的MessageQueue
• mThread：Looper关联的线程
• sThreadLocal：线程局部变量的Key

从这可以知道，一个线程对应一个Looper，一个Looper对应一个MessageQueue

—————-分割线，接下来回到消息的投递结束的地方—————-

得到Message后，就会通过Handler的sendMessageAtTime调用MessageQueue的enqueueMessage将Message投递到MessageQueue中，在往下学习之前必须先了解Handler的创建，因为后面的知识和它有关联。

现在我们知道Message将要投递到哪里的MessageQueue里了，那么投递过去之后，消息是怎么被处理的呢？这代码很长，而且就是个进入队列的过程，我就不贴了，做了以下事情：

1. 合法性检查
2. 标记Message正在使用
3. 入列
4. 唤醒native的MessageQueue

在这里有个有意思的概念必须提一下，就是Barrier Message，它表示的是一种栅栏的概念，将它加入MessageQueue可以拦住所有执行时间在它之后的同步Message，异步Message则不受影响，遍历到就会处理，这种状况会持续到把Barrier Message移除。

提示：图里绿色代表Message可以被取出执行，红色表示无法被取出执行

它和Message的根本差别是，他没有target，即:没有处理该Message的Handler，但我们自己将Message的Handler设为null是没法加入MessageQueue的，必须调用postSyncBarrier方法：

boolean enqueueMessage(Message msg, long when) {
    if (msg.target == null) {
        throw new IllegalArgumentException("Message must have a target.");
    }
    ……
}

private int postSyncBarrier(long when) {
    // Enqueue a new sync barrier token.
    // We don't need to wake the queue because the purpose of a barrier is to stall it.
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.markInUse();
        msg.when = when;
        msg.arg1 = token;

        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

消息的分发

前面已经知道Message投递后就会到达MessageQueue，接下来就看消息是怎么被遍历处理的。首先要知道的一点是，Looper在调用prepare创建后，是必须调loop()方法的，很多人会问，我平常用的时候没用loop()方法也没问题啊。那是因为你是在主线程用的，主线程在创建Looper的时候已经调用过loop()方法了。

我们创建了其他线程的Looper后，调loop()方法会做以下事情：

1. 循环获取MessageQueue中的Message
2. 将Message通过Handler的dispatchMessage方法分发到对应的Handler中
3. 将Message的信息清空，回收到Message Pool中等待下一次使用

public static void loop() {
    ……

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

        ……

        try {
            msg.target.dispatchMessage(msg);
        } finally {
            ……
        }

        ……

        msg.recycleUnchecked();
    }
}

在Handler的dispatchMessage中，对Message的处理其实是有优先顺序这个说法的：

1. 如果Message设置了callback，则将Message交给Message的callback处理
2. 如果Handler设置了callback，则将Message先交给Handler的callback处理
3. 否则的话，将Message交给Handler的handleMessage处理

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

对于MessageQueue，它实际表示了Java层和Native层的MessageQueue，Java层的MessageQueue就是mMessages表示的循环队列，Native层的MessageQueue就是mPtr。它的next()方法里做的事情如下：

1. 调用nativePollOnce让native层的MessageQueue先处理Native层的Message，再处理Java层的Message，这个过程可能阻塞
2. 如果在按时序遍历MessageQueue的过程中发现了Barrier Message，即handler为空的Message，则跳过它后面的所有同步Message，只处理异步Message
3. 如果消息是延时消息，计算当前时间和目标时间的差值，休眠这个时间差后再去取这个Message
4. 如果消息不是延时消息，在Message Pool里标记该Message正在使用，并返回它

Java层Android消息机制的整个过程可以用下图概括：

有钻研过Java层代码的朋友肯定知道，Handler里面还有个用于跨进程Message通信的MessengerImpl，这个东西我就不在这里说了，因为它就是个简单的跨进程通信，和整个Handler、Looper、MessageQueue其实关系不大。

Android Native层消息机制

Android消息机制在Native层其实和Java层很相似，保留了Handler、Looper、MessageQueue的结构。但是Native层Message、Handler、MessageQueue的概念被弱化得很厉害，基本上只是个“空壳”，核心逻辑都在Looper里边了。

其他区别都不大了，只是在实现上有一点不一样，具体的差别就在源码中找答案吧。整体结构图如下：

消息的产生

在Native层中，消息由MessageEnvelope和封装fd（Java层Handler可以添加fd的监听、Native当然也可以）相关信息后得到的epoll_event组成。

fd

对于要被监听的fd的消息，Looper做了以下事情：

1. 合法性检查
2. 将相关信息封装到Request中，并初始化为epoll_event
3. 将该fd以及要监听的epoll_event事件（步骤2转换Request得到）注册到当前Looper的epollFd中
4. 如果出错，进行出错处理
5. 更新mRequests

int Looper::addFd(int fd, int ident, int events, const sp& callback, void* data) {
    ……

    { // acquire lock
        AutoMutex _l(mLock);

        ……

        struct epoll_event eventItem;
        request.initEventItem(&eventItem);

        ssize_t requestIndex = mRequests.indexOfKey(fd);
        if (requestIndex < 0) {
            int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
            ……
            mRequests.add(fd, request);
        } else {
            int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_MOD, fd, & eventItem);
            ……
            mRequests.replaceValueAt(requestIndex, request);
        }
    } // release lock
    return 1;
}

MessageEnvelope

MessageEnvelope相对于fd就简单多了，在调用Native层Looper的sendMessage相关函数时会将uptime、MessageHandler、Native层Message封装到MessageEnvelope中，然后插入mMessageEnvelopes中。

void Looper::sendMessageAtTime(nsecs_t uptime, const sp& handler, const Message& message) {
    ……
    size_t i = 0;
    { // acquire lock
        AutoMutex _l(mLock);

        size_t messageCount = mMessageEnvelopes.size();
        while (i < messageCount && uptime >= mMessageEnvelopes.itemAt(i).uptime) {
            i += 1;
        }

        MessageEnvelope messageEnvelope(uptime, handler, message);
        mMessageEnvelopes.insertAt(messageEnvelope, i, 1);

        ……
    }
    ……
}

消息的投递和处理

前面已经提到了，Java层的MessageQueue处理消息时，会先调用Native层MessageQueue的nativePollOnce()，它实际调用的是native层MessageQueue的pollOnce()，而native的pollOnce调用的是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);
    ……
}

在看Native层Looper的pollOnce方法之前，先看看Native层的Looper和Java层的Looper会不会有一些不一样吧。

Looper Native

和Java层Looper的使用一样，Native层Looper也需要prepare，也是一个通过线程局部变量存储的对象，一个线程只有一个。那么在Native层是怎么实现线程局部变量的呢？

Linux TSD(Thread-specific Data)池

Native层线程局部变量的思想和Java层很类似，Native层会维护一个全局的pthread_keys数组，用于存放线程局部变量的键。其中seq用于标记是否”in_use”，destr则是一个函数指针，可用作析构函数，在线程退出时释放该键对应于线程中的线程局部变量。

static struct pthread_key_struct pthread_keys[PTHREAD_KEYS_MAX] ={{0,NULL}};

int pthread_key_create(pthread_key_t *key, void (*destr_function) (void*));

struct pthread_key_struct
{
  /* Sequence numbers.  Even numbers indicated vacant entries.  Note
     that zero is even.  We use uintptr_t to not require padding on
     32- and 64-bit machines.  On 64-bit machines it helps to avoid
     wrapping, too.  */
  uintptr_t seq;

  /* Destructor for the data.  */
  void (*destr) (void *);
};

pthread在创建线程时会维护一个指针数组，数组元素指向线程局部变量的数据块。整体解构如下图：

创建Looper

创建Looper时，会做以下事情：

1. 通过eventfd创建mWakeEventFd用于线程间通信去唤醒Looper的，当需要唤醒Looper时，就往里面写1
2. 创建用于监听epoll_event的mEpollFd，并初始化mEpollFd要监听的epoll_event类型
3. 通过epoll_ctl将mWakeEventFd注册到mEpollFd中，当mWakeEventFd有事件可读则唤醒Looper
4. 如果mRequests不为空的话，说明前面注册了有要监听的fd，则遍历mRequests中的Request，将它初始化为epoll_event并通过epoll_ctl注册到mEpollFd中，当有可读事件同样唤醒Looper

Looper::Looper(bool allowNonCallbacks) :
        mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
        mPolling(false), mEpollFd(-1), mEpollRebuildRequired(false),
        mNextRequestSeq(0), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
    mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
    ……
    rebuildEpollLocked();
}

void Looper::rebuildEpollLocked() {
    ……

    // Allocate the new 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 = mWakeEventFd;
    int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);
    ……

    for (size_t i = 0; i < mRequests.size(); i++) {
        const Request& request = mRequests.valueAt(i);
        struct epoll_event eventItem;
        request.initEventItem(&eventItem);

        int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, request.fd, & eventItem);
        ……
    }
}

pollOnce

对于Native层Looper的pollOnce，找它函数定义稍微有点隐秘，它在Looper.h中声明，inline到pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData)函数里了，它做了以下事情：

1. 优先处理mResponses里的Response，即来自fd的事件
2. 如果没有需处理的Response，再调用pollInner

inline int pollOnce(int timeoutMillis) {
    return pollOnce(timeoutMillis, NULL, NULL, NULL);
}

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        while (mResponseIndex < mResponses.size()) {
            const Response& response = mResponses.itemAt(mResponseIndex++);
            int ident = response.request.ident;
            if (ident >= 0) {
                ……
                return ident;
            }
        }

        if (result != 0) {
#if DEBUG_POLL_AND_WAKE
            ALOGD("%p ~ pollOnce - returning result %d", this, result);
#endif
            ……
            return result;
        }

        result = pollInner(timeoutMillis);
    }
}

pollInner这个函数比较长，它做了以下事情：

1. 基于下一个Message调整获取Message的时间间隔timeoutMillis
2. 清空mResponses
3. 获取epoll事件，即将要处理的Message
4. 更新mPolling，防止进入idle
5. 执行合法性检查
6. 如果epoll_event的fd为mWakeFd，说明是Looper的唤醒事件，则唤醒Looper
7. 否则先将epoll_event封装为Request，更新epoll_event的事件类型，再封装为Response装入mResponses
8. 循环取出mMessageEnvelopes队头的MessageEnvelope，并将MessageEnvelope中的Message交给对应的Native层的Handler处理
9. 循环调用mResponses中所有Response的callback

至此对Android消息机制的学习就结束啦。

题外话

如果你觉得我的分享有帮助到你的话，请我吃个零食/喝杯咖啡呗~