Android消息机制 2 – Java层源码分析-一一网

一. 概述

Android消息机制主要涉及的类有：

Message：消息的实体
MessageQueue：存放消息的队列，本质上不是队列，是链表
Looper : 内部不断循环提取消息
Handler：处理消息的实体

上一章中讲解了如何使用Android的消息机制，大概可分为如下几步：
1.创建线程，并调用Looper.prepare
2.初始化线程的Handler，与Looper挂钩
3.Looper.loop。

那么从上一章使用方法切入来讲解源码，源码分析基于Android R版本

二. Looper.prepare

[-> Looper.java]

    private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        //见2.1
        sThreadLocal.set(new Looper(quitAllowed));
    }

复制代码

ThreadLoacal（TLS），让线程拥有属于自己的变量，其中key为currentThread，value为Looper对象。

2.1 new Looper

[-> Looper.java ]

   private Looper(boolean quitAllowed) {
   //见2.2
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }
复制代码

其中Looper的构造函数创建了MessageQueue，并设置mThread为currentThread。

2.2 new MessageQueue

[-> MessageQueue.java]

    MessageQueue(boolean quitAllowed) {
        mQuitAllowed = quitAllowed;
        //Native层分析见Android消息机制第三章
        mPtr = nativeInit();
    }
复制代码

初始化Java层MessageQueue，并设置是否允许退出，并初始化Native层MessageQueue。

Looper.prepare初始化了Looper和MessageQueue，属于一对一的关系。

三. 初始化Handler，与Looper挂钩

先来回顾一下如何初始化Handler。

[-> 初始化Handler]

public Handler mSubHandler = new Handler(Looper.myLooper()) {
                @Override
                public void handleMessage(@NonNull Message msg) {
                    Log.i(TAG, "mSubHandler handler handleMessage thread : " + Thread.currentThread());
                    switch (msg.what) {
                        case MSG_GET:
                            double number = Math.random();
                            Message message = new Message();
                            message.what = MSG_RESULT;
                            message.obj = "dopezhi : " + number;
                            mUiHandler.sendMessage(message);
                            break;
                        default:
                            break;
                    }
                }
            };
复制代码

为什么发送消息时，只需要mSubHandler.sendMessage就可以发送消息了？

按照正常的做法，主线程想往子线程发送消息，主线程需要拿到子线程的Looper，再拿到其对应的MessageQueue，往MessageQueue扔一个消息就行了。

但是这样太麻烦了，所以Handler除了处理消息，还有一个作用：帮助我们发消息到Handler对应的MessageQueue中，简化操作，这就是挂钩的目的。

[-> Handler.java]

    public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
        mLooper = looper;
        mQueue = looper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }
复制代码

所谓的挂钩，就是在new Handler的时候，传入对应的Looper，MessageQueue等，后续我们通过Handler.sendMessaage实际上等于向之前挂钩的MessageQueue发送消息。

四. Looper.loop

[-> Looper.java]

public static void loop() {
        //获得TLS存储的Looper
        final Looper me = myLooper()；
        final MessageQueue queue = me.mQueue;
        Binder.clearCallingIdentity();
        //获取本次通信的一个令牌，后续会跟发送完消息的令牌进行比较，判断进程或者线程状态有没有发生改变
        final long ident = Binder.clearCallingIdentity();

        for (;;) {
            //死循环获取消息，见4.1
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
            ......
               //通过Handler去处理消息 见4.3
               msg.target.dispatchMessage(msg);
            ......
            final long newIdent = Binder.clearCallingIdentity();

            //回收消息 见4.4
            msg.recycleUnchecked();
        }
    }
复制代码

Looper.loop本质上是通过一个死循环来不断next来获取待处理的消息，那么这种死循环会引起消耗CPU资源吗？

不会，底层用了Linux的epoll机制，epoll机制是Linux的I/O复用技术，可以监听一个或者多个文件描述符fd是否发生了自己感兴趣的事件（epoll_ctl），在没有感兴趣的时间发生之前，会让出CPU资源，直到fd写入感兴趣的事件，立马快速唤醒epoll_wait处理。

4.1 queue.next()

[-> MessageQueue.java]

 Message next() {
     //ptr为Native层的NativeMessageQueue的地址
        final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }
        //idleHandler内容将在后续章节讲解
        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        int nextPollTimeoutMillis = 0;
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }
            //nextPollTimeoutMillis为0时无需等待直接返回，-1则无限等待
            //真正阻塞在这里，这里后续到Native层进行epoll_wait
            nativePollOnce(ptr, nextPollTimeoutMillis);

            synchronized (this) {
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                //mMessages变量为Message链表的头结点
                Message msg = mMessages;
                //同步屏障，见5
                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) {
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        mBlocked = false;
                        //下面是单链表的操作，把头结点断开作为msg返回
                        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 {
                    nextPollTimeoutMillis = -1;
                }
                //如果Looper退出，则返回null
                if (mQuitting) {
                    dispose();
                    return null;
                }
                //下面都属于idelHandler的内容
              ......
        }
    }
复制代码

调用queue.next时，会在nativePollOnce中一直等待事件的发生，先来看一下事件是怎么入队的？

4.2 handler.sendMessage

发送消息的调用链：

发送消息调用链(form gityuan).png

可以看到即便我们通过各种的方式，都用调用MessageQueue.enqueueMessage方法。

[-> MessageQueue.enqueueMessage]

    boolean enqueueMessage(Message msg, long when) {
       //表明了App端不能通过设置target==null来post同步屏障
        if (msg.target == null) {
            throw new IllegalArgumentException("Message must have a target.");
        }

        synchronized (this) {
            if (msg.isInUse()) {
                throw new IllegalStateException(msg + " This message is already in use.");
            }
            ......
            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            //如果头结点为空，初始化头结点
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
            //头结点不为空，则按照时间顺序插入到链表中，头是先执行的
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            }

            // We can assume mPtr != 0 because mQuitting is false.
            //如果需要wake，则wake
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }
复制代码

在发送完消息之后，会通过needWake判断是否需要唤醒（nativeWake）来处理事件。

看到这里你或许感觉到意犹未尽，具体是怎么唤醒的？具体内容可在Native层这一部分看到，这里也可以稍微剧透一下。

实际上，当初始化native层的NativeMessageQueue时，会通过epoll_ctl监听管道的输入事件，一旦管道被写入事件（就是nativeWake干的事，写入了一个字符1），epoll_wait就会醒来处理，底层只是简单清除管道数据，但是底层函数就能返回，反应到上层就是queue.next()中的nativePollOnce能返回，进而处理提取事件进行处理。

4.3 msg.target.dispatchMessage

此处的target为Handler。

[-> Handler.java]

    public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
复制代码

处理规则：

如果Message Callback不为null，则处理Message Callback
如果Message Callback为null
- 如果Handler Callback不为null，则处理Handler Callback
- 如果Handler Callback为null，则正常处理消息

y1u1有点乱，什么跟什么，一个个解答！

4.3.1 Message Callback？

发送消息除了刚才的sendMessage，还有一个Handler.post。

[-> Handler.java]

    public final boolean post(@NonNull Runnable r) {
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
复制代码

    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }
复制代码

喔，原来使用Handler.post发送消息，是提交runnable对象，把对应的Message.callback设置该runnable对象。让该Message优先执行。

4.3.2 Handler Callback？

[-> Test.java]

            Handler.Callback callback = new Handler.Callback() {
                @Override
                public boolean handleMessage(@NonNull Message msg) {
                    switch (msg.what){
                        case MSG_PASS:
                            return true;
                        default:
                            return false;
                    }
                }
            };
复制代码

Handler Callback就是让Handler有拦截消息的能力，比如我判断初该信息的what是MSG_PASS，则return true跳过该消息。

4.3.3 handleMessage

如果该消息没有被Handler过滤掉，则执行我们写的handleMessage方法。

4.4 msg.recycleUnchecked

[-> Message.java]

    @UnsupportedAppUsage
    void recycleUnchecked() {
        flags = FLAG_IN_USE;
        what = 0;
        arg1 = 0;
        arg2 = 0;
        obj = null;
        replyTo = null;
        sendingUid = UID_NONE;
        workSourceUid = UID_NONE;
        when = 0;
        target = null;
        callback = null;
        data = null;

        synchronized (sPoolSync) {
            if (sPoolSize < MAX_POOL_SIZE) {
                next = sPool;
                sPool = this;
                sPoolSize++;
            }
        }
    }
复制代码

Message内部其实是有维护一个缓存消息池，这个池子的大小是50个。当回收消息时，如果消息池大小还没超过最大值时，会加入到缓存消息池中，并让sPool指向消息池的第一个消息，后续就可以拿他。

但是很奇怪，一直以来我都是new Message的啊，new Message构造函数啥都没干，按道理它应该去消息池获取消息才对，要不然每次我都new，消息池都只能缓存50个，不就浪费很多，触发GC吗？

后来才发现获取消息最恰当的方法是Message.obtain().

[-> Message.java]

/** Constructor (but the preferred way to get a Message is to call {@link #obtain() Message.obtain()}).
    */
    public Message() {
    }
    
    /**
     * Return a new Message instance from the global pool. Allows us to
     * avoid allocating new objects in many cases.
     */
    public static Message obtain() {
        synchronized (sPoolSync) {
            if (sPool != null) {
                Message m = sPool;
                sPool = m.next;
                m.next = null;
                m.flags = 0; // clear in-use flag
                sPoolSize--;
                return m;
            }
        }
        return new Message();
    }

复制代码

从注释也可以看得出来官方是更推荐我们使用Message.obtain()来获取Message的，避免使用new Message的方式分配多余的对象。

五. 同步屏障机制

5.1 原理

首先先思考一个问题，假如我有一个很急的消息，我想MessageQueue立马帮我处理，怎么做呢？只要把消息添加到队列的头部就可以了，但是MessageQueue是基于处理时间排序的，那在这时间点之前还有很多消息堆积，你发的消息也没办法第一时间执行。

因此就有了同步屏障机制。

所有的消息默认都是同步消息，只有设置了异步消息的标志才是异步消息，当不断queue.next()提取消息，只要发现某个消息的target为null，则进入同步屏障的机制，接下来遍历剩余的所有消息，只要消息设置了异步标志，则优先提取消息处理，直到removeBarrier。

[-> MessageQueue.java]

    //返回值为表明该barrier的一个token，这个token的值就是当前MessageQueue维护的一个同步屏障的数量的值。
    @UnsupportedAppUsage
    public int postSyncBarrier() {
        return postSyncBarrier(SystemClock.uptimeMillis());
    }

    private int postSyncBarrier(long when) {
        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;
        }
    }
复制代码

可以看到，post一个同步屏障，就是Message的target为null，这个是App测无法做到的。

[-> Message.java]

    public void setAsynchronous(boolean async) {
        if (async) {
            flags |= FLAG_ASYNCHRONOUS;
        } else {
            flags &= ~FLAG_ASYNCHRONOUS;
        }
    }
复制代码

通过 | 设置异步消息。

5.2 同步屏障的应用

Choreographer 里所有跟 message 有关的代码都设置了异步标志。这样是为了尽可能的保证在上层app收到vsync时都能第一时间执行遍历以及绘制view树的工作。

这里的第一时间是指执行ViewRootImpl.scheduleTraversals之后。
[-> ViewRootImpl.java]

    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            //post同步屏障
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            //提交mTraversalRunnable，主要做doTraversal
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }
复制代码

可以看到在scheduleTraversals中提交了一个同步屏障，后续该MessageQueue优先执行异步消息。

[-> Choreographer.java]

    private void postCallbackDelayedInternal(int callbackType,
            Object action, Object token, long delayMillis) {
.....
        synchronized (mLock) {
            final long now = SystemClock.uptimeMillis();
            final long dueTime = now + delayMillis;
            mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);

            if (dueTime <= now) {
                scheduleFrameLocked(now);
            } else {
            //设置Message Callback，提高优先级
                Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
                msg.arg1 = callbackType;
                //设置异步消息
                msg.setAsynchronous(true);
                mHandler.sendMessageAtTime(msg, dueTime);
            }
        }
    }
复制代码

设置Message Callback为mTraversalRunnable（doTraversal），并设置该消息为异步消息，得到优先处理。

5.3 关于View的一些前瞻

由于现在对View这块不是很熟，现在粗略写这块，以后会出详细分析的文章。

通过WindowManagerGlobal.addView时,会初始化ViewRootImpl。
[-> WindowManagerGlobal.java]

public void addView(View view, ViewGroup.LayoutParams params,
            Display display, Window parentWindow, int userId) {
    ......
    ViewRootImpl root;
    root = new ViewRootImpl(view.getContext(), display);
    
    .....
    root.setView(view, wparams, panelParentView, userId);
}
复制代码

执行setView。

[-> ViewRootImpl.java]

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    synchronized (this) {
        if (mView == null) {
            mView = view;
            ......
            requestLayout(); 
            
            //这里的view指的是DectorView
            view.assignParent(this); 
            ···
        }
    }
}
复制代码

[-> View.java]

    @UnsupportedAppUsage
    void assignParent(ViewParent parent) {
        if (mParent == null) {
            mParent = parent;
        } else if (parent == null) {
            mParent = null;
        } else {
            throw new RuntimeException("view " + this + " being added, but"
                    + " it already has a parent");
        }
    }
复制代码

参数是ViewParent，而ViewRootImpl是实现了ViewParent的接口，这里将DecorView与ViewRootImpl绑定起来。每个Activity的根布局都是DecorView，而DecorView的parent又是ViewRootImpl，所以在子View里面执行invalidate()之类的工作，循环找到parent，找到DecorView，找到ViewRootImpl，View的刷新更新统一都由ViewRootImpl来控制。

未命名文件.png

所以即便是界面上一个小小的View发起重绘请求，都要走到ViewRootImpl（6.5疑问：子view的添加过程？如何跟这个DecorView挂上联系，子View也是ViewRootImpl是吧，ViewRootImpl是View树，还是普通的View是View树；如果添加子view也是相同的方法，那么你只是View跟ViewRootImpl挂上联系，而不是跟View树挂上联系），由它来发起重绘请求，然后再由它来开始遍历 View 树，一直遍历到这个需要重绘的 View 再调用它的 onDraw() 方法进行绘制。

而请求重绘的操作View.invalidate()，以及setView的最后都是调用requestLayout()(为什么它在前？)
[-> ViewRootImpl.java]

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        //回到了同步屏障的内容
        scheduleTraversals();
    }
}
复制代码

六. IdleHandler

6.1 原理

IdleHandler是MessgeQueue的静态内部接口，是一种只有当消息队列没有消息时或者是队列中还没有到执行时间时才会执行的IdleHandler。

[-> 如何使用]

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override
    public boolean queueIdle() {
        //空闲时处理逻辑

        return false;
    }
});
复制代码

返回false时，该IdleHandler就会被移除。

[-> MessageQueue.java]

//总的IdleHandlers
private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>();

//该次需要执行的IdeleHandlers
private IdleHandler[] mPendingIdleHandlers;

Message next() {
......
       //本次需要处理的IdelHandler数量
       int pendingIdleHandlerCount = -1; // -1 only during first iteration
         //只有在队伍没有消息，或者消息还没到时间执行的时才会执行
        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;
        }
        //初始化mPendingIdleHandlers数组，并将总IdleHandlers存一份到本次需要处理的数组中
        if (mPendingIdleHandlers == null) {
            mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
        }
        mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        //开始处理本次需要执行的IdelHandlers。
        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);
            }
            //如果返回false，表示移除该IdelHandler
            if (!keep) {
                synchronized (this) {
                    mIdleHandlers.remove(idler);
                }
            }
        }
}
复制代码

6.2源码应用

系统源码中，Activity执行Rusume时，会在handleResumeActivity最后有一句:

Looper.myQueue().addIdleHandler(new Idler());
复制代码

[-> ActivityThread.java]

    private class Idler implements MessageQueue.IdleHandler {
        @Override
        public final boolean queueIdle() {
            ActivityClientRecord a = mNewActivities;
            boolean stopProfiling = false;
            if (mBoundApplication != null && mProfiler.profileFd != null
                    && mProfiler.autoStopProfiler) {
                stopProfiling = true;
            }
            if (a != null) {
                mNewActivities = null;
                IActivityTaskManager am = ActivityTaskManager.getService();
                ActivityClientRecord prev;
                do {
                    if (localLOGV) Slog.v(
                        TAG, "Reporting idle of " + a +
                        " finished=" +
                        (a.activity != null && a.activity.mFinished));
                    if (a.activity != null && !a.activity.mFinished) {
                        try {
                            am.activityIdle(a.token, a.createdConfig, stopProfiling);
                            a.createdConfig = null;
                        } catch (RemoteException ex) {
                            throw ex.rethrowFromSystemServer();
                        }
                    }
                    prev = a;
                    a = a.nextIdle;
                    prev.nextIdle = null;
                } while (a != null);
            }
            if (stopProfiling) {
                mProfiler.stopProfiling();
            }
            applyPendingProcessState();
            return false;
        }
    }
复制代码

主要是做一些回收操作。界面已经显示这些重要的事情已经处理完了，空闲的时候就可以开始处理回收的操作，空闲值的就是主线程MessageQueue中没有Message了，这个时候就可以开始回收了。（消息太多呢怎么办？来不及执行？）

resumeTopActivityInnerLocked() -> completeResumeLocked() -> scheduleIdleTimeoutLocked() 方法中会发送一个会发送一个延迟消息（10s），如果界面很久没有关闭(如果界面需要关闭)，那么 10s 后该消息被触发就会关闭界面，执行 onStop 等方法。