1、handler的作用

handler是android线程之间的消息机制，主要的作用是将一个任务切换到指定的线程中去执行，（准确的说是切换到构成handler的looper所在的线程中去出处理）android系统中的一个例子就是主线程中的所有操作都是通过主线程中的handler去处理的。

2、handler的架构

Handler的运行需要底层的 messagequeue和 looper做支撑。

3、handler原理

3 .1 、首先说messagequeue，messagequeue 是 一 个 消 息 队 列 ， 它是采用单链表的数据结构来存储消息的，因为单链表在插入删除上 的效率非常高。（Meaasgequeue主要包含一个是插入消 息的 enqueuemessage方法，和一个取出一条消息的next方法。）

3.2、然后说 looper，looper在安卓的消息机制中是扮演着消息调度的角色，具体来说就是他会不停的从 messagequeue中查看 是否有新消息，如果有，并且这个消息需要执行，就从队列中取出这个消息进行执行，（死循环遍历消息：取消息的线程会先阻塞一段时间（队头消息的执行时间减去当前时间），然后从队列中取出队头消息），否则会一直阻塞在messagequeue的next那里。（构成 一个 looper是需要一个 messagequeue，而构成一个 handler则需 要一个 looper，）另外looper一般是调用Looper.prepare()方法使用 threadlocal在线程的ThreadLocalMap中存储一个looper的，线程中有了looper之后就可以在这个线程中创建一个 handler了。

3.2、然后说 looper，looper在安卓的消息机制中是扮演着消息调度的角色。

Looper取消息的过程是这样的：

如果队列中有消息：
1、判断队头消息的执行时间是否大于当前时间，如果大于，就调用nativePollOnce阻塞一段时间（队头消息的执行时间-当前时间）然后取出队头消息进行执行。
2、否则就立即取出队头消息进行执行。
3、如果队列中没有消息，就一直阻塞，直到下一个消息来到，才唤醒取消息的线程继续上述循环。

Message next() {
         ...
        int pendingIdleHandlerCount = -1; // -1 only during first iteration
        int nextPollTimeoutMillis = 0;
        for (;;) {
            if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }
            nativePollOnce(ptr, nextPollTimeoutMillis);
            synchronized (this) {
                // Try to retrieve the next message.  Return if found.
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    //发现屏障消息，优先执行队列中的异步消息
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                     //之所以要循环，是因为队列是按时间排序的，异步消息不一定位于队头
                    } while (msg != null && !msg.isAsynchronous());
                }
                if (msg != null) {
                    if (now < msg.when) {
                        // Next message is not ready.  Set a timeout to wake up when it is ready.
                         //队头消息没到执行时间，休眠nextPollTimeoutMillis
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        // Got a message.
                        //得到一个需要立即执行的消息
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    // No more messages.
                    //队列中没有消息了，进入无限期休眠
                    nextPollTimeoutMillis = -1;
                }
            ...
        }
    }

nativePollOnce(ptr, nextPollTimeoutMillis)，这是一个native方法，实际作用就是通过Native层的MessageQueue休眠nextPollTimeoutMillis毫秒的时间。
1.如果nextPollTimeoutMillis=-1，一直休眠不会超时。
2.如果nextPollTimeoutMillis=0，不会休眠，立即返回。
3.如果nextPollTimeoutMillis>0，最长休眠nextPollTimeoutMillis毫秒(超时)，如果期间有程序唤醒会立即返回。

3.3、最后说 handler

handler通过handler.send (message)发送消息，实际上是往构成他的 looper的 messagequeue中 插入了一条消息，在将这条消息插入 messagequeue中之前，他需 要将此消息的 target变量指向当前发它的 handler，然后looper在适当的时机取出这个消息，（looper发现构成它的 messagequeue中有消息时， looper的 loop方法就会从 messagequeue中取出这条消息），然后调 用这个消息对应的handler的dispatchmessage方法来处理这个消息（即msg.target.dispatchmessage），注意，dispatchmessage 方法是在构成 handler的 looper中的loop方法中调用的，所以处理消息的逻辑就切换到了构成handler的looper所在的线程之中了。

messagequeue加入一条消息唤醒取消息线程的三种情况

 boolean enqueueMessage(Message msg, long when) {
            ...
            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 {
                //p.target == null && msg.isAsynchronous()代表这个消息是系统消息
                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;
            }
            //需要的情况下唤醒取消息线程
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

1、messagequeue为空
2、当前消息不是延时消息
3、当前消息执行时间小于队头消息执行时间

（hanlder的构成是需要一个 looper，主线程 之中，在activitythread的main方法中（程序入口）通过 looper.preparemainlooper在主线 程中存储一个 looper，而在子线程之中，我们则需要手动的通过 looper的 prepare在子线程中存储一个 looper，然后通过 looper.loop 开启一个消息循环）。

4、主线程中的handler

android系统中的一个例子就是主线程中的所有操作都是通过主线程中的handler去处理的。例如activity的生命周期方法调用就是通过主线程中的handler去处理的。
在app的主线程中有一个类是activitythread，这个类中有一个main方法是app程序的入口，在main方法中使用Looper.prepareMainLooper()，在主线程中设置了一个looper，然后创建了一个applicationthread的线程用于和server进程中applicationthreadproxy进行进程通信，最后调用了Looper.loop()开启消息循环。
在activity的生命中期中，比如说系统服务ActivityManagerService调用applicationthreadproxy通过Binder给当前app进程中的applicationthread发送了一个暂停activity的操作。app进程中的applicationthread便会通过在主线程中的handler将这个暂停activity的消息插入到主线程的messagequeue中去处理。

5、主线程的死循环一直运行是不是特别消耗CPU资源呢？

这里就涉及到Linux pipe/epoll机制，在主线程的MessageQueue没有消息时，主线程便阻塞在loop的queue.next()中的nativePollOnce()方法里，相当于java层的线程waite机制，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达时调用nativewake，通过往pipe管道写端写入数据来唤醒主线程工作。相当于java层的notify机制，去唤醒主线程，然后处理消息，所以主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。
从looper取消息的过程，可以看出取消息的线程大部分时候处于阻塞状态，不会消耗cpu资源。

6、 Android中为什么主线程不会因为Looper.loop()里的死循环导致（anr）卡死？

理解1：looper死循环是不断的往构成它的消息队列中取消息，如果当前队列中没有消息，或者队列中的消息不需要现在立即处理，looper所在的线程就进入wait状态，释放cpu资源，其他的线程仍可处理事件。比如说applicationthread仍可接收服务进程中的消息来处理，如果这个消息需要在主线程中处理，它就会调用主线程中的handler，将这个消息加到主线程的消息队列中去处理。

理解2：looper取消息的过程是先wait一段时间（这段时间是messagequeue队首消息的执行时间减去当前时间），然后醒来从messagequeue中取出队首消息进行执行，wait过程中主线程是释放cpu资源的，其他的线程（applicationthread）仍可处理事件。

理解3：(首先主线程中的死循环不会导致app anr，它会使得主线程阻塞在messagequeue的next中的nativePollOnce()方法里，当有消息来时就会唤醒主线程进行消息处理，即使主线程在休眠的时候也有其他的线程（applicationthread）在处理事件。)

首先Anr和死循环不是一个概念。
1、主线程的工作就是处理主线程中的message，所有需要到主线程执行的操作都是通过主线程的向主线程的messagequeue加入一条消息，looper在适当的时机取出这条消息，来执行的，如果不是一个死循环，那么loop取出一条消息，执行完一条消息后，主线程就退出了，正是有这个死循环，它才保证了主线程不会退出，并且能处理队列中所有的消息。所以这个死循环是一个消息处理机制。

2、而anr原因是，主线程中messagequeue中一个message的处理时间过长，导致接下来的某类消息无法处理，比如说一个消息的处理时间超过了5秒，导致用户的输入无法响应，才会出现anr。

3、另外，从looper取消息的过程来看，只有当此刻有需要执行的消息时，主线程才将此消息取出来执行，否则就进入休眠状态，释放cpu。（就算不进入休眠一直循环，如果手机是多核，也是不会卡死的，只是主线程在不停的运行代码，消耗了更多资源）

为什么主线程中会采用死循环呢？

线程是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了。而对于主线程，我们是绝不希望会被运行一段时间就退出，所以采用死循环保证它不会被退出。

7、handler.postDelayed(Runnable r, long delayMillis)

handler.postDelayed在message加入到messagequeue中之前，会计算出这个消息的执行时间SystemClock.uptimeMillis() + delayMillis，（SystemClock.uptimeMillis()是开机到现在的时间（毫秒）），然后通过enqueueMessage 将message和其执行的时间一起添加进messagequeue，在enqueueMessage方法中会根据这个消息的执行时间去将这个消息插入到适当的位置，简单的说，messagequeue是按消息的执行时间message.when排序的。如果插在队列中间，说明该消息不需要马上处理，不需要由这个消息来唤醒队列。 如果插在队列头部（或者when=0），则表明可能要马上处理这个消息。如果当前队列正在堵塞，则需要唤醒它进行处理。 通过nativeWake方法唤醒队列。

8、如何保证延时消息精确执行？

1、从looper取消息过程来看，
2、从加入一条新的消息过程来看。
这两个过程都不存在任何延迟

8、ThreadLocal

ThreadLocal 可以在多个线程内存储数据，使用ThreadLocal存储的数据在多个线程之间是隔离的，因为它是将数据存储在每个线程内的ThreadLocalMap中。

9、同步屏障，同步消息，异步消息

同步消息就是我们平时发送的消息，异步消息一般是系统发送的消息

同步屏障就是给消息队列发送了一个屏障信息（target == null），消息队列在处理到这个屏障信息时就开启了”同步屏障”模式。在该模式下，只返回异步消息给 Looper 处理，屏蔽同步消息。

在处理完异步消息队列后，即使消息队列中还有同步消息也会通过nativePollOnce()进入线程阻塞状态。直到有新的异步消息进来。除非解除同步屏障模式，同步消息才能得到处理。

简单的说就是，发现了同步屏障消息，就只处理异步消息，不处理同步消息，直到同步屏障被移除。

view的刷新用到了同步屏障，因为界面刷新事件应处在第一优先级。

参考文章

8.1、handler.postDelayed(Runnable r, long delayMillis)：https://stevendxc.github.io/Blog/2015/01/18/postDelayed/
8.2、handler流程：https://www.jianshu.com/p/8862bd2b6a29
8.3、handler系列问题：https://www.zhihu.com/question/34652589
8.4、https://segmentfault.com/a/1190000022551209
8.5https://peterxiaosa.github.io/2020/07/15/Handler%E6%9C%BA%E5%88%B6%E4%B9%8B%E6%B6%88%E6%81%AF%E7%9A%84%E5%90%8C%E6%AD%A5%E5%B1%8F%E9%9A%9C/