前言
Handler 属于八股文中非常经典的一个考题了，导致这个知识点很多时候，考官都懒得问了；这玩意很久之前就看过，但是过了一段时间，就很容易忘记，但是处理内存泄漏，IdleHandler 之类的考点答案肯定很难忘。。。虽然考官很多时候不屑问，但是要是问到了，你忘了且不知道怎么回答，那就很尴尬了
鄙人也来炒个剩饭，力求通俗易懂的来描述下 Handler 机制的整个流程；相关知识点，画了一些流程图，时序图来展示其运行机制，力争让本文图文并茂！
文章中关键方法源码，可以直接点击方法名，跳转查看对应方法的源码
如果看了没收获，喷我！
总流程
开头需要建立个 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); }}...
复制代码
从上面源码可知，handler 的使用总的来说，分俩大类，细分三小类
收发一体
public class MainActivity extends AppCompatActivity { private TextView msgTv; private Handler mHandler = new Handler();
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); msgTv = findViewById(R.id.tv_msg);
//消息收发一体 new Thread(new Runnable() { @Override public void run() { String info = "第一种方式"; mHandler.post(new Runnable() { @Override public void run() { msgTv.setText(info); } }); } }).start(); }}
复制代码
收发分开
mCallback.handleMessage(msg)
public class MainActivity extends AppCompatActivity { private TextView msgTv; private Handler mHandler = new Handler(new Handler.Callback() { //接收消息,刷新UI @Override public boolean handleMessage(@NonNull Message msg) { if (msg.what == 1) { msgTv.setText(msg.obj.toString()); } //false 重写Handler类的handleMessage会被调用, true 不会被调用 return false; } });
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); msgTv = findViewById(R.id.tv_msg);
//发送消息 new Thread(new Runnable() { @Override public void run() { Message message = Message.obtain(); message.what = 1; message.obj = "第二种方式 --- 1"; mHandler.sendMessage(message); } }).start(); }}
复制代码
handleMessage(msg)
public class MainActivity extends AppCompatActivity { private TextView msgTv; private Handler mHandler = new Handler() { //接收消息,刷新UI @Override public void handleMessage(@NonNull Message msg) { super.handleMessage(msg); if (msg.what == 1) { msgTv.setText(msg.obj.toString()); } } };
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); msgTv = findViewById(R.id.tv_msg);
//发送消息 new Thread(new Runnable() { @Override public void run() { Message message = Message.obtain(); message.what = 1; message.obj = "第二种方式 --- 2"; mHandler.sendMessage(message); } }).start(); }}
复制代码
prepare 和 loop
大家肯定有印象，在子线程和子线程的通信中，就必须在子线程中初始化 Handler，必须这样写
new Thread(new Runnable() { @Override public void run() { Looper.prepare(); Handler handler = new Handler(); Looper.loop(); }});
复制代码
ActivityThread.java...public static void main(String[] args) { ... //主线程Looper Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } //主线程的loop开始循环 Looper.loop(); ...}...
复制代码
为什么要使用 prepare 和 loop？我画了个图，先让大家有个整体印象
上图的流程，鄙人感觉整体画的还是比较清楚的
总结下就是
Looper.prepare()：生成 Looper 对象，set 在 ThreadLocal 里
handler 构造函数：通过 Looper.myLooper()获取到 ThreadLocal 的 Looper 对象
Looper.loop()：内部有个死循环，开始事件分发了；这也是最复杂，干活最多的方法
具体看下每个步骤的源码，这里也会标定好链接，方便大家随时过去查看
Looper.java... public static void prepare() { prepare(true);}
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));}...
复制代码
Handler.java...@Deprecatedpublic Handler() { this(null, false);}
public Handler(@Nullable 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()); } }
mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread " + Thread.currentThread() + " that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async;}...
复制代码
Looper.java...public static @Nullable Looper myLooper() { return sThreadLocal.get();}...
复制代码
Looper.loop()：该方法分析，在分发消息里讲
精简了大量源码，详细的可以点击上面方法名
Message msg = queue.next()：遍历消息
msg.target.dispatchMessage(msg)：分发消息
msg.recycleUnchecked()：消息回收，进入消息池
Looper.java...public static void loop() { final Looper me = myLooper(); ... final MessageQueue queue = me.mQueue;
...
for (;;) { Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; }
... try { msg.target.dispatchMessage(msg); if (observer != null) { observer.messageDispatched(token, msg); } dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0; } catch (Exception exception) { if (observer != null) { observer.dispatchingThrewException(token, msg, exception); } throw exception; } finally { ThreadLocalWorkSource.restore(origWorkSource); if (traceTag != 0) { Trace.traceEnd(traceTag); } } ....
msg.recycleUnchecked(); }}...
复制代码
收发消息
收发消息的操作口都在 Handler 里，这是我们最直观的接触的点
下方的思维导图整体做了个概括
前置知识
在说发送和接受消息之前，必须要先解释下，Message 中一个很重要的属性：when
when 这个变量是 Message 中的，发送消息的时候，我们一般是不会设置这个属性的，实际上也无法设置，只有内部包才能访问写的操作；将消息加入到消息队列的时候会给发送的消息设置该属性。消息加入消息队列方法：enqueueMessage(...)
在我们使用 sendMessage 发送消息的时候，实际上也会调用 sendMessageDelayed 延时发送消息发放，不过此时传入的延时时间会默认为 0，来看下延时方法：sendMessageDelayed
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);}
复制代码
这地方调用了 sendMessageAtTime 方法，此处！做了一个时间相加的操作：SystemClock.uptimeMillis() + delayMillis
后面会将这个时间刻赋值给 when：when = SystemClock.uptimeMillis() + delayMillis
说明 when 代表的是开机到现在的一个时间刻，通俗的理解，when 可以理解为：现实时间的某个现在或未来的时刻（实际上 when 是个相对时刻，相对点就是开机的时间点）
发送消息
发送消息涉及到俩个方法：post(...)和 sendMessage(...)
post(Runnable)：发送和接受消息都在 post 中完成
sendMessage(msg)：需要自己传入 Message 消息对象
看下源码
使用 post 会自动会通过 getPostMessage 方法创建 Message 对象
在 enqueueMessage 中将生成的 Message 加入消息队列，注意
此方法给 msg 的 target 赋值当前 handler 之后，才进行将消息添加的消息队列的操作
msg.setAsynchronous(true)：设置 Message 属性为异步，默认都为同步；设置为异步的条件，需要手动在 Handler 构造方法里面设置
Handler.java...//postpublic final boolean post(@NonNull Runnable r) { return sendMessageDelayed(getPostMessage(r), 0);}
//生成Message对象private static Message getPostMessage(Runnable r) { Message m = Message.obtain(); m.callback = r; return m;}
//sendMessage方法public final boolean sendMessage(@NonNull Message msg) { return sendMessageDelayed(msg, 0);}
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);}
public boolean sendMessageAtTime(@NonNull 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);}
///将Message加入详细队列 private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg, long uptimeMillis) { //设置target msg.target = this; msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) { //设置为异步方法 msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis);}...
复制代码
enqueueMessage(...)：精简了一些代码，完整代码，可点击左侧方法名
Message 通过 enqueueMessage 加入消息队列
请明确：when = SystemClock.uptimeMillis() + delayMillis，when 代表的是一个时间刻度，消息进入到消息队列，是按照时间刻度排列的，时间刻度按照从小到大排列，也就是说消息在消息队列中：按照从现在到未来的循序排队
这地方有几种情况，记录下：mMessage 为当前消息分发到的消息位置
mMessage 为空，传入的 msg 则为消息链表头，next 置空
mMessage 不为空、消息队列中没有延时消息的情况：从当前分发位置移到链表尾，将传入的 msg 插到链表尾部，next 置空
mMessage 不为空、含有延时消息的情况：举个例子
A，B，C 消息依次发送，三者分边延时：3 秒，1 秒，2 秒 { A(3000)、B(1000)、C(2000) }
这是一种理想情况：三者依次进入，进入之间的时间差小到忽略，这是为了方便演示和说明
这种按照时间远近的循序排列，可以保证未延时或者延时时间较小的消息，能够被及时执行
在消息队列中的排列为：B ---> C ---> A
MessageQueue.java...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;}...
复制代码
接收消息
接受消息相对而言就简单多
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); }} ...
复制代码
handleCallback(msg)
触发条件：Message 消息中实现了 handleCallback 回调
现在基本上只能使用 post()方法了，setCallback(Runnable r) 被表明为 @UnsupportedAppUsage，被 hide 了，没法调用，如果使用反射倒是可以调用，但是没必要。。。
mCallback.handleMessage(msg)
触发条件
使用 sendMessage 方法发送消息（必须）
实现 Handler 的 Callback 回调
分发的消息，会在 Handler 中实现的回调中分发
handleMessage(msg)
触发条件
使用 sendMessage 方法发送消息（必须）
未实现 Handler 的 Callback 回调
实现了 Handler 的 Callback 回调，返回值为 false（mCallback.handleMessage(msg)）
需要重写 Handler 类的 handlerMessage 方法
分发消息
消息分发是在 loop()中完成的，来看看 loop()这个重要的方法
Looper.loop()：精简了巨量源码，详细的可以点击左侧方法名
Message msg = queue.next()：遍历消息
msg.target.dispatchMessage(msg)：分发消息
msg.recycleUnchecked()：消息回收，进入消息池
Looper.java...public static void loop() { final Looper me = myLooper(); ... final MessageQueue queue = me.mQueue; ... for (;;) { //遍历消息池,获取下一可用消息 Message msg = queue.next(); // might block ... try { //分发消息 msg.target.dispatchMessage(msg); ... } catch (Exception exception) { ... } finally { ... } .... //回收消息,进图消息池 msg.recycleUnchecked(); }}...
复制代码
遍历消息
遍历消息的关键方法肯定是下面这个
来看看这个 Message 中的 next()方法吧
MessageQueue.java...Message next() { final long ptr = mPtr; ...
int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { ... //阻塞，除非到了超时时间或者唤醒 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; // 这是关于同步屏障（SyncBarrier）的知识，放在同步屏障栏目讲 if (msg != null && msg.target == null) { do { prevMsg = msg; msg = msg.next; } while (msg != null && !msg.isAsynchronous()); } if (msg != null) { if (now < msg.when) { //每个消息处理有耗时时间，之间存在一个时间间隔（when是将要执行的时间点）。 //如果当前时刻还没到执行时刻（when），计算时间差值，传入nativePollOnce定义唤醒阻塞的时间 nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE); } else { mBlocked = false; //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了 //mMessage仍处于未分发的同步消息位置 if (prevMsg != null) { prevMsg.next = msg.next; } else { mMessages = msg.next; } msg.next = null; if (DEBUG) Log.v(TAG, "Returning message: " + msg); msg.markInUse(); //返回符合条件的Message return msg; } } else { // No more messages. nextPollTimeoutMillis = -1; }
//这是处理调用IdleHandler的操作,有几个条件 //1、当前消息队列为空(mMessages == null) //2、已经到了可以分发下一消息的时刻（now < mMessages.when） 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); }
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; }}
复制代码
总结下源码里面表达的意思
next()内部是个死循环，你可能会疑惑，只是拿下一节点的消息，为啥要死循环？
为了执行延时消息以及同步屏障等等，这个死循环是必要的
nativePollOnce 阻塞方法：到了超时时间(nextPollTimeoutMillis)或者通过唤醒方式(nativeWake)，会解除阻塞状态
nextPollTimeoutMillis 大于等于零，会规定在此段时间内休眠，然后唤醒
消息队列为空时，nextPollTimeoutMillis 为-1，进入阻塞；重新有消息进入队列，插入头结点的时候会触发 nativeWake 唤醒方法
如果 msg.target == null 为零，会进入同步屏障状态
会将 msg 消息死循环到末尾节点，除非碰到异步方法
如果碰到同步屏障消息，理论上会一直死循环上面操作，并不会返回消息，除非，同步屏障消息被移除消息队列
当前时刻和返回消息的 when 判定
消息 when 代表的时刻：一般都是发送消息的时刻，如果是延时消息，就是 发送时刻+延时时间
当前时刻小于返回消息的 when：进入阻塞，计算时间差，给 nativePollOnce 设置超时时间，超时时间一到，解除阻塞，重新循环取消息
当前时刻大于返回消息的 when：获取可用消息返回
消息返回后，会将 mMessage 赋值为返回消息的下一节点（只针对不涉及同步屏障的同步消息）
这里简单的画了个流程图
分发消息
分发消息主要的代码是： msg.target.dispatchMessage(msg);
也就是说这是 Handler 类中的 dispatchMessage(msg)方法
public void dispatchMessage(@NonNull Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); }}
复制代码
可以看到，这里的代码，在收发消息栏目的接受消息那块已经说明过了，这里就无须重复了
消息池
msg.recycleUnchecked()是处理完成分发的消息，完成分发的消息并不会被回收掉，而是会进入消息池，等待被复用
recycleUnchecked()：回收消息的代码还是蛮简单的，来分析下
首先会将当前已经分发处理的消息，相关属性全部重置，flags 也标志可用
消息池的头结点会赋值为当前回收消息的下一节点，当前消息成为消息池头结点
简言之：回收消息插入消息池，当做头结点
需要注意的是：消息池有最大的容量，如果消息池大于等于默认设置的最大容量，将不再接受回收消息入池
默认最大容量为 50： MAX_POOL_SIZE = 50
Message.java...void recycleUnchecked() { // Mark the message as in use while it remains in the recycled object pool. // Clear out all other details. 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.java...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();}
复制代码
来看下从消息池取一个消息的图示
IdleHandler
在 MessageQueue 类中的 next 方法里，可以发现有关于对 IdleHandler 的处理，大家可千万别以为它是什么 Handler 特殊形式之类，这玩意就是一个 interface，里面抽象了一个方法，结构非常的简单
MessageQueue.java...Message next() { final long ptr = mPtr; ...
int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { ... //阻塞，除非到了超时时间或者唤醒 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; ... //这是处理调用IdleHandler的操作,有几个条件 //1、当前消息队列为空(mMessages == null) //2、未到到了可以分发下一消息的时刻（now < mMessages.when） //3、pendingIdleHandlerCount < 0表明：只会在此for循环里执行一次处理IdleHandler操作 if (pendingIdleHandlerCount < 0 && (mMessages == null || now < mMessages.when)) { pendingIdleHandlerCount = mIdleHandlers.size(); } if (pendingIdleHandlerCount <= 0) { mBlocked = true; continue; }
if (mPendingIdleHandlers == null) { mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)]; } mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers); }
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); } } }
pendingIdleHandlerCount = 0; nextPollTimeoutMillis = 0; }}
复制代码
实际上从上面的代码里面，可以分析出很多信息
IdleHandler 相关信息
调用条件
当前消息队列为空(mMessages == null) 或 未到分发返回消息的时刻
在每次获取可用消息的死循环中，IdleHandler 只会被处理一次：处理一次后 pendingIdleHandlerCount 为 0，其循环不可再被执行
实现了 IdleHandler 中的 queueIdle 方法
返回 false，执行后，IdleHandler 将会从 IdleHandler 列表中移除，只能执行一次：默认 false
返回 true，每次分发返回消息的时候，都有机会被执行：处于保活状态
IdleHandler 代码
MessageQueue.java ... /** * Callback interface for discovering when a thread is going to block * waiting for more messages. */ public static interface IdleHandler { /** * Called when the message queue has run out of messages and will now * wait for more. Return true to keep your idle handler active, false * to have it removed. This may be called if there are still messages * pending in the queue, but they are all scheduled to be dispatched * after the current time. */ boolean queueIdle(); } public void addIdleHandler(@NonNull IdleHandler handler) { if (handler == null) { throw new NullPointerException("Can't add a null IdleHandler"); } synchronized (this) { mIdleHandlers.add(handler); } } public void removeIdleHandler(@NonNull IdleHandler handler) { synchronized (this) { mIdleHandlers.remove(handler); } }
复制代码
怎么使用 IdleHandler 呢？
这里简单写下用法，可以看看，留个印象
public class MainActivity extends AppCompatActivity { private TextView msgTv; private Handler mHandler = new Handler(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); msgTv = findViewById(R.id.tv_msg); //添加IdleHandler实现类 mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是IdleHandler")); mHandler.getLooper().getQueue().addIdleHandler(new InfoIdleHandler("我是大帅比")); //消息收发一体 new Thread(new Runnable() { @Override public void run() { String info = "第一种方式"; mHandler.post(new Runnable() { @Override public void run() { msgTv.setText(info); } }); } }).start(); } //实现IdleHandler类 class InfoIdleHandler implements MessageQueue.IdleHandler { private String msg; InfoIdleHandler(String msg) { this.msg = msg; } @Override public boolean queueIdle() { msgTv.setText(msg); return false; } } }
复制代码
总结
通俗的讲：当所有消息处理完了 或者 你发送了延迟消息，在这俩种空闲时间里，都满足执行 IdleHandler 的条件
这地方需要说明下，如果延迟消息时间设置过短的；IdleHandler 可能会在发送消息后执行，毕竟运行到 next 这步也需要一点时间，延迟时间设置长点，你就可以很明显得发现，IdleHandler 在延迟的空隙间执行了！
从其源码上，可以看出来，IdlerHandler 是在消息分发的空闲时刻，专门用来处理相关事物的
同步屏障
来到最复杂的模块了
在理解同步屏障的概念前，我们需要先搞懂几个前置知识
前置知识
同步和异步消息
什么是同步消息？什么是异步消息？
讲真的，异步消息和同步消息界定，完成是通过一个方法去界定的
isAsynchronous()：来分析下
FLAG_ASYNCHRONOUS = 1 << 1：所以 FLAG_ASYNCHRONOUS 为 2
同步消息：flags 为 0 或者 1 的时候，isAsynchronous 返回 false，此时该消息标定为同步消息
flags 为 0，1：同步消息
异步消息：理论上只要按照位操作，右往左，第二位为 1 的数，isAsynchronous 返回 true；但是，Message 里面基本只使用了：0，1，2，可得出结论
flags 为 2：异步消息
public boolean isAsynchronous() { return (flags & FLAG_ASYNCHRONOUS) != 0;}
复制代码
msg.setAsynchronous(true);
public void setAsynchronous(boolean async) { if (async) { flags |= FLAG_ASYNCHRONOUS; } else { flags &= ~FLAG_ASYNCHRONOUS; }}
复制代码
Message msg = Message.obtain();//设置异步消息标记msg.setAsynchronous(true);
复制代码
默认消息类型
我们正常情况下，很少会使用setAsynchronous方法的，那么在不使用该方法的时候，消息的默认类型是什么呢？
在生成消息，然后发送消息的时候，都会经过下述方法
enqueueMessage：正常发送消息（post、延迟和非延迟之类），都会经过此方法
因为发送的所有消息都会经过 enqueueMessage 方法，然后加入消息队列，可以看见所有的消息都被处理过
msg.target = this
这地方给 Message 类的 target 赋值了！
说明：只要使用 post 或 sendMessage 之类发送消息，其消息就绝不可能是同步屏障消息！
关于同步异步，可以看见和 mAsynchronous 息息相关
只要 mAsynchronous 为 true 的话，我们的消息都会异步消息
只要 mAsynchronous 为 false 的话，我们的消息都会同步消息
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,long uptimeMillis) { msg.target = this; msg.workSourceUid = ThreadLocalWorkSource.getUid();
if (mAsynchronous) { msg.setAsynchronous(true); } return queue.enqueueMessage(msg, uptimeMillis);}
复制代码
public Handler(@Nullable 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()); } }
mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread " + Thread.currentThread() + " that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async;}
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) { mLooper = looper; mQueue = looper.mQueue; mCallback = callback; mAsynchronous = async;}
复制代码
public Handler() { this(null, false);}
public Handler(@NonNull Looper looper) { this(looper, null, false);}
public Handler(@NonNull Looper looper, @Nullable Callback callback) { this(looper, callback, false);}
复制代码
生成同步屏障消息
在 next 方法中发现，target 为 null 的消息被称为同步屏障消息，那他为啥叫同步屏障消息呢？
MessageQueue.java...@UnsupportedAppUsage@TestApipublic int postSyncBarrier() { return postSyncBarrier(SystemClock.uptimeMillis());} 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; }}
复制代码
mMessage 这个变量，表明是将要被处理的消息，将要被返回的消息，也可以认为，他是未处理消息队列的头结点消息
关于同步屏障消息
从消息池取一个可用消息
这地方有个很有意思的循环操作，这 while 操作的，会将 mMessages 头结点赋值给 p 变量，将 p 节点移到当前时刻消息的下一节点
头结点（mMessage）是否为空
不为空：因为上面的循环操作，会让 p 节点的消息，肯定是刚好大于当前时间刻，p 节点的上一节点消息为当前时刻过去时刻的消息，此时！咱们的同步屏障消息 msg，就插在这俩者之间！
为空：成为头结点
同步屏障消息是直接插到消息队列，他没有设置 target 属性且不经过 enqueueMessage 方法，故其 target 属性为 null
总结下：
同步屏障消息插入消息队列的规律，和上面正常发送消息插入基本是一致的；如果消息队列有延时消息，延时消息的时刻大于目前的时刻，同步消息会在这些延时消息之前。
OK，同步屏障消息插入，基本可以理解为：正常的非延时消息插入消息队列！
同步屏障流程
MessageQueue.java...Message next() { final long ptr = mPtr; ...
int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { ... //阻塞，除非到了超时时间或者唤醒 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; // 这是关于同步屏障（SyncBarrier）的逻辑块 if (msg != null && msg.target == null) { do { prevMsg = msg; msg = msg.next; } while (msg != null && !msg.isAsynchronous()); } if (msg != null) { if (now < msg.when) { //每个消息处理有耗时时间，之间存在一个时间间隔（when是将要执行的时间点）。 //如果当前时刻还没到执行时刻（when），计算时间差值，传入nativePollOnce定义唤醒阻塞的时间 nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE); } else { mBlocked = false; //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了 //mMessage仍处于未分发的同步消息位置 if (prevMsg != null) { prevMsg.next = msg.next; } else { mMessages = msg.next; } msg.next = null; if (DEBUG) Log.v(TAG, "Returning message: " + msg); msg.markInUse(); //返回符合条件的Message return msg; } } else { // No more messages. nextPollTimeoutMillis = -1; } ... } ... }}
复制代码
去掉大量我们无需关注的代码，发现这也没啥嘛，就是一堆 if eles for 之类的，来分析分析
Message msg = mMessages：这步赋值是非常重要的，表示即使我们对 msg 一顿操作，mMessage 还是保留消息队列头结点消息的位置
msg.target == null：遇到同步屏障消息
首先是一个 while 循环，内部逻辑，不断将 msg 节点的位置后移
结束 while 的俩个条件
msg 移到尾结点，也就是移到了消息队列尾结点，将自身赋值为 null（尾结点的 next）
遇上标记为异步的消息，放行该消息进行后续分发
分析下，俩个放行条件产生的不同影响
消息队列不含异步消息
当我们在同步屏障逻辑里面，将 msg 自身移到尾结点，并赋值为 null（尾结点的 next）
msg 为 null，是无法进行后续分发操作，会重新进行循环流程
mMessage 头结点重新将自身位置赋值给 msg，继续上述的重复过程
可以发现，上述逻辑确实起到了同步屏障的作用，屏蔽了其所有后续同步消息的分发；只有移除消息队列中的该条同步屏障消息，才能继续进行同步消息的分发
消息队列含有异步消息
消息队列中如果有异步消息，同步屏障的逻辑会放行异步消息
同步屏障里面堆 prevMsg 赋值了！请记住在整个方法里面，只有同步屏障逻辑里面堆 prevMsg 赋值了！这个参数为 null 与否，对消息队列节点影响很大
prevMsg 为空：会直接将 msg 的 next 赋值给 mMessage；说明分发完消息后，会直接移除头结点，将头结点的下一节点赋值为头结点
prevMsg 不为空：不会对 mMessage 投节点操作；会将分发消息的上一节点的下一节点位置，换成分发节点的下一节点，有点绕
通过上面分析，可知；异步消息分发完后，会将其直接从消息队列中移除，头结点位置不变
文字写了一大堆，我也是尽可能详细描述，同步屏障逻辑代码块会产生的影响，整个图，加深下印象！
同步屏障作用
那么这个同步屏障有什么作用呢？
有个急需的问题，就是什么地方用到了 postSyncBarrier(long when)方法，这个方法对外是不暴露的，只有内部包能够调用
搜索了整个源码包，发现只有几个地方使用了它，剔除测试类，MessageQueue 类，有作用的就是：ViewRootImpl 类和 Device 类
Device 类
pauseEvents()：Device 内部涉及的是打开设备的时候，会添加一个同步屏障消息，屏蔽后续所有的同步消息处理
pauseEvents()是 Device 类中私有内部类 DeviceHandler 的方法
这说明，我们无法调用这个方法；事实上，我们连 Device 类都无法调用，Device 属于被隐藏的类，和他同一目录的还有 Event 和 Hid，这些类系统都不想对外暴露
这就很鸡贼了，说明插入同步屏障的消息的方法，系统确实不想对外暴露；当然不包括非常规方法：反射
同步屏障添加：开机时，添加同步屏障
Device.java ... private class DeviceHandler extends Handler { ... @Override public void handleMessage(Message msg) { switch (msg.what) { case MSG_OPEN_DEVICE: ... pauseEvents(); break; ... } } public void pauseEvents() { mBarrierToken = getLooper().myQueue().postSyncBarrier(); } public void resumeEvents() { getLooper().myQueue().removeSyncBarrier(mBarrierToken); mBarrierToken = 0; } }
复制代码
Device.java ... private class DeviceHandler extends Handler { ... public void pauseEvents() { mBarrierToken = getLooper().myQueue().postSyncBarrier(); } public void resumeEvents() { getLooper().myQueue().removeSyncBarrier(mBarrierToken); mBarrierToken = 0; } } private class DeviceCallback { public void onDeviceOpen() { mHandler.resumeEvents(); } .... }
复制代码
Device 中使用同步屏障整体过程比较简单，这里简单描述下
打开设备时，会发送一个同步屏障消息，屏蔽后续所有同步消息
完成开机后，移除同步屏障消息
总结：很明显，这是尽量的提升打开设备速度，不被其它次等重要的事件干扰
ViewRootImpl 类
该栏目的分析，必须引用一个非常重要的结论，给出该结论的文章：源码分析_Android UI何时刷新_Choreographer
ViewRootImpl.java ... void scheduleTraversals() { if (!mTraversalScheduled) { mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier(); mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); notifyRendererOfFramePending(); pokeDrawLockIfNeeded(); } }
复制代码
结论：源码分析_Android UI何时刷新_Choreographer
关于上面的方法的分析，整体流程比较麻烦，涉及到整个刷新过程的分析
这边前辈的文章分析完 UI 刷新流程，给出了一个非常重要的结论
我们调用 View 的 requestLayout 或者 invalidate 时，最终都会触发 ViewRootImp 执行 scheduleTraversals()方法。这个方法中 ViewRootImp 会通过 Choreographer 来注册个接收 Vsync 的监听，当接收到系统体层发送来的 Vsync 后我们就执行 doTraversal()来重新绘制界面。通过上面的分析我们调用 invalidate 等刷新操作时，系统并不会立即刷新界面，而是等到 Vsync 消息后才会刷新页面。
我们这边已经有了前辈给出的结论，我们知道了界面刷新（requestLayout 或者 invalidate）的过程一定会触发 scheduleTraversals()方法，这说明会添加同步屏障消息，那肯定有移除同步屏障消息的步骤，这个步骤很有可能存在 doTraversal()方法中，来看下这个方法
void doTraversal() { if (mTraversalScheduled) { mTraversalScheduled = false; mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
if (mProfile) { Debug.startMethodTracing("ViewAncestor"); }
performTraversals();
if (mProfile) { Debug.stopMethodTracing(); mProfile = false; } }}
复制代码
final TraversalRunnable mTraversalRunnable = new TraversalRunnable(); void scheduleTraversals() { if (!mTraversalScheduled) { ... mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); ... } } final class TraversalRunnable implements Runnable { @Override public void run() { doTraversal(); } }
复制代码
postCallback 是 Choreographer 类中方法，该类涉及巨多的消息传递，而且都是使用了异步消息setAsynchronous(true)，这些都是和界面刷新相关，所以都是优先处理，完整的流程可以看上面贴的文章
postCallback 的核心就是让 DisplayEventReceiver 注册了个 Vsync 的通知，后期收到送来的 Vsync 后，我们就执行 doTraversal()来重新绘制界面
总结
调用 View 的 requestLayout 或者 invalidate 时，最终都会执行 scheduleTraversals()，此时会在主线程消息队列中插入一个同步屏障消息（停止所有同步消息分发），会将 mTraversalRunnable 添加到 mCallbackQueues 中，并注册接收 Vsync 的监听，当接受到 Vsync 通知后，会发送一个异步消息，触发遍历执行 mCallbackQueues 的方法，这会执行我们添加的回调 mTraversalRunnable，从而执行 doTraversal()，此时会移除主线程消息队列中同步屏障消息，最后执行绘制操作
调用 requestLayout 或者 invalidate 时，会在主线程消息队列中插入一个同步屏障消息，同时注册接收 Vsync 的监听；当接受到 Vsync 通知，会发送一个异步消息，执行真正的绘制事件：此时会移除消息队列中的同步屏障消息，然后才会执行绘制操作
总结
消息插入对比
有个很重要的事情，我们再来看下：正常发送消息和同步屏障消息插入消息队列直接的区别，见下图
取消息：关于取消息，都是取的 mMessage，可以理解为，取消息队列的头结点
非延时消息在同步屏障消息之前发送，都会排在同步屏障消息之前
延时消息，如果时刻大于发送同步屏障消息的时刻，会排在同步屏障消息之后
Vsync
总结
相关总结
同步屏障能确保消息队列中的异步消息，会被优先执行
鉴于正常消息和同步屏障消息插入消息队列的区别：同步屏障能够及时的屏障队列中的同步消息
某些极端场景：发送的消息，在分发的时候，可能会存一帧延时
极端场景：Vsync 信号到来之后，立马执行了 RequestLayout 等操作
同步屏障能确保在 UI 刷新中：Vsync 信号到来后，能够立马执行真正的绘制页面操作
同步消息和异步消息使用建议
在正常的情况，肯定不建议使用异步消息，此处假设一个场景：因为某种需求，你发送了大量的异步消息，由于消息进入消息队列的特殊性，系统发送的异步消息，也只能乖乖的排在你的异步消息后面，假设你的异步消息占据了大量的时间片，甚至占用了几帧，导致系统 UI 刷新的异步消息无法被及时执行，此时很有可能发生掉帧
当然，如果你能看明白这个同步屏障栏目所写的东西，相信什么时候设置消息为异步，心中肯定有数
考点
上面源码基本就分析到这边了，咱们看看能根据这些知识点，能提一些什么问题呢？
一个小知识
我逛一些论坛的时候，发现有人：对 Handler 怎么在主线程和子线程进行数据交互的原理，感到迷惑。
如果看完这整篇，或许你的心里已经有了答案，为了更加明确这个知识，我还是在这里总结下吧！
主线程和子线程通过 handler 交互，交互的载体是通过 Message 这个对象，实际上我们在子线程发送的所有消息，都会加入到主线程的消息队列中，然后主线程分发这些消息，这个就很容易做到俩个线程信息的交互。
看到这里，你可能有疑问了，我从子线程发送的消息，怎么就加到了主线程的消息队列里呢？？？
大家可以看看你自己的代码，你的 handler 对象是不是在主线程初始的？子线程发送消息，是不是通过这个 handler 发送的？
这就很简单了，handler 只需要把发送的消息，加到自身持有的 Looper 对象的 MessageQueue 里面（mLooper 变量）就 ok 了
所以，你在哪个线程里面初始化 Handler 对象，在不同的线程中，使用这个对象发送消息；都会在你初始化 Handler 对象的线程里分发消息
1、先来个自己想的问题：Handler 中主线程的消息队列是否有数量上限？为什么？
这问题整的有点鸡贼，可能会让你想到，是否有上限这方面？而不是直接想到到上限数量是多少？
解答：Handler 主线程的消息队列肯定是有上限的，每个线程只能实例化一个 Looper 实例（上面讲了，Looper.prepare 只能使用一次），不然会抛异常，消息队列是存在 Looper()中的，且仅维护一个消息队列
重点：每个线程只能实例化一次 Looper()实例、消息队列存在 Looper 中
拓展：MessageQueue 类，其实都是在维护 mMessage，只需要维护这个头结点，就能维护整个消息链表
2、Handler 中有 Loop 死循环，为什么没有卡死？为什么没有发生 ANR？
先说下 ANR：5 秒内无法响应屏幕触摸事件或键盘输入事件；广播的onReceive()函数时 10 秒没有处理完成；前台服务 20 秒内，后台服务在 200 秒内没有执行完毕；ContentProvider 的 publish 在 10s 内没进行完。所以大致上 Loop 死循环和 ANR 联系不大，问了个正确的废话，所以触发事件后，耗时操作还是要放在子线程处理，handler 将数据通讯到主线程，进行相关处理。
线程实质上是一段可运行的代码片，运行完之后，线程就会自动销毁。当然，我们肯定不希望主线程被 over，所以整一个死循环让线程保活。
为什么没被卡死：在事件分发里面分析了，在获取消息的 next()方法中，如果没有消息，会触发 nativePollOnce 方法进入线程休眠状态，释放 CPU 资源，MessageQueue 中有个原生方法 nativeWake 方法，可以解除 nativePollOnce 的休眠状态，ok，咱们在这俩个方法的基础上来给出答案
当消息队列中消息为空时，触发 MessageQueue 中的 nativePollOnce 方法，线程休眠，释放 CPU 资源
消息插入消息队列，会触发 nativeWake 唤醒方法，解除主线程的休眠状态
当插入消息到消息队列中，为消息队列头结点的时候，会触发唤醒方法
当插入消息到消息队列中，在头结点之后，链中位置的时候，不会触发唤醒方法
综上：消息队列为空，会阻塞主线程，释放资源；消息队列为空，插入消息时候，会触发唤醒机制
这套逻辑能保证主线程最大程度利用 CPU 资源，且能及时休眠自身，不会造成资源浪费
本质上，主线程的运行，整体上都是以事件（Message）为驱动的
3、为什么不建议在子线程中更新 UI？
多线程操作，在 UI 的绘制方法表示这不安全，不稳定。
假设一种场景：我会需要对一个圆进行改变，A 线程将圆增大俩倍，B 改变圆颜色。A 线程增加了圆三分之一体积的时候，B 线程此时，读取了圆此时的数据，进行改变颜色的操作；最后的结果，可能会导致，大小颜色都不对。。。
4、可以让自己发送的消息优先被执行吗？原理是什么？
这个问题，我感觉只能说：在有同步屏障的情况下是可以的。
同步屏障作用：在含有同步屏障的消息队列，会及时的屏蔽消息队列中所有同步消息的分发，放行异步消息的分发。
在含有同步屏障的情况，我可以将自己的消息设置为异步消息，可以起到优先被执行的效果。
5、子线程和子线程使用 Handler 进行通信，存在什么弊端？
子线程和子线程使用 Handler 通信，某个接受消息的子线程肯定使用实例化 handler，肯定会有 Looper 操作，Looper.loop()内部含有一个死循环，会导致线程的代码块无法被执行完，该线程始终存在。
如果在完成通信操作，我们一般可以使用： mHandler.getLooper().quit() 来结束分发操作
6、Handler 中的阻塞唤醒机制？
这个阻塞唤醒机制是基于 Linux 的 I/O 多路复用机制 epoll 实现的，它可以同时监控多个文件描述符，当某个文件描述符就绪时，会通知对应程序进行读/写操作.
MessageQueue 创建时会调用到 nativeInit，创建新的 epoll 描述符，然后进行一些初始化并监听相应的文件描述符，调用了 epoll_wait 方法后，会进入阻塞状态；nativeWake 触发对操作符的 write 方法，监听该操作符被回调，结束阻塞状态
详细请查看：同步屏障？阻塞唤醒？和我一起重读 Handler 源码
7、什么是 IdleHandler？什么条件下触发 IdleHandler？
IdleHandler 的本质就是接口，为了在消息分发空闲的时候，能处理一些事情而设计出来的
具体条件：消息队列为空的时候、发送延时消息的时候
8、消息处理完后，是直接销毁吗？还是被回收？如果被回收，有最大容量吗？
Handler 存在消息池的概念，处理完的消息会被重置数据，采用头插法进入消息池，取的话也直接取头结点，这样会节省时间
消息池最大容量为 50，达到最大容量后，不再接受消息进入
9、不当的使用 Handler，为什么会出现内存泄漏？怎么解决？
先说明下，Looper 对象在主线程中，整个生命周期都是存在的，MessageQueue 是在 Looper 对象中，也就是消息队列也是存在在整个主线程中；我们知道 Message 是需要持有 Handler 实例的，Handler 又是和 Activity 存在强引用关系
存在某种场景：我们关闭当前 Activity 的时候，当前 Activity 发送的 Message，在消息队列还未被处理，Looper 间接持有当前 activity 引用，因为俩者直接是强引用，无法断开，会导致当前 Activity 无法被回收
思路：断开俩者之间的引用、处理完分发的消息，消息被处理后，之间的引用会被重置断开
解决：使用静态内部类弱引 Activity、清空消息队列
最后
写这篇文章加上思维导图，也大概整了十三来张图，我真的尽力了！
评论