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并不是码链澳洲源码线程，而是码链开启主线程的类。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时，原创源码管理器并没有一股脑的向操作系统复制这万个连接的句柄数据，内核也不需要去遍历全部的连接。
当某一进程调用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告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。记录ip的网页源码(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)
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 中提供了线程间高效、安全的消息传递能力，是应用开发中的重要工具。
