Android的消息机制之Handler源码解析
Android 的消息机制
消息机制在开发中我们会经常遇到，Handler的使用过程很简单，通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。很多人认为Handler 的作用是更新UI，这的确没错，但是更新UI仅仅是Handler的一个特殊的使用场景。具体来说是这样的：有时候需要在子线程中进行耗时操作，当耗时操作完成以后可能需要在UI上做一些改变，由于Android开发规范的限制， 我们并不能在子线程中访问UI控件，否则就会触发程序异常，这个时候通过Handler就可以将更新UI的操作切换到主线程中执行。因此，本质上来说，Handler并不是专门用于更新UI的，它只是常被开发者用来更新UI。
Android的消息机制主要是指Handler的运行机制，Handler的运行需要的 MessageQueue和Looper的支撑。MessageQueue是消息队列，它的内部存储了一组消息，以队列的形式对外提供插入和删除的工作。虽然叫消息队列，但是它的内部存储结构并不是真正的队列，而是釆用单链表的数据结构来存储消息列表。Looper 可以理解为消息循环。由于MessageQueue 只是一个消息的存储单元，它不能去处理消息，而Looper就填补了这个功能，Looper会以无限循环的形式去査找是否有新消息，如果有的话就处理消息，否则就一直等待着。Looper中还有一个特殊的概念， 那就是ThreadLocal，ThreadLocal并不是线程，它的作用是可以在每个线程中存储数据。我们知道，Handler创建的时候会采用当前线程的Looper来构造消息循环系统，那么Handler内部如何获取到当前线程的Looper呢？这就要使用ThreadLocal 了，ThreadLocal可以在不同的线程中互不干扰地存储并提供数据，通过ThreadLocal可以轻松获取每个线程的Looper。当然需要注意的是，线程是默认没有Looper的，如果需要使用Handler就必须为线程创建Looper。
本文主要基于Android 8.1.0 系统分析android的消息机制
1. Android 的消息机制概述
Android 的消息机制主要是指 Handler 的运行机制以及 Handler 所附带的 MessageQueue 和 Looper 的工作过程，这三者实际上是一个整体，只不过我们在开发过程中比较多地接触到 Handler 而已。Handler的主要作用是将一个任务切换到某个指定的线程 中去执行，那么Android为什么要提供这个功能呢？这是因为Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。ViewRootlmpI对UI操作做了验证，这个验证工作是由ViewRootlmpI的checkThread方法来完成的，代码如下所示：
frameworks/base/core/java/android/view/ViewRootImpl.java
void checkThread() { if (mThread != Thread.currentThread()) { throw new CalledFromWrongThreadException( "Only the original thread that created a view hierarchy can touch its views."); } }针对checkThread方法中抛出的异常信息，相信读者在开发中都曾经遇到过。由于这 一点的限制，导致必须在主线程中访问UI，但是Android又建议不要在主线程中进行耗时操作，否则会导致程序无法响应即ANR。考虑一种情况，假如我们需要从服务端获取一些信息并将其显示在UI上，这个时候必须在子线程中进行获取数据的工作，获取数据完成后又不能在子线程中直接访问UI，如果没有Handler，那么我们的确没有办法将访问UI的工作切换到主线程中去执行。因此，系统之所以提供Handler，主要原因就是为了解决在子线程中无法访 问UI的问题。
系统为什么不允许在子线程中访问UI呢？这是因为Android的UI 控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态， 那为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：首先加上锁机制会让UI访问的逻辑变得复杂；其次锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。 鉴于这两个缺点，最简单且高效的方法就是采用单线程模型来处理UI操作，对于开发者来说也不是很麻烦，只是需要通过Handler切换一下UI访问的执行线程即可。
Handler 的使用方法这里就不做介绍了，有兴趣的同学可以通过“Handler消息机制 —— 基本使用及存在的性能问题”这篇文章去学习，这里描述一下 Handler 的工作原理。Handler 创建时会采用当前线程的 Looper 来构建内部的消息循环系统，如果当前线程没有Looper，那么就会报错，错误信息如下所示：
2020-08-04 14:06:42.050 12985-13017/com.lx.test E/AndroidRuntime: FATAL EXCEPTION: pool-1-thread-1 Process: com.lx.test, PID: 12985 java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare() at android.os.Handler.(Handler.java:204) at android.os.Handler.(Handler.java:118) at com.lx.test.MainActivity$1.run(MainActivity.java:31) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764) 如何解决上述问题呢？其实很简单，只需要为当前线程创建一个Looper即可。
Handler创建完毕后，这个时候其内部的 Looper 以及 MessageQueue 就可以和 Handler 一起协同工作了，然后通过Handler的 post 方法将一个 Runnable 投递到 Handler 内部的 Looper 中去处理，也可以通过 Handler 的 send 方法发送一个消息，这个消息同样会在 Looper 中去处理。其实 post 方法最终也是通过 send 方法来完成的，接下来主要来看一下 send 方法的工作过程。当 Handler 的 send 方法被调用时，它会调用 MessageQueue 的 enqueueMessage 方法将这个消息放入消息队列中，然后Looper 发现有新消息到来时，就会处理这个消息， 最终消息中的 Runnable 或者 Handler 的 handleMessage 方法就会被调用。注意 Looper 是运行在创建 Handler 所在的线程中的，这样一来 Handler 中的业务逻辑就被切换到创建 Handler 所在的线程中去执行了，这个过程可以用图1来表示。
图1 Handler 的工作过程
2. Android 的消息机制分析
本节将对 Android 消息机制的实现原理做一个全面的分析，主要包括 Handler，MessageQueue 和 Looper。同时为了更好地理解 Looper 的工作原理，还会介绍 ThreadLocal的工作原理，通过本节的分析可以让读者对 Android 的消息机制有一个深入的理解。
2.1 ThreadLocal 的工作原理
ThreadLocal是线程本地变量的意思，主要用于多线程对同一个变量的读写操作，且相互之间又不会依赖于原始值的改变而影响线程的业务逻辑。主要表现为以下两个方面：
1：每一个线程对ThreadLocal变量都保存着一份副本，任何一个线程的操作只是对这个副本的操作，并不会对原始数据进行修改。
2：由于ThreadLocal变量是线程本地变量，因此其不适用于值的改变需要对多线程必须可见的场景。
下面通过一个例子来理解ThreadLocal的用法，代码如下所示：
public class MainActivity extends AppCompatActivity { private static final String TAG = MainActivity.class.getSimpleName(); // 定义ThreadLocal对象 private ThreadLocal mNameThreadLocal = new ThreadLocal<>(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // 主线程 mNameThreadLocal.set("UI Thread"); Log.d(TAG,"主线程中的值：" + mNameThreadLocal.get()); // 线程1 Executors.newCachedThreadPool().execute(new Runnable() { @Override public void run() { mNameThreadLocal.set("Thread-1"); Log.d(TAG,"线程1中的值：" + mNameThreadLocal.get()); } }); // 线程2 Executors.newCachedThreadPool().execute(new Runnable() { @Override public void run() { mNameThreadLocal.set("Thread-2"); Log.d(TAG,"线程2中的值：" + mNameThreadLocal.get()); } }); }} 在 MainActivity 中我们定义了一个 ThreadLocal 类型的变量 mNameThreadLocal变量，然后分别在主线程、线程1 和 线程2 中设置和访问它的值。运行结果如下所示：
2020-08-04 14:39:03.412 13716-13716/com.lx.message.mechanism D/MainActivity: 主线程中的值：UI Thread2020-08-04 14:39:03.413 13716-13758/com.lx.message.mechanism D/MainActivity: 线程2中的值：Thread-22020-08-04 14:39:03.416 13716-13757/com.lx.message.mechanism D/MainActivity: 线程1中的值：Thread-1从上面日志可以看出，虽然在不同线程中访问的是同一个 ThreadLocal 对象，但是它们通过 ThreadLocal 获取到的值却是不一样的，这就是 ThreadLocal 的奇妙之处。
对 ThreadLocal 的使用方法和工作过程做了介绍后，下面分析 ThreadLocal 的内部实现, ThreadLocal 是一个泛型类，它的定义为 public class ThreadLocal
首先来分析 ThreadLocal 的 set 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
public void set(T value) { // 获取当前线程 Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); }ThreadLocal 的 set 方法中会调用 getMap 方法获取 ThreadLocalMap 类型的对象 map，getMap 方法的代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
ThreadLocalMap getMap(Thread t) { return t.threadLocals; }在 ThreadLocal 的 set 方法中，如果 getMap 获取的map对象为空时，会调用 createMap 方法来创建一个 map 对象，createMap 方法的代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); }接下来我们来查看 TheadLocal.ThreadLocalMap 的构造方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { // 初始化Entry数组， INITIAL_CAPACITY 默认值为16 table = new Entry[INITIAL_CAPACITY]; // 计算 firstKey 在 Entry 数组中应该存放的位置 int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); // 实例化一个Entry对象，并存入Entry 数组中 table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); }ThreadLocalMap 内部类有一个Entry 类，key是ThreadLocal 对象，value 就是需要存放的值。
再回到 ThreadLocal 的 set 方法中，当通过 getMap 方法获取的 map 对象不为空是，调用 ThreadLocalMap 的 set 方法将要存储的值存储进去，ThreadLocalMap 的 set 方法代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
private void set(ThreadLocal<?> key, Object value) { Entry[] tab = table; int len = tab.length; // 计算当前key在Entry数组中应该存放的位置 int i = key.threadLocalHashCode & (len-1); // 遍历 Entry 数组，有两种可能会退出这个循环 // 1. 找到了相同的 ThreadLocal 对象 // 2. 一直往数组的下一个下标进行查询，直到下一个下标对应的元素为空 for (Entry e = tab[i]; e != null;e = tab[i = nextIndex(i, len)]) { ThreadLocal<?> k = e.get(); // 如果数组中存在key，则直接更新key所对应的value即可。 if (k == key) { e.value = value; return; } // k==null&&e!=null, 说明key被垃圾回收机制回收了，因为Entry采用的是弱引用。 if (k == null) { // 替换被回收key的值，把新的值放在这里放回 replaceStaleEntry(key, value, i); return; } } // 如果for循环没有返回，说明在Entry中没有找到相同的 ThreadLocal 对象， 则创建一个新的Entry 对象存入到数组中。 tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) // 进行扩容 rehash(); }下面我们分析一下 replaceStaleEntry 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
private void replaceStaleEntry(ThreadLocal<?> key, Object value, int staleSlot) { Entry[] tab = table; int len = tab.length; Entry e; // 这里采用的是从当前的 staleSlot 位置向前遍历，这样做的好处是可以把前面已经被 // 垃圾回收机制回收的也一起释放出空间来。(注意：这里只是key被回收了，value还没有 // 被回收，entry更加没有被回收，所以需要让他们也被回收)。 // 同时也避免这样存在很多key==null的对象（简称过期对象）的占用。 int slotToExpunge = staleSlot; for (int i = prevIndex(staleSlot, len); (e = tab[i]) != null; i = prevIndex(i, len)) //slotToExpunge 记录 staleSlot 左手边第一个空的 entry 到 staleSlot 之间 key过期最小的 index if (e.get() == null) slotToExpunge = i; // 这里采用的是从当前的 staleSlot 位置向后遍历。 for (int i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); // 发现Entry的键值和我们要存入的key相同，需要替换旧值并且和前面过期的entry对象进行交换位置。 if (k == key) { e.value = value; tab[i] = tab[staleSlot]; tab[staleSlot] = e; // 若果在第一个for循环（先前遍历）中没有找到任何过期对象 // 只有 staleSlot 对应的对象过期，由于前面过期的对象已经通过交换位置 // 的方式放到index=i上了，所以需要清理的位置是i,而不是传过来的staleSlot if (slotToExpunge == staleSlot) slotToExpunge = i; // 清理过期数据 cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); return; } // 如果我们在第一个for 循环向前遍历的时候没有找到任何过期的对象 // 那么我们需要把slotToExpunge 设置为向后遍历的第一个过期对象的位置 // 如果整个数组都没有找到要设置的key的时候，该key会设置在该staleSlot的位置上 //如果数组中存在要设置的key,那么上面也会通过交换位置的时候把有效值移到staleSlot位置上 //综上所述，staleSlot位置上不管怎么样，存放的都是有效的值，所以不需要清理的 if (k == null && slotToExpunge == staleSlot) slotToExpunge = i; } // 如果key 在数组中没有存在，那么直接新建一个新的放进去 tab[staleSlot].value = null; tab[staleSlot] = new Entry(key, value); // 如果有其他已经过期的对象，那么需要清理他 if (slotToExpunge != staleSlot) cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); }这里说明一下为什么需要交换，假设for循环向后查找发现存在key值和我们需要存入的key相同时，数组下标值我index。index 肯定是大于 staleSlot 的，如果进行不交换，那么staleSlot位置的元素就会被清除，当下次又有一个相同的key进来时，staleSlot位置的元素为空，而 for 循环终止条件是 e == null，导致后面存在key相同的元素没法找到，它会直接存放在 staleSlot 的位置，导致 Entry 数组中出现了重复的key，所以必须要交换数据。
接下来我们分析 expungeStaleEntry 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
private int expungeStaleEntry(int staleSlot) { Entry[] tab = table; int len = tab.length; // 将staleSlot位置的数据设置为null，方便GC回收 tab[staleSlot].value = null; tab[staleSlot] = null; size--; // Rehash until we encounter null Entry e; int i; for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); // 通过循环找到key为null的entry，将它的数据设置为null，方便GC回收。 if (k == null) { e.value = null; tab[i] = null; size--; } else { // 这里的主要作用就是让后面的元素往前移动 // 为什么要这样做呢？主要是开放地址寻找元素的时候，遇到null 就停止寻找了， // 你前面k==null的时候已经设置entry为null了，不移动的话， // 那么后面的元素就永远访问不了了， int h = k.threadLocalHashCode & (len - 1); if (h != i) { tab[i] = null; // Unlike Knuth 6.4 Algorithm R, we must scan until // null because multiple entries could have been stale. while (tab[h] != null) h = nextIndex(h, len); tab[h] = e; } } } return i; }下面我们来分析 ThreadLocal 的 get 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
public T get() { Thread t = Thread.currentThread(); // 获取当前线程的ThreadLocalMap对象 ThreadLocalMap map = getMap(t); if (map != null) { // 获取当前线程的Entry实例 ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") // 获取 Entry 的 value 值 T result = (T)e.value; return result; } } // 如果map为空，返回值其实是null return setInitialValue(); }ThreadLocal 的 get 方法会调用 ThreadLocalMap 的 getEntry 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
private Entry getEntry(ThreadLocal<?> key) { // 计算 key 对应的 Entry 数组中的下标 int i = key.threadLocalHashCode & (table.length - 1); // 获取对应下标的元素 Entry e = table[i]; // 如果key对应下标的元素不为空，并且该元素的key和我们传入的key相同时，直接返回改元素。 if (e != null && e.get() == key) return e; else return getEntryAfterMiss(key, i, e); }在 ThreadLocalMap 的 getEntry 方法中，如果key对应下标的元素为空或者该元素的key和我们传入的key不相同时，会调用THreadLocalMap 的 getEntryAfterMiss 方法，代码如下所示：
libcore/ojluni/src/main/java/java/lang/ThreadLocal.java
private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) { Entry[] tab = table; int len = tab.length; // 选好遍历 Entry 数组 while (e != null) { ThreadLocal<?> k = e.get(); // 如果找到相同的key，直接返回 if (k == key) return e; if (k == null) // 如果key为null，清理数据。 expungeStaleEntry(i); else i = nextIndex(i, len); e = tab[i]; } return null; }从ThreadLocal 的set 和 get 方法可以看到，他们的操作都的针对当前线程的 ThreadLocalMap 进行的操作，因此不同的线程中访问同一个ThreadLocal 的 set 和 get 方法，他们针对ThreadLocal 所做的操作仅限于各自线程的内部。这就是为什么ThreadLocal 可以在不同线程中互不干扰的存取数据了。
2.2 消息队列（MessageQueue）的工作原理。
消息队列在Android中指的是MessageQueue， MessageQueue主要包含两个操作：插入和读取。读取操作本身会伴随着删除操作，插入和读取对应的方法分别为enqueueMessage 和next，其中enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。尽管MessageQueue叫消息队列，但是它的内部实现并不是用的队列，实际上它是通过一个单链表的数据结构来维护消息列表，单链表在插入和删除上比较有优势。
首先来分析 MessageQueue 的 enqueueMessage 方法，代码如下所示：
frameworks/base/core/java/android/os/MessageQueue.java
boolean enqueueMessage(Message msg, long when) { // msg.target 就是发送此消息的Handler对象 if (msg.target == null) { throw new IllegalArgumentException("Message must have a target."); } // 表示此消息正在被使用 if (msg.isInUse()) { throw new IllegalStateException(msg + " This message is already in use."); } synchronized (this) { // 表示此消息队列已近被弃用了 if (mQuitting) { IllegalStateException e = new IllegalStateException( msg.target + " sending message to a Handler on a dead thread"); Log.w(TAG, e.getMessage(), e); msg.recycle(); return false; } msg.markInUse(); msg.when = when; // 将延迟时间封装到消息msg的内部 Message p = mMessages; // 消息队列的第一个元素 boolean needWake; if (p == null || when == 0 || when < p.when) { // 如果此队列中头部元素是null(空的队列，一般是第一次)， // 或者此消息不是延时的消息或者延迟时间小于消息队列中第一个元素的延迟时间， // 此时会将这个消息作为新的头部元素，并将此消息的next指向旧的头部元素， // 然后判断Looper获取消息的线程，如果是阻塞状态则唤醒它，让它立刻去拿消息处理 msg.next = p; mMessages = msg; needWake = mBlocked; } else { // 如果此消息是延时的消息，则将其添加到队列中，原理就是链表的添加新元素， // 按照when，也就是延迟的时间来插入的，延迟的时间越长，越靠后， // 这样就得到一条有序的延时消息链表，取出消息的时候，延迟时间越小的， // 就被先获取了。插入延时消息不需要唤醒Looper线程。 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; }MessageQueue 的 enqueueMessage 方法可以看出 MessageQueue 的底层数据结构是单向链表，enqueueMessage 方法的作用主要有两个：
1） 插入消息到消息队列中。
2）唤醒Looper中等待的线程（如果消息是及时消息并且线程是阻塞状态）。
接下里我们分析 MessageQueue 的 next 方法，代码如下所示：
frameworks/base/core/java/android/os/MessageQueue.java
Message next() { // Return here if the message loop has already quit and been disposed. // This can happen if the application tries to restart a looper after quit // which is not supported. final long ptr = mPtr; if (ptr == 0) { // 从官方注释可以看出，只有looper被放弃的时候（调用了quit方法）才会返回null， // mPtr是MessageQueue的一个long型成员变量，关联的是一个在C++层的MessageQueue， // 阻塞操作就是通过底层的这个MessageQueue来操作的；当队列被放弃的时候其变为0。 return null; } int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { if (nextPollTimeoutMillis != 0) { Binder.flushPendingCommands(); } // 阻塞方法，主要是通过native层的epoll监听文件描述符的写入事件来实现的。 // 如果nextPollTimeoutMillis=-1，一直阻塞不会超时。 // 如果nextPollTimeoutMillis=0，不会阻塞，立即返回。 // 如果nextPollTimeoutMillis>0，最长阻塞nextPollTimeoutMillis毫秒(超时)， // 如果期间有程序唤醒会立即返回。 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) { //msg.target == null表示此消息为消息屏障（通过postSyncBarrier方法发送来的） // 如果发现了一个消息屏障，会循环找出第一个异步消息（如果有异步消息的 // 话），所有同步消息都将忽略（平常发送的一般都是同步消息） do { prevMsg = msg; msg = msg.next; } while (msg != null && !msg.isAsynchronous()); } if (msg != null) { if (now < msg.when) { // 如果消息此刻还没有到时间，设置一下阻塞时间nextPollTimeoutMillis， // 进入下次循环的时候会调用nativePollOnce(ptr, nextPollTimeoutMillis)进行阻塞； nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE); } else { // 正常取出消息，并且将mBlocked设置为false，表示线程没有被阻塞 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 { // 没有消息，会一直阻塞，直到被唤醒 nextPollTimeoutMillis = -1; } // Process the quit message now that all pending messages have been handled. if (mQuitting) { dispose(); return null; } // If first time idle, then get the number of idlers to run. // Idle handles only run if the queue is empty or if the first message // in the queue (possibly a barrier) is due to be handled in the future. 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 的 next 方法 由此可以看出：
1) 当首次进入或所有消息队列已经处理完成，由于此刻队列中没有消息（mMessages为null），这时nextPollTimeoutMillis = -1 ，然后会处理一些不紧急的任务（IdleHandler），之后线程会一直阻塞，直到被主动唤醒。
2) 读取列表中的消息，如果发现消息屏障，则跳过后面的同步消息。
3) 如果拿到的消息还没有到时间，则重新赋值nextPollTimeoutMillis = 延时的时间，线程会阻塞，直到时间到后自动唤醒
4) 如果消息是及时消息或延时消息的时间到了，则会返回此消息给looper处理。
2.3 Looper 的工作原理
Looper 在 Android 的消息机制中扮演着消息循环的角色，具体来说就是它会不停地从 MessageQueue 中査看是否有新消息需要立即处理，否则就一直阻塞在那里。 首先看一下它的构造方法，在构造方法中它会创建一个 MessageQueue 即消息队列，然后将当前线程的对象保存起来，代码如下所示：
frameworks/base/core/java/android/os/Looper.java
private Looper(boolean quitAllowed) { // 创建 MessageQueue 消息队列 mQueue = new MessageQueue(quitAllowed); // 保存当前线程对象 mThread = Thread.currentThread(); }前面我们提到过 Handler 的工作需要 Looper ，没有 Looper 的线程就会报错，那么如何为一个线程创建 Looper 呢？其实很简单，通过 Looper 的 prepare 方法即可为线程创建 Looper ， 接着通过 Looper 的 loop 方法来开启消息循环，代码如下所示：
Executors.newCachedThreadPool().execute(new Runnable() { @Override public void run() { Looper.prepare(); Handler handler = new Handler(); Looper.loop(); } });Looper 除了 prepare 方法外，还提供了 prepareMainLooper 方法，这个方法主要是给主线程也就是ActivityThread创建Looper 使用的，其本质也是通过 prepare 方法来实现的。由于主线程的 Looper 比较特殊，所以Looper提供了一个 getMainLooper 方法，通过它可以在任何地方获取到主线程的 Looper 。Looper 也是可以退出的，Looper 提供了 quit 和quitSafely 来退岀一个Looper，二者的区别是：quit会直接退出 Looper ，而 quitSafely 只是设定一个退出标记，然后把消息队列中的已有消息处理完毕后才安全地退出。Looper退出后，通过 Handler 发送的消息会失败，这个时候Handler 的 send 方法会返回 false 。在子线程中，如果手动为其创建了 Looper ，那么在所有的事情完成以后应该调用 quit 方法来终止消息循环， 否则这个子线程就会一直处于等待的状态，而如果退出 Looper 以后，这个线程就会立刻终止，因此建议不需要的时候终止 Looper。
Looper 最重要的一个方法就是 loop 方法，只有调用了 loop 方法后，消息循环系统才会正真的起作用，loop 方法的代码如下所示：
frameworks/base/core/java/android/os/Looper.java
public static void loop() { // 获取当前线程的Looper对象 final Looper me = myLooper(); if (me == null) { throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread."); } // 获取 Looper 中的 MessageQueue 消息队列 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. // 如果消息为null，表明消息队列正在退出 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 { // 将消息分发给Handler，msg.target指的就是发送该消息的Handler对象 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(); } }Looper 的 loop 方法的工作过程也比较好理解，loop 方法是一个死循环，唯一跳岀循环的方式是 MessageQueue 的 next 方法返回了 null 。当 Looper 的 quit 方法被调用时，Looper 就会调用 MessageQueue 的 quit 或者 quitSafely 方法来通知消息队列退出，当消息队列被标记为退出状态时，它的 next 方法就会返回 null。也就是说，Looper 必须退出，否则 loop 方法就会无限循环下去。 loop 方法会调用 MessageQueue 的 next 方法来获取新消息，而next 是一个阻塞操作，当没有消息时，next 方法会一直阻塞在那里，这也导致 loop 方法一直阻塞在那里。如果 MessageQueue 的 next 方法返回了新消息，Looper 就会处理这条消息： msg.target.dispatchMessagc(msg)，这里的 msg.target 是发送这条消息的 Handler 对象，这样 Handler 发送的消息最终又交给它的 dispatchMessage 方法来处理了。但是这里不同的是， Handler 的 dispatchMessage 方法是在创建 Handler 时所使用的 Looper 中执行的，这样就成功地将代码逻辑切换到指定的线程中去执行了。
2.4 Handler 的工作原理
Handler 的工作主要包含消息的发送和接收过程。消息的发送可以通过 post 的一系列方法以及 send 的一系列方法来实现， post 的一系列方法最终是通过 send 的一系列方法来实现的。我们从 Handler 的 post 和 send 系列方法开始分析，代码如下所示：
frameworks/base/core/java/android/os/Handler.java
// post 系列方法 public final boolean post(Runnable r) { return sendMessageDelayed(getPostMessage(r), 0); } public final boolean postAtTime(Runnable r, long uptimeMillis) { return sendMessageAtTime(getPostMessage(r), uptimeMillis); } public final boolean postAtTime(Runnable r, Object token, long uptimeMillis) { return sendMessageAtTime(getPostMessage(r, token), uptimeMillis); } public final boolean postDelayed(Runnable r, long delayMillis) { return sendMessageDelayed(getPostMessage(r), delayMillis); } public final boolean postAtFrontOfQueue(Runnable r) { return sendMessageAtFrontOfQueue(getPostMessage(r)); } // send 系列方法 public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); } public final boolean sendEmptyMessage(int what) { return sendEmptyMessageDelayed(what, 0); } public final boolean sendEmptyMessageDelayed(int what, long delayMillis) { Message msg = Message.obtain(); msg.what = what; return sendMessageDelayed(msg, delayMillis); } public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) { Message msg = Message.obtain(); msg.what = what; return sendMessageAtTime(msg, uptimeMillis); } 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); } public final boolean sendMessageAtFrontOfQueue(Message msg) { 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, 0); }从上面的代码可以看出，post 系列方法最终都是调用 send 系统方法实现的，而 send 系列方法最终会调用 Handler 的 enqueueMessage 方法，代码如下所示：
frameworks/base/core/java/android/os/Handler.java
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { // this 指的就是当前 Handler 对象，这里将 发送该消息的 Handler 对象封装到 msg 的 target 属性中 // 在 Looper 的 loop 方法中通过 msg.target 获取发送该消息的 Handler 对象，然后 // 通过 Handler 的 dispatchMessage 将该消息分发出去。 msg.target = this; if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis); }Handler 的 enqueueMessage 方法最终会调用 MessageQueue 的 enqueueMessage 方法将这条消息插入到消息队列中。
接下来我们分析 Handler 的 dispatchMessage 方法，代码如下所示：
frameworks/base/core/java/android/os/Handler.java
public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); } }Handler 的 dispatchMessage 方法处理消息的过程如下：
1）首先检查 Message 的 callback 是否为 null，不为 null 就通过 handleCallback 来处理消息。Message 的 callback 是一个Runnable 对象，实际上就是 Handler 的 post 方法所传递的 Runnable 参数。handleCallback 的逻辑也是很简单，如下所示。
frameworks/base/core/java/android/os/Handler.java
private static void handleCallback(Message message) { message.callback.run(); }2） 其次检査 mCallback 是否为 null ，不为 null 就调用 mCallback 的 handleMessage 方法来处理消息。Callback 是个接口，它的定义如下：
frameworks/base/core/java/android/os/Handler.java
/** * Callback interface you can use when instantiating a Handler to avoid * having to implement your own subclass of Handler. */ 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); }通过 Callback 可以采用如下方式来创建 Handler 对象：Handler handler = new Handler(callback)。那么 Callback 的意义是什么呢？源码里面的注释已经做了说明：可以用来创建一个Handler的实例但并不需要派生 Handler 的子类。在日常开发中，创建 Handler 最常见的方式就是派生一个 Handler 的子类并重写其 handleMessage 方法来处理具体的消息，而 Callback 给我们提供了另外一种使用 Handler 的方式，当我们不想派生子类时，就可以通过 Callback 来实现。
3）最后调用 Handler 的 handleMessage 方法来处理消息。
Handler 的 dispatchMessage 方法处理消息的流程如图2所示：
图2 Handler 处理消息的流程图
我们创建 Handler 的时候，一般使用的是默认构造方法 public Handler() ，这个方法最终会调用 public Handler(Callback callback, boolean async) 这个构造方法，代码如下所示：
frameworks/base/core/java/android/os/Handler.java
public Handler(Callback callback, boolean async) { ... // 获取当前线程的Looper 对象 mLooper = Looper.myLooper(); if (mLooper == null) { // 如果当前线程的Looper对象为空，则抛出异常。 throw new RuntimeException( "Can't create handler inside thread that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }2.5 Looper 的死循环为什么不会导致ANR
Looper 的 loop 方法是一个死循环，拿不到需要处理的 Message 就会阻塞，那在 UI 线程中为什么不会导致ANR？
首先我们来看造成ANR的原因：
1）当前的事件没有机会得到处理（即主线程正在处理前一个事件，没有及时的完成或者looper被某种原因阻塞住了）。
2）当前的事件正在处理，但没有及时完成。
接下来我们来看主线程 ActivityThread 的 main 方法，代码如下所示：
frameworks/base/core/java/android/app/AcctivityThread.java
public static void main(String[] args) { ... // 创建主线程的 Looper Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } if (false) { Looper.myLooper().setMessageLogging(new LogPrinter(Log.DEBUG, "ActivityThread")); } // End of event ActivityThreadMain. Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER); // 开始消息循环 Looper.loop(); throw new RuntimeException("Main thread loop unexpectedly exited"); }从 ActivityThread 的 main 方法可以看出，如果Looper 的 loop 方法没有死循环，那么 main 方法运行完 loop 方法之后抛出异常。
现在我们知道了消息循环的必要性，那为什么这个死循环不会造成ANR异常呢？
我们知道 Android 是由事件驱动的，looper.loop() 不断地接收事件、处理事件，每一个点击触摸或者说 Activity 的生命周期都是运行在 Looper 的控制之下，如果它停止了，应用也就停止了。只能是某一个消息或者说对消息的处理阻塞了 Looper.loop()而不是 Looper.loop() 阻塞它，这也就是我们为什么不能在UI线程中处理耗时操作的原因。主线程Looper从消息队列读取消息，当读完所有消息时，主线程阻塞。子线程往消息队列发送消息，唤醒主线程，主线程被唤醒只是为了读取消息，当消息读取完毕再次睡眠。因此 loop 的循环并不会对 CPU 性能有过多的消耗。
更多相关文章
- 单线程模型中Message、Handler、Message Queue、Looper之间的关
- Android中SQLite应用详解
- Android(安卓)要注意的内存占用问题
- Android(安卓)WindowManager与窗口管理
- 让洪水猛兽变成温顺小羊——浅谈Android线程池机制
- android中setVisibility方法无效的可能原因与解决办法
- Android(安卓)中的注解详细介绍
- 浅谈Java中Collections.sort对List排序的两种方法
- Python list sort方法的具体使用