Android消息机制

短命女 2022-05-25 05:27 183阅读 0赞

# Android消息机制 #

参考书籍：《Android开发艺术探索——任玉刚》

## 消息机制概述 ##

Android的消息机制主要指的是Handler的运行机制，Handler的运行又需要MessageQueue和Looper的支撑，因此本博客将分别谈到ThreadLocal、MessageQueue、Looper和Handler的底层运行机制。

首先了解一下Android消息机制涉及到的几个类：

*  MessageQueue：消息队列，内部存储了一组消息Message，以队列的形式对外提供插入和删除的工作，队列的底层实现是单链表
 *  Looper：会以无限循环的方式去查找MessageQueue中是否有新消息，如果有新消息就将消息取出交给Handler进行处理，否则保持阻塞
 *  Handler：发送和处理消息的类，需要与Looper搭配使用，在没有创建Looper的线程里使用Handler将会报错，Handler创建的时候将会采用当前线程的Looper来搭建消息处理系统。

## 消息机制分析 ##

### ThreadLocal工作原理 ###

在之前的学习中我们知道，如果我在线程A中创建了一个Handler，那么这个Handler将会采用线程A的Looper进行构建消息处理机制，也就是每个线程都有一个独立的Looper（如果实例化了的话），看到这我们想到了什么？“每个线程”、“独立的数据”，这不就是ThreadLocal吗？没错，Looper就是通过ThreadLocal实现了这个功能，接下来我们就详细的了解一下ThreadLocal是如何实现的。

首先我们在主线程中调用ThreadLocal的set方法向其中放入了一个布尔类型的值，默认为false，接着我们在线程A中将这个布尔类型的值设置为true，在线程B中不赋值直接获取，代码如下：

ThreadLocal<Boolean> booleanThreadLocal = new ThreadLocal<>();
    booleanThreadLocal.set(false);
    System.out.println(Thread.currentThread().getName() + ":" + booleanThreadLocal.get());
    
    new Thread(new Runnable() {
        @Override
        public void run() {
            booleanThreadLocal.set(true);
            System.out.println(Thread.currentThread().getName() + ":" + booleanThreadLocal.get());
        }
    }).start();
    
    new Thread(new Runnable() {
        @Override
        public void run() {
            System.out.println(Thread.currentThread().getName() + ":" + booleanThreadLocal.get());
        }
    }).start();

接着看下运行结果：

main:false
    Thread-0:true
    Thread-1:null

可以看到虽然访问的是同一个ThreadLocal对象，但是我们在其中存放的布尔数据类型的数据在不同线程之间是互相独立的。

为了搞清楚ThreadLocal的内部实现机制，我们首先来看一下set方法：

public void set(T value) {
        Thread t = Thread.currentThread();
        Values values = values(t);
        if (values == null) {
            values = initializeValues(currentThread);
        }
        values.put(this, value);
    }

可以看到在set方法中，首先通过values方法获取到当前线程的ThreadLocal数据，这是Thread下的一个数据成员：

ThreadLocal.Values localValues

如果localValues的值为空，就对其进行初始化，初始化完毕后再将ThreadLocal的值存入。那么ThreadLocal的值是如何存入localValues的呢？在localValues里面有一个Object数组table，ThreadLocal的值就是存放在这个数组中，ThreadLocal的值在table数组中的存储位置总是为ThreadLocal的reference字段所标识的对象的下一个位置，例如ThreadLocal的reference对象在table数组中的索引为index，那么ThreadLocal的值在table数组中的索引就是index+1.

接着分析ThreadLocal的get方法：

public T get() {  
        // Optimized for the fast path.  
        Thread currentThread = Thread.currentThread();  
        Values values = values(currentThread);  
        if (values != null) {  
            Object[] table = values.table;  
            int index = hash & values.mask;  
            if (this.reference == table[index]) {  
                return (T) table[index + 1];  
            }  
        } else {  
            values = initializeValues(currentThread);  
        }  
    
        return (T) values.getAfterMiss(this);  
    }

在get方法中，也是首先获取到当前Thread下的ThreadLocal.Values localValues数据成员，如果为null就返回初始值，如果不为null就取出其中的table数组并找出ThreadLocal的reference对象的索引index，那么index+1就是ThreadLocal的值。

可以看到，ThreadLocal的set和get方法最终操作的对象都是当前线程下的localValues对象里面的table数组，因此达到了各个线程间互相独立的效果。

### 消息队列的工作原理 ###

MessageQueue最需要分析的是其两个方法:enqueueMessage和next，enqueueMessage方法的作用是向队列中插入一条新的消息，next的作用是从消息队列中取出一条消息。

首先分析enqueueMessage方法的源码：

boolean enqueueMessage(Message msg, long when) {
        ...
        synchronized (this) {
            ...
            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 {
                // Inserted within the middle of the queue.  Usually we don't have to wake
                // up the event queue unless there is a barrier at the head of the queue
                // and the message is the earliest asynchronous message in the queue.
                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.
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

可以看到enqueueMessage方法实质上就是对单链表的插入操作，只是加入了synchronized关键字保证了多线程下的安全性。

接着看next方法的源码：

Message next() {
        ...
        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;
                }
                ...
            }
            ...
        }
    }

可以看到next方法是一个阻塞方法，如果MessageQueue中没有消息，那么next方法将一直等待。有新消息进入了MessageQueue中时，next方法就会将这个消息返回并从链表中删除这条消息。

### Looper的工作原理 ###

首先看一下Looper的构造方法：

private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
    }

在构造方法中首先创建了一个MessageQueue消息队列，接着获取当前线程的对象并保存起来。

Looper的工作是不停的从MessageQueue中取出消息，并交给Handler进行处理，而执行这个任务的方法就是loop，让我们看看loop的源码：

public static void loop() {
            final Looper me = myLooper();
            if (me == null) {
                throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
            }
            final MessageQueue queue = me.mQueue;
    
            // Make sure the identity of this thread is that of the local process,
            // and keep track of what that identity token actually is.
            Binder.clearCallingIdentity();
            final long ident = Binder.clearCallingIdentity();
    
            for (;;) {
                Message msg = queue.next(); // might block
                if (msg == null) {
                    // No message indicates that the message queue is quitting.
                    return;
                }
    
                // This must be in a local variable, in case a UI event sets the logger
                final Printer logging = me.mLogging;
                if (logging != null) {
                    logging.println(">>>>> Dispatching to " + msg.target + " " +
                            msg.callback + ": " + msg.what);
                }
    
                final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
    
                final long traceTag = me.mTraceTag;
                if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                    Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
                }
                final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
                final long end;
                try {
                    msg.target.dispatchMessage(msg);
                    end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
                } finally {
                    if (traceTag != 0) {
                        Trace.traceEnd(traceTag);
                    }
                }
                if (slowDispatchThresholdMs > 0) {
                    final long time = end - start;
                    if (time > slowDispatchThresholdMs) {
                        Slog.w(TAG, "Dispatch took " + time + "ms on "
                                + Thread.currentThread().getName() + ", h=" +
                                msg.target + " cb=" + msg.callback + " msg=" + msg.what);
                    }
                }
    
                if (logging != null) {
                    logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
                }
    
                // Make sure that during the course of dispatching the
                // identity of the thread wasn't corrupted.
                final long newIdent = Binder.clearCallingIdentity();
                if (ident != newIdent) {
                    Log.wtf(TAG, "Thread identity changed from 0x"
                            + Long.toHexString(ident) + " to 0x"
                            + Long.toHexString(newIdent) + " while dispatching to "
                            + msg.target.getClass().getName() + " "
                            + msg.callback + " what=" + msg.what);
                }
    
                msg.recycleUnchecked();
            }
        }

loop方法是一个死循环，只有当MessageQueue的next方法返回null之后才会跳出循环（也就是消息队列为空时）。如果MessageQueue的next方法返回了一个消息，那么Looper就会将这条消息交给Handler进行处理，对应的代码是`msg.target.dispatchMessage(msg);`，msg.target就是将这条消息发送到MessageQueue里的Handler，这样由Handler发出去的消息最终又回到了Handler的dispatchMessage()方法里面，但是不同的是，Handler的dispatchMessage方法是在创建Handler的线程中的Looper里面执行的，这样就实现了切换线程完成逻辑的功能。

### Handler的工作原理 ###

Handler的主要工作是完成消息的发送和消息的处理，消息的发送是通过post和send方法完成的，其中post方法的底层最终还是调用了send方法，因此我们这里仅讨论send方法的源码：

public final boolean sendMessage(Message msg){
        return sendMessageDelayed(msg, 0);
    }
    
    public final boolean sendMessageDelayed(Message msg, long delayMillis) {
        if (delayMillis < 0) {
            delayMillis = 0;
        }
        return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
    }
    
    public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
        MessageQueue queue = mQueue;
        if (queue == null) {
            RuntimeException e = new RuntimeException(
                    this + " sendMessageAtTime() called with no mQueue");
            Log.w("Looper", e.getMessage(), e);
            return false;
        }
        return 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);
    }

可以看到，Handler发送消息的底层实现最终就是向MessageQueue中插入一条新的消息，最终Looper通过MessageQueue的next方法获取到这条消息，并且调用msg.target.dispatchMessage(Message msg)将消息的处理重新交给Handler，下面我们来看看dispatchMessage的源码：

public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

在Handler的dispatchMessage方法内部，首先检查Message的callback是否为null，不为null就调用handleCallBack(Message msg)直接处理消息；这个callback实质上是一个Runnable对象，这个对象来自于Handler的post方法中传递过来的Runnable对象，在handleMessgae方法内部最终会调用这个Runnable的run方法执行消息的处理过程：

private static void handleCallback(Message message) {
        message.callback.run();
    }

如果Messgae的callback为空，那么就检查Handler的mCallback是否为null，不为null的话就调用mCallback的handleMessage方法处理消息，Handler的mCallback是一个接口：

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);
    }

这个接口是在Handler被创建时传入的：

Handler handler = new Handler(callback);

Handler提供了这样一个重载的构造方法的目的在于我们可以不必再派生一个Handler的子类并重写其handleMessgae方法。

当然如果我们是通过派生子类的方式来创建Handler的话：

Handler handler = new Handler(){
                @Override
                public void handleMessage(Message msg) {
                    super.handleMessage(msg);
                }
            };

最终在dispatchMessage方法中就会调用我们重写的这个handleMessage方法来处理消息。

我们可以总结一下，如果我们发送消息时调用的是`handler.post(Runnable runnable)`，那么最终在Handler处理消息的时候Message的callback就不为空，那么就会调用这个callback的run方法来处理消息；其次，如果我们在创建Handler时传入的参数为Callback接口，那么在Handler处理消息时调用的就是这个接口的handleMessage方法来处理消息；只有当我们是派生Handler的子类并重写Handler的handleMessage方法来创建Handler实例的情况下，才会调用这个重写的handleMessage方法来处理消息。