Android进阶之路|Android 面试准备进行曲-Handler源码/面试题 android|移动开发|安卓

前言关于Google 建议在主线程中更新UI （其实子线程也可以更新UI,但是不推荐）多线程同步更新UI ，容易使UI进入不可预测的状态。将工作线程中需更新UI的操作信息传递到 UI主线程，从而实现工作线程对UI的更新绘制等处理，最终实现异步消息的处理。(保证多线程安全数据更新的顺序性)
Handler 流程
文章图片

上图已经比较清晰地讲述了整个handler的过程其中牵扯到比较重要的类有：

处理器类（Handler）
消息队列类（MessageQueue）
循环器类（Looper）

三个对象直接的关系
Handler -> Handler.sendMessage() / post（） -> MessageQueue -> MessageQueue.next() -> Looper -> Looper.prepare() -> Looper.loop() -> handlerMessage() 回到Handler中。关于MessageQueue先说明一点，该队列的实现既非Collection的子类，亦非Map的子类，而是Message本身。因为Message本身就是链表节点。
流程源码这里主要讲述三个对象整个流程的源码分析，顺带说一些面试题的点
Handler 初始化

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()); } } // 内部通过 ThreadLocal.get() 获取的唯一的loop对象 mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread " + Thread.currentThread() + " that has not called Looper.prepare()"); } // 获取该Looper对象中保存的消息队列对象（MessageQueue） mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }

上述代码为Handler中的构造方法部分,mLooper = Looper.myLooper() 通过ThreadLocal.get() 获取到 Loop对象中的Loop存储对象，这里也就保证了一个线程可以有多个Handler ，一个Handler 只能绑定一个Looper。有get（）方法了我们就找一下在那个地方set进去的。接下来我们进入Looper 源码部分。
Looper 初始化

// quitAllowed 参数为 MessageQueue 是否可以quit 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)); }public static void prepareMainLooper() { prepare(false); synchronized (Looper.class) { if (sMainLooper != null) { throw new IllegalStateException("The main Looper has already been prepared."); } sMainLooper = myLooper(); } }private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread(); }

通过上述代码在 prepare（）中为sThreadLocal 传入新的Looper 对象，Looper（）中创建了 messageQueue ，获取当前线程的对象。所以一个线程可以有多个Handler ，一个Handler 只能绑定一个 Looper ，一个Looper 中有一个MessageQueus （好他瞄的绕但是面试官真的这样问过我），通过反推我们可以给面试官讲述 Handler Looper MessageQueus 之间的创建声明关系。
prepareMainLooper（）对应着创建主线程时，会自动调用ActivityThread的1个静态的main（）；而main（）内则会调用Looper.prepareMainLooper()为主线程生成1个Looper对象，同时也会生成其对应的MessageQueue对象，这也就是我们为何不用再 OnCreate 的时候设置Looper.prepare() 。
Handler 发送消息
sendMessage() / postMessage() 发送消息，post() 则是实现一个 Runable 不需要外部创建消息对象。

public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis); } // 跳转到sendMessageAtTime public boolean sendMessageAtTime(Message msg, long uptimeMillis) { MessageQueue queue = mQueue; if (queue == null) { RuntimeException e = new RuntimeException( this + " sendMessageAtTime() called with no mQueue"); return false; } return enqueueMessage(queue, msg, uptimeMillis); } //跳转到 enqueueMessage(queue, msg, uptimeMillis) private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }

核心代码就可以看到 queue.enqueueMessage() 方法，我们来看一下源码

// enqueueMessage核心办法Message p = mMessages; if (p == null || when == 0 || when < p.when) { // 如果Message队列为空的则将信息添加到头部 msg.next = p; mMessages = msg; } else { ... Message prev; for (; ; ) { // 通过 prev = p、 p.next 递归链表比对when prev = p; p = p.next; if (p == null || when < p.when) { break; } ... } msg.next = p; // invariant: p == prev.next prev.next = msg; }

Message 通过 next 来将Message 本身当做节点拼接为单链表，when 代表的就是 Message 触发的时间，所以循环比对时间如果触发 when < p.when，则退出循环进行插入 p 的操作。
Looper.loop -> MessageQueue.next
消息循环，即从消息队列中获取消息、分发消息到Handler 。下为部分核心源码

public static void loop() {// 1. 获取当前Looper的消息队列 final Looper me = myLooper(); if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } // myLooper()作用：返回sThreadLocal存储的Looper实例 final MessageQueue queue = me.mQueue; for (; ; ) {// 从消息队列中取出消息 Message msg = queue.next(); if (msg == null) { return; } // next()：取出消息队列里的消息 // 若取出的消息为空，则线程阻塞 // 派发消息到对应的Handler msg.target.dispatchMessage(msg); // 把消息Message派发给消息对象msg的target属性 // target属性实际是1个handler对象 msg.recycleUnchecked(); } }

通过 Looper 获取到 MessageQueue ，然后从 queue 中取出消息，然后回调 msg中的 target 走dispatchMessage方法回调到我们的主线程的Handler 的 handlermessage () 方法中，然后在调用recycleUnchecked方法将 msg 标识和 next 等标记设置为初始值。
下边我们进入 MessageQueue.next() / dispatchMessage(msg) 看看源码

Message next() { // 该参数用于确定消息队列中是否还有消息 // 从而决定消息队列应处于出队消息状态 / 等待状态 int nextPollTimeoutMillis = 0; for (; ; ) { if (nextPollTimeoutMillis != 0) { Binder.flushPendingCommands(); }// nativePollOnce方法在native层，若是nextPollTimeoutMillis为-1，此时消息队列处于等待状态　 nativePollOnce(ptr, nextPollTimeoutMillis); synchronized (this) {final long now = SystemClock.uptimeMillis(); Message prevMsg = null; Message msg = mMessages; // 出队消息，从消息队列中取出消息：按创建Message对象的时间顺序 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 { // 若消息队列中已无消息，则将nextPollTimeoutMillis参数设为-1 // 下次循环时，消息队列则处于等待状态 nextPollTimeoutMillis = -1; } ...... } ..... } }

上述代码主要功能都有注释表明了，通过 Looper.loop 到 msgQueue.next 循环队列，获取有用的消息进行出列操作，没有消息就更新标识，阻塞循环。上文的 msg.target.dispatchMessage(msg); 其实target 就是Handler 对象我们通过跟踪找到 dispatchMessage 源码
Handler 消息处理源码

public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); } }public interface Callback { /** * @param msg A {@link android.os.Message Message} object * @return True if no further handling is desired */ public boolean handleMessage(Message msg); }// 我们必须实现的子类方法 public void handleMessage(Message msg) { }

在进行消息分发时dispatchMessage(msg)，会进行1次发送方式的判断：若msg.callback属性不为空，则代表使用了post（Runnable r）发送消息，则直接回调Runnable对象里复写的run（）若msg.callback属性为空，则代表使用了sendMessage（Message msg）发送消息，则回调复写的handleMessage(msg)
面试题 Message 创建回收链表关系
【Android进阶之路|Android 面试准备进行曲-Handler源码/面试题】这里分享一个有图有源码自我感觉不错的博客 Message中obtain()与recycle()的来龙去脉
MessageQueue 创建的时间
上文Looper 在创建的时候有源码 messageQueue 是和Looper 一块创建的
ThreadLocal在Handler机制中的作用
sThreadLocal是一个ThreadLocal对象，可以在一个线程中存储变量。上文 Looper.prepare() 源码出可以看到从中get到一个 Looper对象，sThreadLocal存储的就是Looper 对象。也就说明了一个handler 对应一个Looper 。
Looper,Handler,MessageQueue的引用关系?
这里直接引用上文写的：“ Handler -> Handler.sendMessage() / post（） -> MessageQueue -> MessageQueue.next() -> Looper -> Looper.prepare() -> Looper.loop() -> handlerMessage() 回到Handler中“ 。
Handler post 和 sendMessage 区别

public final boolean post(Runnable r) { returnsendMessageDelayed(getPostMessage(r), 0); }

查看post源码里边其实还是走的SendMessage ，不过 post方法对 msg的callback和target都有赋值，上文提到的Handler.dispatchMessage 方法中有提到这两种方法有一个区分反馈处理。
Handler导致内存泄露问题?
这个问题在三年工作经验以后稳得比较少，主要考察生命周期和gc的问题。因为匿名内部类 Handler 中包含外部对象也就是Activity对象，如果界面销毁但是后边的Queue还在消息没有处理，就有可能造成内存泄漏。
简单的处理方法：

static class MyHandler extends Handler { // 弱引用 Avtivity WeakReference mActivityReference; // 如果界面销毁 handler 交给 gc自己清理 MyHandler(Activity activity) { mActivityReference= new WeakReference(activity); } @Override public void handleMessage(Message msg) { final Activity activity = mActivityReference.get(); if (activity != null) { mImageView.setImageBitmap(mBitmap); } } }

有了解过 Handler的同步屏障机制么？
这一点说实话有点冷门但是也可以看出你对源码的解读是否深刻，（我也是从朋友强哥哪里听来的 360大佬牛逼）在说同步屏障的前提，我们需要先说 Message 可以添加同步消息和消息

public Handler(Looper looper, Callback callback, boolean async) { mLooper = looper; mQueue = looper.mQueue; mCallback = callback; mAsynchronous = async; }

上述代码的 async 布尔值便是同步和异步的标识

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }

在加入 Message 的时候调用msg.setAsynchronous(true)
同步屏障就是为了区分MessageQueue中的message的优先级的。通过打开同步屏障可以在 looper循环的时候使异步消息优先处理并返回。我们通过源码看看：

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 的tager其实为null ,我们重新贴一下 Looper.loop () 看下源码怎么处理的

Message next() { 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 (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 handlerboolean 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取到一个target为null的Message是，会先执行异步消息，已达到后添加进去的消息，先处理通过所谓的同步屏障达到修改链表顺序处理的机制。
主线程Looper.loop 为何不会卡死
由于这个问题其实我自己当时也不是很明白给出参考文章这个问题涵盖面就有点多了，不光要说 Handler 还有说 linux epoll机制. 为了可以让App一直运行，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder线程也是采用死循环的方法，通过循环方式不同与Binder驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，详情见Android消息机制1-Handler(Java层)，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。关于更加详细的和本片文章Handler沾边比较少的，则可以异步链接地址观看 Git yuan大佬的详细解读。
Message 复用机制
在Loop.looper 中我们就可以初探原因。

// Loop 类for (; ; ) { Message msg = queue.next(); // might block ... // This must be in a local variable, in case a UI event sets the logger final Printer logging = me.mLogging; ...try { // 消息分发 target 其实指的 Handler （这里也是 Handler sendMsg 和 post 方法的区别所在） msg.target.dispatchMessage(msg); dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; } finally { if (traceTag != 0) { Trace.traceEnd(traceTag); } } ...final long newIdent = Binder.clearCallingIdentity(); // 回收方法我们重点看一下这个方法 msg.recycleUnchecked(); }// Message 类void recycleUnchecked() { // 改变标记加入消息池中并重置所有状态 flags = FLAG_IN_USE; what = 0; arg1 = 0; arg2 = 0; obj = null; replyTo = null; sendingUid = -1; when = 0; target = null; callback = null; data = https://www.it610.com/article/null; synchronized (sPoolSync) { if (sPoolSize < MAX_POOL_SIZE) { // 头节点设置给Next 将当前对象最为最新的头节点sPool next = sPool; sPool = this; sPoolSize++; } } }

我们还要看下关于 Message .obtain() 中如何处理的

// 部分需要标注的对象 public static final Object sPoolSync = new Object(); private static Message sPool; private static int sPoolSize = 0; private static final int MAX_POOL_SIZE = 50; // 消息回首复用主要方法 public static Message obtain() { synchronized (sPoolSync) { //判断头节点是否null if (sPool != null) { // 取出头结点并将下一个消息设置为头结点 Message m = sPool; sPool = m.next; m.next = null; m.flags = 0; // clear in-use flag sPoolSize--; return m; } } // 如果消息链表为null 则返回新msg return new Message(); }

Message通过静态单链表来全局完成消息的复用，而在每次回收的过程中消息数据重置防止Message持有其他对象而造成内存泄漏操作，所有在日常开发开发中尽量使用Mesaage.obtain 来获取Message。
MessageQueue.removeMessages中的操作
这一部分也是朋友鱼总问我的，答不上来进行了一次百度，并附上参考文章地址：MessageQueue.removeMessages中的操作
Handler.post
Handler.sendmsg 和 Handler.post 两种方式不同的是post方法只需要完成 runable 方法实现就好，他底层就做了什么操作呢？

// handler.class public final boolean post(Runnable r) { returnsendMessageDelayed(getPostMessage(r), 0); }private static Message getPostMessage(Runnable r) { Message m = Message.obtain(); // 对msg的 callback 进行赋值 m.callback = r; return m; }//在Loop.loop 中对消息进行的分发代码中对msg的callback进行分类处理。public void dispatchMessage(Message msg) { if (msg.callback != null) {// 回调 post 方法中的 runable 方法 handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } }// 回到到 handler 的 handleMessage 方法中 handleMessage(msg); } }

部分讲解都在代码的注释中了。大体handler 本人学习和部分面试题总结大概就这些了。后续还会持续维护更新。