Android Handler 通信 - 彻底了解 Handler 的通信过程

相关源码文件：

/frameworks/base/core/java/android/os/Handler.java
/frameworks/base/core/java/android/os/MessageQueue.java
/frameworks/base/core/java/android/os/Looper.java

framework/base/core/jni/android_os_MessageQueue.cpp
system/core/libutils/Looper.cpp
system/core/include/utils/Looper.h

在 Android 应用开发过程中，跨进程通信一般是 binder 驱动，关于 binder 驱动的源码分析，大家感兴趣可以看看我之前的一些文章。这里我们来聊聊线程间的通信 Handler，关于 handler 的通信原理我想大家应该都是倒背如流。但有一些比较细节的东西大家可能就未必了解了：

基于 Handler 可以做性能检测
基于 Handler 可以做性能优化
基于 Handler 竟然也可以做跨进程通信？

关于 Handler 的基础原理篇，大家有不了解的可以看看《Android Handler 通信 - 源码分析与手写 Handler 框架》，本文这里我们先来分析一下 Handler 是怎么处理消息延迟的，这是我在头条面试碰到的一个题目。首先我们先自己思考一下：如果我们要延迟 2s 再去处理这个消息，自己实现会怎样去处理？（思考五分钟）我们一起来看看源码：

// MessageQueue.java 中的 next 方法源码
Message next() {
        // 判断 native 层的 MessageQueue 对象有没有正常创建
        final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }
        // 消息执行需要等待的时间
        int nextPollTimeoutMillis = 0;
        for (;;) {
            // 执行 native 层的消息延迟等待，调 next 方法第一次不会进来
            nativePollOnce(ptr, nextPollTimeoutMillis);
            synchronized (this) {
                // 获取当前系统的时间
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
                ...
                if (msg != null) {
                    if (now < msg.when) {
                        // 需要延迟， 计算延迟时间
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // 不需要延迟获取已经过了时间，立马返回
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        // 标记为已在使用状态
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // 如果队列里面没有消息，等待时间是 -1
                    nextPollTimeoutMillis = -1;
                }
                // 有没有空闲的 IdleHandler 需要执行，一般我们没关注这个功能
                // 后面内容有专门解释，这里目前分析是 == 0 ，跳出
                if (pendingIdleHandlerCount <= 0) {
                    mBlocked = true;
                    continue;
                }
                ...
            }
            pendingIdleHandlerCount = 0;
            nextPollTimeoutMillis = 0;
        }
    }

通过源码分析我们发现消息的处理过程，是通过当前消息的执行时间与当前系统时间做比较，如果小于等于当前系统时间则立即返回执行该消息，如果大于当前系统时间则调用 nativePollOnce 方法去延迟等待被唤醒，当消息队列里面为空时则设置等待的时间为 -1。关于 IdleHandler 、异步消息和消息屏障的源码已被我忽略，大家待会可以看文章后面的分析。我们跟进到 Native 层的 android_os_MessageQueue_nativePollOnce 方法。

static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
        jlong ptr, jint timeoutMillis) {
    // 通地址转换成 native 层的 MessageQueue 对象
    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
    nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}

void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
    // 调用 native 层 Looper 对象的 pollOnce 方法
    mLooper->pollOnce(timeoutMillis);
}

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

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        ...
        if (result != 0) {
            ...
            return result;
        }
        // 再处理内部轮询
        result = pollInner(timeoutMillis); 【6】
    }
}

int Looper::pollInner(int timeoutMillis) {
    ...
    int result = POLL_WAKE;
    mResponses.clear();
    mResponseIndex = 0;
    mPolling = true; //即将处于idle状态
    // fd最大个数为16
    struct epoll_event eventItems[EPOLL_MAX_EVENTS]; 
    // 等待事件发生或者超时，在 nativeWake() 方法，向管道写端写入字符，则该方法会返回；
    int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
    ...
    return result;
}

通过源码分析我们能发现 Looper.loop() 方法并不是一个死循环那么简单，如果真是一个简单的死循环那得多耗性能，其实 native 层是调用 epoll_wait 进入等待的，timeoutMillis 这里有三种情况分别为：0 ，-1 和 >0 。如果是 -1 那么该方法会一直进入等待，如果是 0 那么该方法会立即返回，如果是 >0 该方法到等待时间就会立即返回，关于 epoll_wait 的使用和原理介绍，大家可以看看之前的内容。接下来我们看看唤醒方法：

boolean enqueueMessage(Message msg, long when) {
  ...
  synchronized (this) {
    if (mQuitting) {
      ...
      // We can assume mPtr != 0 because mQuitting is false.
      // 如果需要唤醒，调用 nativeWake 方法唤醒
      if (needWake) {
        nativeWake(mPtr);
      }
    }
    return true;
}

void NativeMessageQueue::wake() {
    mLooper->wake();
}

void Looper::wake() {
    uint64_t inc = 1;
    // 向管道 mWakeEventFd 写入字符1 , 写入失败仍然不断执行
    ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
    if (nWrite != sizeof(uint64_t)) {
        if (errno != EAGAIN) {
            ALOGW("Could not write wake signal, errno=%d", errno);
        }
    }
}

我们来总结一下延迟消息的处理过程：首先我们在 native 层其实也有 Handler.cpp 、MessageQueue.cpp 和 Looper.cpp 对象，但他们并不是与 Java 层一一对应的，只有 MessageQueue.java 和 MessageQueue.cpp 有关联。当我们上层计算好延迟时间后调用 native 层 nativePollOnce 方法，其内部实现采用 epoll 来处理延迟等待返回（6.0版本）。

当有新的消息插入时会调用 native 层的 nativeWake 方法，这个方法很简单就是向文件描述符中写入一个最简单的 int 数据 -1，目的是为了唤醒之前的 epoll_wait 方法，其实也就是唤醒 nativePollOnce 的等待。关于 Handler.cpp 、MessageQueue.cpp 和 Looper.cpp 对象，如果大家感兴趣可以看看之前的文章。

由此可见大公司的一个简单面试题就能过滤到很多人，我以前也经常听到同学抱怨，你为什么要问我这些问题，开发中又用不上。那么接下带大家来看看开发中能用上的，但我们可能并不熟悉的一些源码细节。

IdleHandler

我们在实际的开发过程中为了不阻塞主线程的其它任务执行，可能要等主线程空闲下来再去执行某个特定的方法，比如我们写了一个性能监测的工具，触发了某些条件要不定时的去收集某些信息，这个肯定是不能去影响主线程的，否则我们发现加了某些性能监测工具，反而会引起整个应用性能更差甚至引起卡顿。那如何才能知道主线程是否空闲了？

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
  @Override
  public boolean queueIdle() {
    // 开始执行一些其它操作，可能不耗时也可能稍微耗时
    // 比如跨进程访问，比如查询数据库，比如收集某些信息，比如写日志等等
    return false;
  }
});

这个代码很简单，只是我们平时可能比较少接触，我们来看看源码：

public void addIdleHandler(@NonNull IdleHandler handler) {
  if (handler == null) {
    throw new NullPointerException("Can't add a null IdleHandler");
  }
  synchronized (this) {
    mIdleHandlers.add(handler);
  }
}

Message next() {
        int pendingIdleHandlerCount = -1; // -1 only during first iteration

        for (;;) {
            synchronized (this) {
                //  目前这里分析有内容
                if (mPendingIdleHandlers == null) {
                    mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
                }
                mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
            }

            // 循环遍历所有的 IdleHandler 回调
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; // release the reference to the handler
                // 回调执行 queueIdle 方法
                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }
                // 执行完函数返回是不是需要空闲时一直回调
                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            pendingIdleHandlerCount = 0;
            nextPollTimeoutMillis = 0;
        }
    }

主线程方法耗时

在实际的应用开发过程中，我们可能会发现界面会有卡顿的问题，尤其是在一些复杂的场景下，比如直播间各种礼物动画效果或者复杂列表滑动等等，当然引起卡顿的原因会有很多，比如机型的不同，在我们的手机上丝丝般顺滑，在测试的手机上却像没吃饭一样，当然还与 cpu 使用率、主线程执行耗时操作和磁盘 I/O 操作等等都有关。实际过程中要排查卡顿其实是比较复杂的，这里我们主要来监听排查是不是主线程有方法耗时：

    @Override
    public void onCreate() {
        super.onCreate();
        Looper.getMainLooper().setMessageLogging(new Printer() {
            long currentTime = -1;

            @Override
            public void println(String x) {
                if (x.contains(">>>>> Dispatching to ")) {
                    currentTime = System.currentTimeMillis();
                } else if (x.contains("<<<<< Finished to ")) {
                    long executeTime = System.currentTimeMillis() - currentTime;
                    // 原则上是 16 毫秒，一般没办法做到这么严格
                    if (executeTime > 60) {
                        Log.e("TAG", "主线程出现方法耗时");
                    }
                }
            }
        });
    }

当然这么做只能监测到主线程有方法耗时而引起卡顿，可能目前这些代码无法跟踪到是哪个方法耗时引起的卡顿，但基于这些代码去实现是哪个方法引起的耗时应该是 soeasy ，这里我们先不做过多的延伸主要来看下原理：

    /**
     * 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();
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        final MessageQueue queue = me.mQueue;

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
            // 在执行方法之前做打印
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }
            // 执行消息的分发
            try {
                msg.target.dispatchMessage(msg);
                end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }
            // 执行方法之后再做打印
            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }
            ...
        }
    }

原理其实是非常简单的，关于异步消息、消息屏障、跨进程通信以及监听具体的某个方法耗时，在后面的源码分析中会陆陆续续的提到，大家感兴趣可以持续关注。国庆快乐～

视频地址：pan.baidu.com/s/1fLq65bUn…

视频密码：gkpv