Android-消息机制Handler

Handler的机制:Android 消息传递机制就是handler。在多线程的应用场景中，将工作线程中需更新UI的操作信息 传递到 UI主线程，从而实现对UI的更新处理，最终实现异步消息的处理。多个线程并发更新UI的同时 保证线程安全。Handler只是一个入口，核心的是Message、Message Queue、Looper（循环器）。handler添加消息到消息队列，处理循环器分派的消息。Message是线程间通讯的数据单元，存储需要操作的通信信息。message queue是一种先进先出的数据结构，底层是单链表结构。存储message。Looper消息循环，循环取出消息队列的消息，分发给对应的handler。looper的构造方法是私有的，只能通过looper的prepare这个静态方法初始化。首先判断sThreadLocal.get() != null 的话会抛出异常，sThreadLocal存储的就是looper，ThreadLocal是线程中的。也就是说一个线程只能有一个looper。Looper 处理 Message 的实现：
Looper 得到 Message 后回调 Message 的 callback 属性即 Runnable，或依据 target 属性即 Handler，去执行 Handler 的回调。存在 mCallback 属性的话回调 Handler$Callback；反之，回调 handleMessage() 。Handler通过执行其绑定线程的消息队列（MessageQueue）中不断被Looper循环取出的消息(Message)来完成线程间的通信。
prepare方法调用sThreadLocal.set(new Looper(quitAllowed))，loop的构造方法中会初始化MessageQueue，也就是一个线程也保证了只有一个MessageQueue。消息的入队是enqueueeMessage根据时间放入消息队列。MessageQueue然后利用 Message 的 next 属性进行多个消息之间的链接，同时使用 when 属性对消息进行排序，when 的值越小，在链表中的排序越靠前。
取出消息就是Looper.loop()，拿到消息队列 queue 以后，进入死循环，通过MessageQueue.next获取消息，通过msg.target的dispatchMessage 分发出去消息。msg.target就是handler。阻塞和唤醒主要是nativePollOnce，nativeWake方法，这两个方法实际是实现了空队列阻塞，以及唤醒功能，底层使用epoll机制实现。由于Looper中拥有当前线程的引用，所以有时候可以用Looper的这种特点来判断当前线程是不是主线程。

handler调用链
MessageQueue -> Message -> Handler -> Activity 调用链。当activity关闭后，正常应该被GC回收，发现activity仍然被handler所引用，导致不能正常回收，依然占用内存，导致了内存泄漏。

如何理解 ThreadLocal 的作用？
首先要明确并非不是用来切换线程的，只是为了让每个线程方便程获取自己的 Looper 实例，见 Looper#myLooper()；
后续可供 Handler 初始化时指定其所属的 Looper 线程；
也可用来线程判断自己是否是主线程。

Message的创建就是享元模式，从消息池取出一个消息，Message.obtain，放到需要用到的链表，没有了创建和销毁的过程，避免内存抖动。MessageQueue.quit中remove消息的时候调用recycleUnchecked（）方法，并不是真的将消息干掉，而是将消息里的内容都去掉。message是有一个内存块，里面的内容处理掉之后，放到另一个消息链表，头插，每生成一个节点放到头部。源码中Handler在调用enqueueMessage的时候有 msg.target = this;msg中的target属性就是handler。
Handler中的消息队列，也就是MessageQueue,从名字看是一个队列，但是底层是单链表结构，通过MessageQueue.enqueueMessage()向消息队列添加消息，入参时候的 when 参数，when变量是一个时间戳，就是我们平时调用 sendMessageDelayed 方法时传入的延时 + 当前系统时间，使用 when 属性对消息进行排序，when 的值越小，在链表中的排序越靠前。
Looper的构造函数是私有的，只能通过Looper.prepare()初始化，静态方法prepare首先会判断sThreadLocal.get() != null，否则会抛出异常，sThreadLocal 中存放的就是looper，所以一个线程只能有一个looper，在构造 Looper 的时候，创建了属于这个 Looper 的消息队列 MessageQueue ，一个looper只能有一个messageQueue，想要开启消息循环，需要通过Looper.loop()，主干代码就是拿到消息队列 queue 以后，进入死循环。
循环中从消息队列中获取到一个可以执行的 Message，接着调用这个消息的 target（即 Handler）的 dispatchMessage 方法，消息就分发出去了。如果当前插入消息是即时消息，则将这个消息作为新的头部元素，并将此消息的next指向旧的头部元素，并通过needWake唤醒Looper线程。如果消息为异步消息则通过Message.when长短插入到队列对应位置，不唤醒Looper线程。
ThreadLocal是用在多线程中，用于保存当前线程的上下文信息。ThreadLocal的实现原理：在每个线程中使用ThreadLocalMap将键值对保存在使用线性探测法实现的hash表中（HashMap是链接法实现的hash表）。
主线程为什么没有被loop阻塞？
MessageQueue类中的两个Java方法：Message next（）和boolean enqueueMessage（Message，long）。Message next（），接收并返回队列中的下一条消息。如果队列为空（并且没有任何内容可以返回），则该方法调用native void nativePollOnce（long，int），该块将阻塞，直到添加新消息。Message添加到队列时，框架会调用enqueueMessage方法，该方法不仅会将消息插入队列，还会调用native static void nativeWake（long），如果需要唤醒队列的话。 nativePollOnce和nativeWake的核心发生在native（实际上是C ++）代码中。 Native MessageQueue使用名为epoll的Linux系统调用，该调用允许监视IO事件的文件描述符。 nativePollOnce在某个文件描述符上调用epoll_wait，而nativeWake写入描述符，这是IO操作之一，epoll_wait等待。然后内核从等待状态中取出epoll等待线程，并且线程继续处理新消息。epoll 是 Linux 内核为处理大批量文件描述符而作了改进的 poll，是 Linux 下多路复用IO接口 select/poll 的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统 CPU 利用率。epoll 是 Linux 中用来监听 IO 事件的工具。一个进入等待的句柄，一旦监听到事件发生，就会被唤醒，继续往下执行。nativePollOnce不会浪费CPU周期。
Handler 同步消息屏障？
同步屏障是用来阻挡同步消息执行的。在日常使用中，很少去关心 Handler 的消息是同步还是异步，这是因为默认的消息都是 同步消息 。 Android 系统 View 的绘制流程，应该会知道 View 的绘制也是通过 Handler 来驱动的。如果在启动绘制之前，用户（开发者）插入了一个非常耗时的消息到队列中，那就会导致 UI 不能按时绘制，导致卡顿掉帧。同步消息屏障就可以用来保证 UI 绘制的优先性。
异步 Message：设置了 isAsync 属性的 Message 实例
同步屏障：在 MessageQueue 的某个位置放一个 target 属性为 null 的 Message，确保此后的非异步 Message 无法执行，只能执行异步 Message。当 MessageQueue 轮循 Message 时候发现建立了同步屏障的时候，会去跳过其他 Message，读取下个 async 的 Message 并执行，屏障移除之前同步 Message 都会被阻塞。比如屏幕刷新 Choreographer 就使用到了同步屏障，确保屏幕刷新事件不会因为队列负荷影响屏幕及时刷新。同步屏障的添加或移除 API 并未对外公开，App 需要使用的话需要依赖反射机制。

内存泄漏：
在Java中，非静态内部类会持有一个外部类的隐式引用，可能会造成外部类无法被GC；
比如这里的Handler，就是非静态内部类，它会持有Activity的引用从而导致Activity无法正常释放。而单单使用静态内部类，Handler就不能调用Activity里的非静态方法了，所以加上「弱引用」持有外部Activity。
1、在Handler消息队列 还有未处理的消息 / 正在处理消息时，消息队列中的Message持有Handler实例的引用。
2、Handler = 非静态内部类 / 匿名内部类（2种使用方式），故又默认持有外部类的引用。
解决：静态内部类+弱引用，外部类结束生命周期时，清空Handler内消息队列mHandler.removeCallbacksAndMessages(null);
IdleHandler？
IdleHandler 是 Handler 中提供的一种可以在 Looper 事件循环的过程中，MessageQueue 出现空闲的时候，允许我们执行一些任务的机制。空闲就是 MessageQueue 为空，没有 Message；或、MessageQueue 中最近待处理的 Message，是一个延迟消息（when>currentTime），需要滞后执行；适合执行一些不重要的任务，说白了就是对执行时机没有那么高要求的任务；因为 IdleHandler 只有在事件循环空闲时才会执行，所以它处理任务的时机，是不可控的。
IdleHandlers 不为空时，为什么不会进入死循环？
1、关键在于 pendingIdleHanderCount 的值。
2、在 pendingIdleHandlerCount 为 -1 时，才会尝试执行 mIdleHander；
3、pendingIdleHandlerCount 在 next() 中初始时为 -1，执行一遍后被置为 0，所以不会重复执行；
IntentService是google在原生的Service基础上通过创建子线程的Service。也就是说IntentService是专门为android开发者提供的能在service内部实现耗时操作的service。我们可以通过重写onHandleIntent方法实现耗时操作的回调处理，而且IntentService在耗时操作完成后，会主动销毁自己，IntentService可以通过多次启动来完成多个任务，而IntentService只会被创建一次，每次启动的时候只会触发onStart方法。内部是实现了Handler异步处理耗时操作的过程，一般多用在Service中需要处理耗时操作的功能。提问：为什么IntentService中能实现耗时操作?
在onCreate中，通过HandlerThread来开启一条线程，而HandlerThread线程中会跟我们平常用的Handler不太一样，在run方法中创建了looper对象，所以HandlerThread能让IntentService在子线程中使用handler达到耗时操作。

适用于期望空闲时候执行，但不影响主线程操作的任务。
系统应用：
Activity destroy 回调就放在了 IdleHandler 中
ActivityThread 中 GCHandler 使用了 IdleHandler，在空闲的时候执行 GC 操作。

参考文章：https://blog.csdn.net/u013750244/article/details/106717193
https://mp.weixin.qq.com/s/MhHTKwywee_GQBOKqZv3Eg
https://www.jianshu.com/p/ed9e15eff47a
https://juejin.cn/post/7020060105773154312#heading-0
https://juejin.cn/post/6844904136937324552