前言

Handler属于八股文中非常经典的一个考题了，导致这个知识点很多时候，考官都懒得问了；这玩意很久之前就看过，但是过了一段时间，就很容易忘记，但是处理内存泄漏，IdleHandler之类的考点答案肯定很难忘。。。虽然考官很多时候不屑问，但是要是问到了，你忘了且不知道怎么回答，那就很尴尬了

img

鄙人也来炒个剩饭，力求通俗易懂的来描述下Handler机制的整个流程；相关知识点，画了一些流程图，时序图来展示其运行机制，力争让本文图文并茂！

文章中关键方法源码，可以直接点击方法名，跳转查看对应方法的源码

如果看了没收获，喷我！

img

总流程

开头需要建立个handler作用的总体印象，下面画了一个总体的流程图

Handler总流程

从上面的流程图可以看出，总体上是分几个大块的

Looper.prepare()、Handler()、Looper.loop() 总流程
收发消息
分发消息

相关知识点大概涉及到这些，下面详细讲解下！

需要详细的查看该思维导图，请右键下载后查看

Handler流程

使用

先来看下使用，不然源码，原理图搞了一大堆，一时想不起怎么用的，就尴尬了

使用很简单，此处仅做个展示，大家可以熟悉下

演示代码尽量简单是为了演示，关于静态内部类持有弱引用或者销毁回调中清空消息队列之类，就不在此处展示了

来看下消息处理的分发方法：dispatchMessage(msg)

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的使用总的来说，分俩大类，细分三小类

收发消息一体
- handleCallback(msg)
收发消息分开
- mCallback.handleMessage(msg)
- handleMessage(msg)

收发一体

handleCallback(msg)
使用post形式，收发都是一体，都在post()方法中完成，此处不需要创建Message实例等，post方法已经完成这些操作

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)

实现Callback接口

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)

重写Handler类的handlerMessage(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，必须这样写

prepare在前，loop在后，固化印象了

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？我画了个图，先让大家有个整体印象

Handler---Looper

上图的流程，鄙人感觉整体画的还是比较清楚的
总结下就是
- Looper.prepare()：生成Looper对象，set在ThreadLocal里
- handler构造函数：通过Looper.myLooper()获取到ThreadLocal的Looper对象
- Looper.loop()：内部有个死循环，开始事件分发了；这也是最复杂，干活最多的方法

具体看下每个步骤的源码，这里也会标定好链接，方便大家随时过去查看

Looper.prepare()
- 可以看见，一个线程内，只能使用一次prepare()，不然会报异常的

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()
- 这里通过Looper.myLooper() ---> sThreadLocal.get()拿到了Looper实例

Handler.java
...
@Deprecated
public 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里，这是我们最直观的接触的点

下方的思维导图整体做了个概括

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

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
...
//post
public 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;
}
...

来看下发送的消息插入消息队列的图示

消息插入消息队列

接收消息

接受消息相对而言就简单多

dispatchMessage(msg)：关键方法呀

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 msg = queue.next()：Message类中的next()方法；当然这必须要配合外层for（无限循环）来使用，才能遍历消息队列

来看看这个Message中的next()方法吧

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赋值为返回消息的下一节点（只针对不涉及同步屏障的同步消息）

这里简单的画了个流程图

Handler---消息遍历

分发消息

分发消息主要的代码是： msg.target.dispatchMessage(msg);

也就是说这是Handler类中的dispatchMessage(msg)方法

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

来看下消息池回收消息图示

Handler---消息池（存）

既然有将已使用的消息回收到消息池的操作，那肯定有获取消息池里面消息的方法了

obtain()：代码很少，来看看
- 如果消息池不为空：直接取消息池的头结点，被取走头结点的下一节点成为消息池的头结点
- 如果消息池为空：直接返回新的Message实例

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

来看下从消息池取一个消息的图示

Handler---消息池（取）

IdleHandler

在MessageQueue类中的next方法里，可以发现有关于对IdleHandler的处理，大家可千万别以为它是什么Handler特殊形式之类，这玩意就是一个interface，里面抽象了一个方法，结构非常的简单

next()：精简了大量源码，只保留IdleHandler处理的相关逻辑；完整的点击左侧方法名

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

setAsynchronous(boolean async)：这个方法会影响flags的值
- 因为flags是int类型，没有赋初值，故其初始值为0
- setAsynchronous传入true的话，或等于操作，会将flags数值改成2

msg.setAsynchronous(true);

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

怎么生成异步消息？so easy

Message msg = Message.obtain();
//设置异步消息标记
msg.setAsynchronous(true);

一般来说：默认消息不做设置，flags都为0，故默认为同步消息，下面栏目将分析下setAsynchronous在何处使用了

默认消息类型

我们正常情况下，很少会使用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);
}

mAsynchronous在哪设置的呢？
- 这是在构造方法里面给mAsynchronous赋值了

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

总结下
- 这下清楚了！如果不做特殊设置的话：默认消息都是同步消息
- 默认消息都会给其target变量赋值：默认消息都不是同步屏障消息

生成同步屏障消息

在next方法中发现，target为null的消息被称为同步屏障消息，那他为啥叫同步屏障消息呢？

postSyncBarrier(long when)
- sync：同步 barrier：屏障，障碍物 ---> 同步屏障
- 同步屏障实际挺能代表其含义的，它能屏蔽消息队列中后续所有的同步方法分发

MessageQueue.java
...
@UnsupportedAppUsage
@TestApi
public 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，同步屏障消息插入，基本可以理解为：正常的非延时消息插入消息队列！

同步屏障消息插入消息队列流程图

同步屏障入消息队列

同步屏障流程

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

去掉大量我们无需关注的代码，发现这也没啥嘛，就是一堆if eles for之类的，来分析分析

Message msg = mMessages：这步赋值是非常重要的，表示即使我们对msg一顿操作，mMessage还是保留消息队列头结点消息的位置
msg.target == null：遇到同步屏障消息
1. 首先是一个while循环，内部逻辑，不断将msg节点的位置后移
2. 结束while的俩个条件
  - msg移到尾结点，也就是移到了消息队列尾结点，将自身赋值为null（尾结点的next）
  - 遇上标记为异步的消息，放行该消息进行后续分发
分析下，俩个放行条件产生的不同影响
1. 消息队列不含异步消息
  - 当我们在同步屏障逻辑里面，将msg自身移到尾结点，并赋值为null（尾结点的next）
  - msg为null，是无法进行后续分发操作，会重新进行循环流程
  - mMessage头结点重新将自身位置赋值给msg，继续上述的重复过程
  - 可以发现，上述逻辑确实起到了同步屏障的作用，屏蔽了其所有后续同步消息的分发；只有移除消息队列中的该条同步屏障消息，才能继续进行同步消息的分发
2. 消息队列含有异步消息
  - 消息队列中如果有异步消息，同步屏障的逻辑会放行异步消息
  - 同步屏障里面堆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

scheduleTraversals()：非常重要的方法

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()方法中，来看下这个方法

doTraversal()：removeSyncBarrier！我giao！果然在这地方！
- 这地方做了俩件事：移除同步屏障（removeSyncBarrier）、绘制界面（performTraversals）

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }

        performTraversals();

        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}

doTraversal()是怎么被调用呢？

调用：mTraversalRunnable在scheduleTraversals()中使用了

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()来重新绘制界面

总结

通过上面的对ViewRootImpl说明，需要来总结下同步屏障对界面绘制过程的影响
详细版总结（不讲人话版）

调用View的requestLayout或者invalidate时，最终都会执行scheduleTraversals()，此时会在主线程消息队列中插入一个同步屏障消息（停止所有同步消息分发），会将mTraversalRunnable添加到mCallbackQueues中，并注册接收Vsync的监听，当接受到Vsync通知后，会发送一个异步消息，触发遍历执行mCallbackQueues的方法，这会执行我们添加的回调mTraversalRunnable，从而执行doTraversal()，此时会移除主线程消息队列中同步屏障消息，最后执行绘制操作

通俗版总结

调用requestLayout或者invalidate时，会在主线程消息队列中插入一个同步屏障消息，同时注册接收Vsync的监听；当接受到Vsync通知，会发送一个异步消息，执行真正的绘制事件：此时会移除消息队列中的同步屏障消息，然后才会执行绘制操作

下面给不讲人话版画了个流转图示

Handler---同步屏障作用

总结

消息插入对比

有个很重要的事情，我们再来看下：正常发送消息和同步屏障消息插入消息队列直接的区别，见下图
- 取消息：关于取消息，都是取的mMessage，可以理解为，取消息队列的头结点
- 非延时消息在同步屏障消息之前发送，都会排在同步屏障消息之前
- 延时消息，如果时刻大于发送同步屏障消息的时刻，会排在同步屏障消息之后
正常发消息和同步屏障

Vsync

关于Vsync
- Vsync 信号一般是由硬件产生的，现在手机一般为60hz~120hz，每秒刷新60到120次，一个时间片算一帧
- 每个 Vsync 信号之间的时间就是一帧的时间段
来看下执行同步消息时间片：这图真吉儿不好画，吐血

同步屏障在ViewRootImpl中作用

由上图可知：某种极端情况，你所发送的消息，在分发的时候，可能存在一帧的延时

总结

相关总结

同步屏障能确保消息队列中的异步消息，会被优先执行
鉴于正常消息和同步屏障消息插入消息队列的区别：同步屏障能够及时的屏障队列中的同步消息
某些极端场景：发送的消息，在分发的时候，可能会存一帧延时
- 极端场景：Vsync信号到来之后，立马执行了RequestLayout等操作
同步屏障能确保在UI刷新中：Vsync信号到来后，能够立马执行真正的绘制页面操作

同步消息和异步消息使用建议

在正常的情况，肯定不建议使用异步消息，此处假设一个场景：因为某种需求，你发送了大量的异步消息，由于消息进入消息队列的特殊性，系统发送的异步消息，也只能乖乖的排在你的异步消息后面，假设你的异步消息占据了大量的时间片，甚至占用了几帧，导致系统UI刷新的异步消息无法被及时执行，此时很有可能发生掉帧

当然，如果你能看明白这个同步屏障栏目所写的东西，相信什么时候设置消息为异步，心中肯定有数

正常情况，请继续使用同步消息
特殊情况，需要自己发送的消息被优先处理：可以使用异步消息

考点

上面源码基本就分析到这边了，咱们看看能根据这些知识点，能提一些什么问题呢？

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() 来结束分发操作

说明下：quit()方法会进行几项操作
- 清空消息队列（未分发的消息，不再分发了）
- 调用了原生的销毁方法 nativeDestroy（猜测下：可能是一些资源的释放和销毁）
- 拒绝新消息进入消息队列
- 它可以起到结束loop()死循环分发消息的操作
拓展：quitSafely() 可以确保所有未完成的事情完成后，再结束消息分发

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、清空消息队列

最后

写这篇文章加上思维导图，也大概整了十三来张图，我真的尽力了！

image-20210423224601010

源码篇：Handler那些事（万字图文）

源码篇：Handler那些事（万字图文）

前言

总流程

使用

收发一体

收发分开

mCallback.handleMessage(msg)

handleMessage(msg)

prepare和loop

收发消息

前置知识

发送消息

接收消息

分发消息

遍历消息

分发消息

消息池

IdleHandler

总结

同步屏障

前置知识

同步和异步消息

默认消息类型

生成同步屏障消息

同步屏障流程

同步屏障作用

Device类

ViewRootImpl类

总结

总结

消息插入对比

Vsync

总结

考点

最后