Android 面试准备进行曲（Handler源码/面试题）v

作者: _明川 | 来源:发表于2019-12-19 15:26 被阅读0次

前言
Handler 流程
流程源码
面试题

本博客为本人学习 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<Looper>.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<Looper>.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 本人学习和部分面试题总结大概就这些了。后续还会持续维护更新。

Android 面试准备进行曲（Handler源码/面试题）v

前言

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中的操作

Handler.post

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android面试相关

Android 面试准备进行曲 （Handler源码/面试题）v

前言

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中的操作

Handler.post

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android面试相关

Android 面试准备进行曲（Handler源码/面试题）v

Message 创建回收链表关系