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

转载图片原文

Android 面试准备进行曲 (Handler源码/面试题)v1.3_第1张图片
在这里插入图片描述

上图已经比较清晰地讲述了整个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 创建回收 链表关系

这里分享一个 有图 有源码 自我感觉不错的博客
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源码/面试题)v1.3)