Handler 使得Android开发难度大大降低，几乎看不到多线程死锁的问题。

Q：谈谈消息机制Hander？作用？有哪些要素？流程是怎样的？

1、Android的消息机制主要是指Handler的运行机制，Handler的运行依赖于MessageQueue和Looper，当然，既然是消息机制，通常也需要用到Message。Handler、Looper、MessageQueue和Message的工作原理就像是生产线，Looper是发动机，MessageQueue就是传送带，Handler是工人，Message就是待处理的产品。

Handler工作流程

Handler相当于一个传送带,handler.sendXXX,handler.postXXX都是将消息发送出去，通过传送带，调用handler.dispatch()将消息获取到并处理。handler通过send将一个个的Message放到传送带里面来，拼凑成一个链表结构，再由Looper函数，调用Looper.loop方法，相当于给这个传送带附上的一个开关，打开以后为传送带供能，传送带就不停的滚动，带动MessageQueue滚动，消息Message 就一直向前走，当Message到达某个时间节点的时候，消息将会发送出去（handler.sendXXX）交由Hanler去处理。
handler.send() ----->>>>>MessageQueue.enqueueMessage() 消息入队列
Looper.loop()----->>>>>MessageQueue.next()--->handler.dispatch() 消息出队列
Thread ---->Looper.loop()由线程本身调用

image.png

2、Handler主要是为了解决在子线程中无法访问UI的矛盾。
如何实现线程数据的隔离：线程的上下文独一无二？
Thread---->static final ThreadLocal --->Looper 通过prepare保障了ThreadLocal 和Looper 唯一绑定
Looper唯一----->MessageQueue--->唯一

image.png

Q：为什么系统不建议在子线程访问UI？

因为Android的UI是线程不安全的，UI负责与用户的交互，如果多线程中并发访问UI会导致UI处于不可控的状态。其次也不能选择使用加锁处理，首先因为加锁会阻塞某些线程的执行，降低UI访问的效率，其次加锁会让UI访问的逻辑变得复杂。
UI线程直接与用户交互，如果在UI线程处理耗时操作，用户将无法继续执行其他UI操作，用户体验很差。其次Android规定，如果任意一个Acitivity没有响应5秒钟以上就会弹出ANR窗口。因此我们可以使用Handler将耗时操作放到子线程中去执行以避免上述情况。

Q：一个Thread可以有几个Looper？几个Handler？

一个Thread只有一个Looper,一个looper，多个Handler。
https://www.

Q：如何将一个Thread线程变成Looper线程？Looper线程有哪些特点？

Looper和MessageQueue共同协作来让整个消息队列动起来，不断的取出新消息

Q：可以在子线程直接new一个Handler吗？那该怎么做？

不能直接new，会报错，当我们在主线程中创建Handler对象的时候没有问题，是因为主线程会自动调用Looper.prepare（）方法去
给当前主线程创建并设置一个Looper对象，随意在Handler构造函数中从当前线程的对象身上拿到这个Looper。
但是子线程中并不会自动调用这个方法，所以要想在子线程中创建Handler对象就必须在创建之前手动调用Looper.prepare（）方
法，否则就会报错。

Q：Message可以如何创建？哪种效果更好，为什么？

由于我们是使用Message来进行消息传递，所以如果每次都new 一个Message就很可能会产生大量用了一次就不再用的Message对象，消耗有限的内存资源。针对这种情况，Handler的obtainMessage()方法内部采用了享元模式。我们应该优先使用Handler的obtainMessage()方法构建Message对象。

Q：这里的ThreadLocal有什么作用？

它的存在让Thread、Handler、MessageQueue绑定了起来，于是让handler可以做到不管在哪个线程发消息，最终消息都会传送到原来的Thread里。ThreadLocalMap也是功不可没。

Q：主线程中Looper的轮询死循环为何没有阻塞主线程？

ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么你的应用也就退出了。因为Android 的是由事件驱动的，looper.loop() 不断地接收事件、处理事件，每一个点击触摸或者说Activity的生命周期都是运行在 Looper.loop() 的控制之下，如果它停止了，应用也就停止了。只能是某一个消息或者说对消息的处理阻塞了 Looper.loop()，而不是 Looper.loop() 阻塞它。

也就说我们的代码其实就是在这个循环里面去执行的，当然不会阻塞了。

如果某个消息处理时间过长，比如你在onCreate(),onResume()里面处理耗时操作，那么下一次的消息比如用户的点击事件不能处理了，整个循环就会产生卡顿，时间一长就成了ANR。
而且主线程Looper从消息队列读取消息，当读完所有消息时，主线程阻塞。子线程往消息队列发送消息，并且往管道文件写数据，主线程即被唤醒，从管道文件读取数据，主线程被唤醒只是为了读取消息，当消息读取完毕，再次睡眠。因此loop的循环并不会对CPU性能有过多的消耗。
总结：Looer.loop()方法可能会引起主线程的阻塞，但只要它的消息循环没有被阻塞，能一直处理事件就不会产生ANR异常。

Q：使用Hanlder的postDealy()后消息队列会发生什么变化？

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 = (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;
                if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                msg.markInUse();
                return msg;
            }
        } else {
            // No more messages.
            nextPollTimeoutMillis = -1;
        }
        ...
    }

可以看到，在这个方法内，如果头部的这个Message是有延迟而且延迟时间没到的（now < msg.when），会计算一下时间（保存为变量nextPollTimeoutMillis），然后在循环开始的时候判断如果这个Message有延迟，就调用nativePollOnce(ptr, nextPollTimeoutMillis)进行阻塞。nativePollOnce()的作用类似与object.wait()，只不过是使用了Native的方法对这个线程精确时间的唤醒。

Q:Handler的内存泄露问题及其处理方法

成因：

Handler的内存泄露问题大致是这样形成的：就是主线程中创建的Handler会和主线程Looper的消息队列MessageQueue相关联，于是MessageQueue中的每个Message都会持有一个Handler的引用。而由于非静态内部类和匿名类都会隐式的持有它们所属外部类的引用，所以就导致了Message持有Handler引用，Handler持有其外部类的引用的引用链。在Message被处理前，这条引用链会阻止垃圾回收器的回收，于是发生内存泄露。
验证:可以使用 handler.postDelayed()方法进行验证。
解决：
解决方法：1. 使用内部静态类构造Handlr，因为内部静态类不会持有外部类的引用。但是这样的话就无法操控外部Activity的对象，于是还需要增加一个队Activity的弱引用。2. 在Activity退出的时候调用Looper的quit和quitSafely方法，以及使用对应的handler.removeCallback方法，这些方法会最后会执行 msg.target = null 操作，让msg不再持有handler引用。