Android 面试准备进行曲 （Handler源码/面试题）v1.3

• 前言
• Handler 流程
• 流程源码
  • Handler 初始化
  • Looper 初始化
  • Handler 发送消息
  • Looper.loop -> MessageQueue.next
  • Handler 消息处理源码
• 面试题
  • Message 创建回收 链表关系
  • MessageQueue 创建的时间
  • ThreadLocal在Handler机制中的作用
  • Looper,Handler,MessageQueue的引用关系?
  • Handler post 和 sendMessage 区别
  • Handler导致内存泄露问题?
  • 有了解过 Handler的同步屏障机制么？
  • 主线程Looper.loop 为何不会卡死
  • Message 复用机制
  • [MessageQueue.removeMessages中的操作](#messagequeueremovemessages中的操作)
  • Handler.post

本博客为本人学习 Handler 中的笔记，可能文笔方面欠妥，该文中本人会描述主要源码和部分经典面试题答案的源码解读。阅读时间：20分钟+ 本文源码版本 android SDK 28

update time ： 2019年12月30日19:01:22
v1.2 ： 添加面试题（message复用 和 Handler.post 的流程）
v1.3 : 修改个人本身对 MessageQueue 理解错误，重点修改 Message 单链表对应的知识点

前言

关于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<? extends Handler> 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 创建回收 链表关系

这里分享一个 有图 有源码 自我感觉不错的博客
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)
    {
       return  sendMessageDelayed(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 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;
            // 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 = 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)
    {
       return  sendMessageDelayed(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 本人学习和部分面试题总结 大概就这些了。后续还会持续维护更新。