本篇内容主要讲解“怎么掌握Handler消息机制”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么掌握Handler消息机制”吧!
Handler 的基本原理
子线程中怎么使用 Handler
MessageQueue 获取消息是怎么等待
为什么不用 wait 而用 epoll 呢？
线程和 Handler Looper MessageQueue 的关系
多个线程给 MessageQueue 发消息，如何保证线程安全
Handler 消息延迟是怎么处理的
View.post 和 Handler.post 的区别
Handler 导致的内存泄漏
非 UI 线程真的不能操作 View 吗
代码分析基于 Android SDK 28
大家可以先看上面的问题思考一下，如果都清楚的话，下面的文章也没必要看了～
关于 Handler 的原理，相比不用多说了，大家都应该知道，一张图就可以说明（图片来自网络）。
除了上面 Handler 的基本原理，子线程中如何使用 Handler 也是一个常见的问题。 子线程中使用 Handler 需要先执行两个操作：Looper.prepare 和 Looper.loop。 为什么需要这样做呢？Looper.prepare 和 Looper.loop 都做了什么事情呢？ 我们知道如果在子线程中直接创建一个 Handler 的话，会报如下的错误：
"Can't create handler inside thread xxx that has not called Looper.prepare()
我们可以看一下 Handler 的构造函数，里面会对 Looper 进行判断，如果通过 ThreadLocal 获取的 Looper 为空，则报上面的错误。
public Handler(Callback callback, boolean async) {
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread " + Thread.currentThread()
+ " that has not called Looper.prepare()");
}
}
public static @Nullable Looper myLooper() {
return sThreadLocal.get();
}那么 Looper.prepare 里做了什么事情呢？
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.prepare 就是创建了 Looper 并设置给 ThreadLocal，这里的一个细节是每个 Thread 只能有一个 Looper，否则也会抛出异常。 而 Looper.loop 就是开始读取 MessageQueue 中的消息，进行执行了。
这里一般会引申一个问题，就是主线程中为什么不用手动调用这两个方法呢？相信大家也都明白，就是 ActivityThread.main 中已经进行了调用。 通过这个问题，又可以引申到 ActivityThread 相关的知识，这里就不细说了。
上面说到 Looper.loop 其实就是开始读取 MessageQueue 中的消息了，那 MessageQueue 中没有消息的时候，Looper 在做什么呢？我们知道是在等待消息，那是怎么等待的呢？
通过 Looper.loop 方法，我们知道是 MessageQueue.next() 来获取消息的，如果没有消息，那就会阻塞在这里，MessageQueue.next 是怎么等待的呢？
public static void loop() {
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;
}
}
} Message next() {
for (;;) {
nativePollOnce(ptr, nextPollTimeoutMillis);
// ...
}
}在 MessageQueue.next 里调用了 native 方法 nativePollOnce。
// android_os_MessageQueue.cpp
static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jlong ptr, jint timeoutMillis) {
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}
void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
// ...
mLooper->pollOnce(timeoutMillis);
// ...
}
// Looper.cpp
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
// ...
result = pollInner(timeoutMillis);
// ...
}
int Looper::pollInner(int timeoutMillis) {
// ...
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
}从上面代码中我们可以看到，在 native 侧，最终是使用了 epoll_wait 来进行等待的。 这里的 epoll_wait 是 Linux 中 epoll 机制中的一环，关于 epoll 机制这里就不进行过多介绍了，大家有兴趣可以参考 https://segmentfault.com/a/1190000003063859
那其实说到这里，又有一个问题，为什么不用 java 中的 wait / notify 而是要用 native 的 epoll 机制呢？
说起来 java 中的 wait / notify 也能实现阻塞等待消息的功能，在 Android 2.2 及以前，也确实是这样做的。 可以参考这个 commit https://www.androidos.net.cn/android/2.1_r2.1p2/xref/frameworks/base/core/java/android/os/MessageQueue.java 那为什么后面要改成使用 epoll 呢？通过看 commit 记录，是需要处理 native 侧的事件，所以只使用 java 的 wait / notify 就不够用了。 具体的改动就是这个 commit https://android.googlesource.com/platform/frameworks/base/+/fa9e7c05c7be6891a6cf85a11dc635a6e6853078%5E%21/#F0
Sketch of Native input for MessageQueue / Looper / ViewRoot MessageQueue now uses a socket for internal signalling, and is prepared to also handle any number of event input pipes, once the plumbing is set up with ViewRoot / Looper to tell it about them as appropriate. Change-Id: If9eda174a6c26887dc51b12b14b390e724e73ab3
不过这里最开始使用的还是 select，后面才改成 epoll。 具体可见这个 commit https://android.googlesource.com/platform/frameworks/base/+/46b9ac0ae2162309774a7478cd9d4e578747bfc2%5E%21/#F16
至于 select 和 epoll 的区别，这里也不细说了，大家可以在上面的参考文章中一起看看。
这里的关系是一个线程对应一个 Looper 对应一个 MessageQueue 对应多个 Handler。
既然一个线程对应一个 MessageQueue，那多个线程给 MessageQueue 发消息时是如何保证线程安全的呢？ 说来简单，就是加了个锁而已。
// MessageQueue.java
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
// ...
}
}Handler 引申的另一个问题就是延迟消息在 Handler 中是怎么处理的？定时器还是其他方法？ 这里我们先从事件发起开始看起：
// Handler.java
public final boolean postDelayed(Runnable r, long delayMillis)
{
return sendMessageDelayed(getPostMessage(r), delayMillis);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
// 传入的 time 是 uptimeMillis + delayMillis
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
// ...
return enqueueMessage(queue, msg, uptimeMillis);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
// 调用 MessageQueue.enqueueMessage
return queue.enqueueMessage(msg, uptimeMillis);
}从上面的代码逻辑来看，Handler post 消息以后，一直调用到 MessageQueue.enqueueMessage 里，其中最重要的一步操作就是传入的时间是 uptimeMillis + delayMillis。
boolean enqueueMessage(Message msg, long when) {
synchronized (this) {
// ...
msg.when = when;
Message p = mMessages; // 下一条消息
// 根据 when 进行顺序排序，将消息插入到其中
if (p == null || when == 0 || when < p.when) {
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
// 找到 合适的节点
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
}
// 插入操作
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// 唤醒队列进行取消息
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}通过上面代码我们看到，post 一个延迟消息时，在 MessageQueue 中会根据 when 的时长进行一个顺序排序。 接着我们再看看怎么使用 when 的。
Message next() {
// ...
for (;;) {
// 通过 epoll_wait 等待消息，等待 nextPollTimeoutMillis 时长
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
// 当前时间
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
Message msg = mMessages;
if (msg != null && msg.target == null) {
// 获得一个有效的消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) { // 说明需要延迟执行，通过； nativePollOnce 的 timeout 来进行延迟
// 获取需要等待执行的时间
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;
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
// 当前没有消息要执行，则执行 IdleHandler 中的内容
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// 如果没有 IdleHandler 需要执行，则去等待 消息的执行
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// 执行 idle handlers 内容
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;
// 如果执行了 idle handlers 的内容，现在消息可能已经到了执行时间，所以这个时候就不等待了，再去检查一下消息是否可以执行， nextPollTimeoutMillis 需要置为 0
nextPollTimeoutMillis = 0;
}
}通过上面的代码分析，我们知道了执行 Handler.postDelayd 时候，会执行下面几个步骤：
将我们传入的延迟时间转化成距离开机时间的毫秒数
MessageQueue 中根据上一步转化的时间进行顺序排序
在 MessageQueue.next 获取消息时，对比当前时间（now）和第一步转化的时间（when），如果 now < when，则通过 epoll_wait 的 timeout 进行等待
如果该消息需要等待，会进行 idel handlers 的执行，执行完以后会再去检查此消息是否可以执行
我们最常用的 Handler 功能就是 Handler.post，除此之外，还有 View.post 也经常会用到，那么这两个有什么区别呢？ 我们先看下 View.post 的代码。
// View.java
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
// Postpone the runnable until we know on which thread it needs to run.
// Assume that the runnable will be successfully placed after attach.
getRunQueue().post(action);
return true;
}通过代码来看，如果 AttachInfo 不为空，则通过 handler 去执行，如果 handler 为空，则通过 RunQueue 去执行。 那我们先看看这里的 AttachInfo 是什么。 这个就需要追溯到 ViewRootImpl 的流程里了，我们先看下面这段代码。
// ViewRootImpl.java
final ViewRootHandler mHandler = new ViewRootHandler();
public ViewRootImpl(Context context, Display display) {
// ...
mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,
context);
}
private void performTraversals() {
final View host = mView;
// ...
if (mFirst) {
host.dispatchAttachedToWindow(mAttachInfo, 0);
mFirst = false;
}
// ...
}代码写了一些关键部分，在 ViewRootImpl 构造函数里，创建了 mAttachInfo，然后在 performTraversals 里，如果 mFirst 为 true，则调用 host.dispatchAttachedToWindow，这里的 host 就是 DecorView，如果有读者朋友对这里不太清楚，可以看看前面【面试官带你学安卓-从View的绘制流程】说起这篇文章复习一下。
这里还有一个知识点就是 mAttachInfo 中的 mHandler 其实是 ViewRootImpl 内部的 ViewRootHandler。
然后就调用到了 DecorView.dispatchAttachedToWindow，其实就是 ViewGroup 的 dispatchAttachedToWindow，一般 ViewGroup 中相关的方法，都是去依次调用 child 的对应方法，这个也不例外，依次调用子 View 的 dispatchAttachedToWindow，把 AttachInfo 传进去，在 子 View 中给 mAttachInfo 赋值。
// ViewGroup
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mGroupFlags |= FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;
super.dispatchAttachedToWindow(info, visibility);
mGroupFlags &= ~FLAG_PREVENT_DISPATCH_ATTACHED_TO_WINDOW;
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
final View child = children[i];
child.dispatchAttachedToWindow(info,
combineVisibility(visibility, child.getVisibility()));
}
final int transientCount = mTransientIndices == null ? 0 : mTransientIndices.size();
for (int i = 0; i < transientCount; ++i) {
View view = mTransientViews.get(i);
view.dispatchAttachedToWindow(info,
combineVisibility(visibility, view.getVisibility()));
}
}
// View
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
// ...
}看到这里，大家可能忘记我们开始刚刚要做什么了。
我们是在看 View.post 的流程，再回顾一下 View.post 的代码：
// View.java
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
getRunQueue().post(action);
return true;
}现在我们知道 attachInfo 是什么了，是 ViewRootImpl 首次触发 performTraversals 传进来的，也就是触发 performTraversals 之后，View.post 都是通过 ViewRootImpl 内部的 Handler 进行处理的。
如果在 performTraversals 之前或者 mAttachInfo 置为空以后进行执行，则通过 RunQueue 进行处理。
那我们再看看 getRunQueue().post(action); 做了些什么事情。
这里的 RunQueue 其实是 HandlerActionQueue。
HandlerActionQueue 的代码看一下。
public class HandlerActionQueue {
public void post(Runnable action) {
postDelayed(action, 0);
}
public void postDelayed(Runnable action, long delayMillis) {
final HandlerAction handlerAction = new HandlerAction(action, delayMillis);
synchronized (this) {
if (mActions == null) {
mActions = new HandlerAction[4];
}
mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
mCount++;
}
}
public void executeActions(Handler handler) {
synchronized (this) {
final HandlerAction[] actions = mActions;
for (int i = 0, count = mCount; i < count; i++) {
final HandlerAction handlerAction = actions[i];
handler.postDelayed(handlerAction.action, handlerAction.delay);
}
mActions = null;
mCount = 0;
}
}
}通过上面的代码我们可以看到，执行 getRunQueue().post(action); 其实是将代码添加到 mActions 进行保存，然后在 executeActions 的时候进行执行。
executeActions 执行的时机只有一个，就是在 dispatchAttachedToWindow(AttachInfo info, int visibility) 里面调用的。
void dispatchAttachedToWindow(AttachInfo info, int visibility) {
mAttachInfo = info;
if (mRunQueue != null) {
mRunQueue.executeActions(info.mHandler);
mRunQueue = null;
}
}看到这里我们就知道了，View.post 和 Handler.post 的区别就是：
如果在 performTraversals 前调用 View.post，则会将消息进行保存，之后在 dispatchAttachedToWindow 的时候通过 ViewRootImpl 中的 Handler 进行调用。
如果在 performTraversals 以后调用 View.post，则直接通过 ViewRootImpl 中的 Handler 进行调用。
这里我们又可以回答一个问题了，就是为什么 View.post 里可以拿到 View 的宽高信息呢？ 因为 View.post 的 Runnable 执行的时候，已经执行过 performTraversals 了，也就是 View 的 measure layout draw 方法都执行过了，自然可以获取到 View 的宽高信息了。
这个问题就是老生常谈了，可以由此再引申出内存泄漏的知识点，比如：如何排查内存泄漏，如何避免内存泄漏等等。
我们使用 Handler 最多的一个场景就是在非主线程通过 Handler 去操作 主线程的 View。 那么非 UI 线程真的不能操作 View 吗？ 我们在执行 UI 操作的时候，都会调用到 ViewRootImpl 里，以 requestLayout 为例，在 requestLayout 里会通过 checkThread 进行线程的检查。
// ViewRootImpl.java
public ViewRootImpl(Context context, Display display) {
mThread = Thread.currentThread();
}
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}我们看这里的检查，其实并不是检查主线程，是检查 mThread != Thread.currentThread，而 mThread 指的是 ViewRootImpl 创建的线程。 所以非 UI 线程确实不能操作 View，但是检查的是创建的线程是否是当前线程，因为 ViewRootImpl 创建是在主线程创建的，所以在非主线程操作 UI 过不了这里的检查。
一个小小的 Handler，其实可以引申出很多问题，这里这是列举了一些大家可能忽略的问题，更多的问题就等待大家去探索了～ 这里来总结一下：
一张图解释（图片来自网络） 
Looper.prepare 创建 Looper 并添加到 ThreadLocal 中
Looper.loop 启动 Looper 的循环
通过 epoll 机制进行等待和唤醒。
在 Android 2.2 及之前，使用 Java wait / notify 进行等待，在 2.3 以后，使用 epoll 机制，为了可以同时处理 native 侧的消息。
一个线程对应一个 Looper 对应一个 MessageQueue 对应多个 Handler。
通过对 MessageQueue 加锁来保证线程安全。
将传入的延迟时间转化成距离开机时间的毫秒数
MessageQueue 中根据上一步转化的时间进行顺序排序
在 MessageQueue.next 获取消息时，对比当前时间（now）和第一步转化的时间（when），如果 now < when，则通过 epoll_wait 的 timeout 进行等待
如果该消息需要等待，会进行 idel handlers 的执行，执行完以后会再去检查此消息是否可以执行
View.post 最终也是通过 Handler.post 来执行消息的，执行过程如下：
如果在 performTraversals 前调用 View.post，则会将消息进行保存，之后在 dispatchAttachedToWindow 的时候通过 ViewRootImpl 中的 Handler 进行调用。
如果在 performTraversals 以后调用 View.post，则直接通过 ViewRootImpl 中的 Handler 进行调用。
略过不讲～
不能操作，原因是 ViewRootImpl 会检查创建 ViewRootImpl 的线程和当前操作的线程是否一致。而 ViewRootImpl 是在主线程创建的，所以非主线程不能操作 View。
到此，相信大家对“怎么掌握Handler消息机制”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
