1.Handler全解
2.Handler消息机制（一）：Linux的码链epoll机制
3.27道 Handler 经典面试题，请注意查收
4.Handler 执行流程及源码解析
5.10分钟了解Android的码链Handler机制
6.Handler消息传递和同步屏障机制全面解析
Handler全解
Handler的作用是发送并处理一个线程关联的Message或Runable。
在UI线程中创建Handler，码链在子线程中发送消息。码链
Looper从ActivityThread类开始分析，码链ActivityThread并不是码链peewee 源码线程，而是码链开启主线程的类。Looper构造方法中创建了MessageQueue对象，码链保证了一个线程只对应一个MessageQueue对象。码链Looper死循环不断检查MessageQueue是码链否有可处理的消息，将消息分发给Handler处理。码链
Looper死循环的码链目的是防止线程退出，保证UI刷新和生命周期回调的码链完成，使用死循环实现不消耗过多资源，码链通过Linux pipe/epoll机制让线程进入休眠状态，码链释放CPU资源，等待被唤醒。
唤醒Looper的消息来自于创建ActivityThread后，通过thread.attach(false)方法接收系统服务AMS发送的事件，通过sendMessage方法将消息发送给AndroidThread的Handler实现内部类H，完成ActivityThread到UI线程的切换。
MessageQueue插入和读取操作通过enqueueMessage和next方法实现，使用单链表维护消息，方便插入和删除。nativePollOnce方法在没有消息或等待时间不到时，将线程设置为等待状态，直到获取到下一个Message。
Looper的loop方法死循环是为了无限读取MessageQueue的Message，next方法死循环是为了读取延迟的Message消息，计算需要等待的时间，让线程等待。
Handler构造方法利用threadLocal线程相关性获取当前线程对应的Looper，Handler对象将自己的引用放入msg中，通过enqueueMessage中的nativeWake唤醒等待线程，最终在Handler的dispatchMessage方法处理消息。
在子线程中创建Handler需要注意退出时机，避免子线程一直处于等待状态。Looper.quit方法退出后，发送的消息会失败，子线程也应手动调用quit方法终止。
Handler全解涵盖了Handler、Looper、MessageQueue的使用和原理，了解这些机制可以更好地管理线程和消息处理。溯源码燕窝天然
Handler消息机制（一）：Linux的epoll机制
在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。
假设我们的服务器需要支持万的并发连接，则在__FD_SETSIZE 为的情况下，则我们至少需要开辟1k个进程才能实现万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到万级别的并发访问，是一个很难完成的任务。
由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。
设想一下如下场景：有万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？
在select/poll时代，服务器进程每次都把这万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这万个连接的套接字
3）调用epoll_wait收集发生的事件的连接
如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，源码编译启动nginx并没有一股脑的向操作系统复制这万个连接的句柄数据，内核也不需要去遍历全部的连接。
当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：
每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。
而所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
epoll结构示意图
通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。
events可以是以下几个宏的集合：
EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；
EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP： 表示对应的文件描述符被挂断；
EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。
示例：
ET(EdgeTriggered):高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。mud源码搭建视频(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)
LT(LevelTriggered):缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！
1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
\2. 这个时候从管道的另一端被写入了2KB的数据
\3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
\4. 然后我们读取了1KB的数据
\5. 调用epoll_wait(2)……
ET工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。
LT工作模式：
LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。
当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、家政平台源码下载删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。
1.减少用户态和内核态之间的文件句柄拷贝；
2.减少对可读可写文件句柄的遍历。
/developer/information/linux%epoll%E6%9C%BA%E5%%B6
/s?id=&wfr=spider&for=pc
道 Handler 经典面试题，请注意查收
前言
Handler是什么？它的设计初衷与作用是什么？面试中，Handler无疑是关键点之一。它是Android消息机制的核心，主要负责切换线程，尤其在处理界面相关的消息事件时至关重要。常见的使用场景包括Activity启动时的进程间通信以及子线程网络操作后的UI更新。
二十七问，深入解析Handler
1. Handler被设计出来的原因是用于切换线程，其主要功能是解决子线程无法直接操作UI的问题。
2. 子线程访问UI导致崩溃的原因在于Android UI控件的非线程安全特性。解决办法包括避免在子线程中进行UI更新、使用Handler异步处理UI相关任务、使用AsyncTask等。
3. 延迟消息的实现依赖于enqueueMessage方法，该方法接收消息发送时间参数，确保消息按照时间顺序执行。
4. MessageQueue是一个特殊队列结构，采用链表形式存储消息，支持先进先出（FIFO）特性，用于消息的接收和分发。
5. 延迟消息的实现细节在于enqueueMessage方法，它根据时间参数安排消息插入队列的位置。
6. MessageQueue通过queue.next方法获取消息，使用死循环确保在有消息时立即返回，而阻塞发生在消息队列空时。
7. 当MessageQueue没有消息时，会阻塞等待新消息的到来，通过pipe/epoll机制实现唤醒。
8. 同步屏障和异步消息的使用场景包括界面绘制方法中，用于优化启动性能。
9. Message消息在被分发后，通过recycleUnchecked方法进行资源释放并复用。
. Looper作为管理消息队列的角色，通过ThreadLocal机制获取当前线程的Looper对象。
. ThreadLocal机制实现线程单例功能，避免了全局Map带来的混乱和潜在的内存泄漏问题。
. Handler机制中，ThreadLocal的运行机制和设计好处，以及在Choreographer等场景的应用。
. Looper的创建是线程级别的，因此不能多次创建，避免冲突。
. Looper中的quitAllowed字段用于控制退出消息队列的条件，确保线程安全退出。
. Handler的post和sendMessage方法的区别在于post方法附加了一个回调，用于后续消息处理。
. Handler机制的死循环设计原理，保证线程不会卡死。
. Message通过msg.target找到所属的Handler进行分发处理。
. post(Runnable)与sendMessage的区别在于后续消息处理机制。
. Handler.Callback.handleMessage和Handler.handleMessage的区别在于是否返回true。
. Looper、MessageQueue、线程的一一对应关系与Handler的多对一关系。
. ActivityThread中与Handler相关的工作及其主线程无需单独创建Looper的理由。
. IdleHandler的使用场景，特别是启动优化中。
. HandlerThread的定义与使用场景，以及其内部的线程安全处理。
. IntentService的定义与使用场景，提供子线程耗时任务执行的自动化。
. BlockCanary的原理，通过Handler消息处理时间检测应用卡顿。
. Handler内存泄露问题的根源及其影响链路解析。
. 利用Handler机制设计一个不崩溃的App，关注消息循环管理与异常恢复。
总结
阅读完本文后，相信你对Handler有了更深入的理解。尽管本文未能详尽解答Handler机制的运行原理，但通过结合自身知识库，你应能构建出自己的答案。继续探索，提升你的Android开发技能。
额外资源访问
在这里，你可以访问一系列Android开发学习资源，包括学习文档、面试题、核心笔记等，以助你进一步提升技能。点击下方卡片即可进行访问。
Handler 执行流程及源码解析
本文深入解析了Handler的执行流程及源码，围绕Looper、MessageQueue、Message、Handler之间的协作运行机制，详细介绍了从sendMessage到handlerMessage的代码执行流程。
在UI线程中，Looper是自动创建的，通过调用Looper.prepareMainLooper()方法，此方法内部调用了Looper的prepare()方法来创建Looper对象，并将其存储在ThreadLocal中，实现线程内部的数据存储。对于子线程，则需手动创建Looper，方法与UI线程一致，同样通过Looper.prepare()完成。
Handler在初始化时，通过ThreadLocal获取当前线程的Looper与MessageQueue。发送消息时，有三种方式：sendMessage、obtainMessage与post(runable)，它们实质上操作相同，差异仅在于对Message的处理。最终，所有消息都会通过sendMessage方法调用到MessageQueue的enqueueMessage实现。
MessageQueue内部使用单链表维护消息列表，主要包含enqueueMessage与next两个操作：enqueueMessage实现数据插入，next通过死循环检查并删除链表中的消息。当MessageQueue中出现新消息时，Looper会立即检测到并处理。
Looper的loop()方法内有一个死循环，通过messageQueue.next()检查消息队列，获取并删除新消息。检测到新消息后，调用msg.target.dispatchMessage(msg)处理消息，此方法在Looper内执行，切换到Handler创建时的线程，由Handler发送的消息最终回到Handler内部，执行dispatchMessage(msg)方法。
Handler处理消息分为三种情况：执行run()方法，实现线程切换；使用Callback接口的实例作为mCallback，用于不使用Handler派生类的情况；重写handlerMessage(msg)方法处理具体业务。至此，从sendMessage到handlerMessage的整个流程得以清晰展现。
整体流程总结如下：
1. 在Handler初始化时，获取线程的Looper与MessageQueue；
2. sendMessage方法最终调用enqueueMessage插入Message到队列，并将Handler赋值给Message对象的target属性；
3. MessageQueue在插入Message后，Looper检测到新消息，并开始处理；
4. Looper的loop方法通过traget属性获取到Handler对象，执行dispatchMessage方法；
5. 最终调用继承自Handler的handlerMessage方法处理具体业务。
分钟了解Android的Handler机制
Handler机制在Android中扮演着关键角色，是异步消息处理的核心，广泛应用于应用层和Framework层。
当我们调用Handler发送消息时，消息最终回到Handler手中。消息流转过程包括：通过sendEmptyMessage方法发送，消息经过sendMessageAtTime方法，判断Handler队列mQueue是否为空，若非空则调用enqueueMessage方法入队。enqueueMessage方法将消息与Handler绑定，然后调用queue.enqueueMessage方法正式入队列，队列由单向链表实现。消息队列在Handler构造函数中创建，通过Looper对象获取。
Looper是Handler机制中的重要角色，是线程私有的唯一对象，用于管理消息队列。在Looper.prepare方法中，Looper创建并初始化MessageQueue对象，这是消息队列的核心。在ActivityThread的Main方法中，Looper对象已初始化，因此在Handler示例代码中未调用prepare方法也不会导致程序崩溃。
消息取出并处理过程如下：MessageQueue封装添加和获取消息的方法。next()方法作为死循环，持续从队列中取出消息，直到取出消息或Looper调用quit方法，mQuitting变量为真时跳出循环。Looper.loop方法启动消息循环，调用queue.next方法阻塞式取消息，只有主动停止取消息才会跳出循环。取出消息后，调用dispatchMessage方法传递给Handler处理。
在主线程中执行loop方法的死循环不会导致Activity阻塞卡死，因为其中执行了重要方法nativePollOnce。Handler机制通过绑定消息和Handler，以及Looper管理消息队列的特性，实现了高效、安全的异步消息处理。
Handler消息传递和同步屏障机制全面解析
Handler消息传递和同步屏障机制详解 1. 消息传递原理Handler：负责发送和处理消息，可通过sendXXX和postXXX方法发送，核心是Looper的调度和消息队列的管理。
MessageQueue：消息的存放地，采用链表结构，确保消息有序，处理时按when值排序。
Message：承载数据的载体，通过消息池复用，减少内存占用。
Looper：消息调度的关键，每个线程有独立的Looper，保证了线程间的消息独立处理。
2. 消息处理流程发送消息：使用sendXXX或post方法，涉及sendMessageAtTime和enqueueMessage，确保消息按时间顺序排列。
消息入队：通过enqueueMessage方法，注意指定target和设置flag，确保消息队列的有序性。
消息出队：Looper的loop方法不断获取消息，优先级高的消息先被处理。
消息分发：Looper根据消息的target分发到对应的Handler，通过dispatchMessage方法执行。
3. 同步屏障机制 同步屏障用于保证屏幕刷新等高优先级任务，通过postSyncBarrier发送消息，插入队列尾部，确保优先执行。 4. IdleHandler 在消息队列空闲时执行低优先级任务，通过addIdleHandler添加任务，queueIdle()执行。 5. 消息对象池 复用Message对象，通过obtain方法获取，回收时通过recycleUnchecked()确保内存管理。 总结：Handler消息传递机制涉及多个环节，同步屏障和IdleHandler则提供了特殊场景下的处理策略，了解这些有助于优化应用性能。[Android 消息机制]—— Handler 机制详解
Android 消息机制的核心在于 Handler 机制，它解决的是主线程访问 UI 和子线程执行耗时操作的矛盾。Handler 提供了一个上层接口，底层由 MessageQueue 和 Looper 实现。消息机制的核心问题在于为什么只有主线程才能更新 UI。答案在于避免 UI 控件的并发访问导致的不确定性。ThreadLocal 的使用实现了线程间的隔离，让消息在不同线程间传递，实现了线程切换。MessageQueue 通过队列结构管理消息，支持插入和读取，使用单链表结构优化了插入与删除操作。Looper 负责消息循环，不断从 MessageQueue 中获取消息，处理并分发给 Handler。Looper 的构造方法确保了线程与 Looper 的唯一绑定，保证了消息机制的高效运行。Handler 则负责消息的发送与接收，通过 post 和 send 方法实现跨线程的消息传递。消息最终在 Looper 中通过循环处理，由 Handler 的 dispatchMessage 方法进行处理。ThreadLocal 和 Looper 的配合，实现了消息机制中线程切换的关键功能。消息的发送与接收，通过 enqueueMessage 方法在 MessageQueue 中进行，并由 nativeWake 唤醒等待的线程。Handler 机制提供了一种灵活的消息传递方式，但在非主线程中使用时需要妥善管理 Looper 的生命周期，以避免资源泄露和线程阻塞。通过 ActivityThread 的源码可见，每个 App 启动时都会创建一个 Looper，子线程则需要开发者自行创建。Handler 机制在 Android 中提供了线程间高效、安全的消息传递能力，是应用开发中的重要工具。
