Handler机制与原理

为什么会出现内存泄漏问题呢？

• 分析

  • Handler使用是用来进行线程间通信的，所以新开启的线程是会持有Handler引用的，如果在Activity等中创建Handler，并且是非静态内部类的形式，就有可能造成内存泄漏

  • 非静态内部类是会隐式持有外部类的引用，所以当其他线程持有了该Handler，线程没有被销毁，则意味着Activity会一直被Handler持有引用而无法导致回收

  • MessageQueue中如果存在未处理完的Message，Message的target也是对Activity等的持有引用，也会造成内存泄漏

• 解决的办法

  • 使用静态内部类 + 弱引用的方式

    • 静态内部类不会持有外部类的的引用，当需要引用外部类相关操作时，可以通过弱引用还获取到外部类相关操作，弱引用是不会造成对象该回收回收不掉的问题，不清楚的可以查阅JAVA的几种引用方式的详细说明

  • 在外部类对象被销毁时，将MessageQueue中的消息清空

在使用Handler时，通常是通过Handler.obtainMessage()来获取Message对象的，而其内部调用的是Message.obtain()方法，那么问题来了，为什么不直接new一个Message，而是通过Message的静态方法obtain()来得到的呢？

• 使用obtain获取Message对象是因为Message内部维护了一个数据缓存池，回收的Message不会被立马销毁，而是放入了缓存池，在获取Message时会先从缓存池中去获取，缓存池为null才会去创建新的Message

Message的存储形式是什么

• Message的存储是链表的形式，next相当于链表的尾指针

新的首部如果阻塞了，需要唤醒线程。为什么会有线程的阻塞呢？

• 其实MessageQueue内部的消息是按需要发送的时间点从小到大排列的，后面会分析到，从当前if里的when判断也能看出一二，当队首的Message未到达发送的时间点时，说明其当前所有的消息都未到达发送的时间，上面说过，Handler发送消息并不是通过定时器发送的。当队首Message（最近需要发送的Message）未到达发送时间点时，线程被阻塞，所以这里需要根据线程是否阻塞看是否需要唤醒线程，这样才能使新加入的Message能及时发送出去，不会被阻塞

一个线程可以有几个Looper、几个MessageQueue和几个Handler？

• 在 Android 中，Looper类利用了ThreadLocal的特性，保证了每个线程只存在一个Looper对象。Looper构造函数中创建了MessageQueue对象，因此一个线程只有一个MessageQueue。可以有多个Handler

可以在子线程直接创建一个Handler吗？会出现什么问题，那该怎么做？

• 不能在子线程直接new一个Handler。因为Handler的工作依赖于Looper，而Looper又是属于某一个线程的，其他线程不能访问，所以在线程中使用Handler时必须要保证当前线程中Looper对象并且启动循环。不然会抛出异常

Looper死循环为什么不会导致应用卡死，会消耗大量资源吗？

• 对于线程即是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder线程也是采用死循环的方法，通过循环方式不同与Binder驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。但这里可能又引发了另一个问题，既然是死循环又如何去处理其他事务呢？通过创建新线程的方式。真正会卡死主线程的操作是在回调方法onCreate/onStart/onResume等操作时间过长，会导致掉帧，甚至发生ANR，looper.loop本身不会导致应用卡死

-主线程的死循环一直运行是不是特别消耗CPU资源呢？ 其实不然，这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在Loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪（读或写就绪），则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源

Handler原理

Handler创建消息

• 每一个消息都需要被指定的Handler处理，通过Handler创建消息便可以完成此功能。Android消息机制中引入了消息池。Handler创建消息时首先查询消息池中是否有消息存在，如果有直接从消息池中取得，如果没有则重新初始化一个消息实例。使用消息池的好处是：消息不被使用时，并不作为垃圾回收，而是放入消息池，可供下次Handler创建消息时使用。消息池提高了消息对象的复用，减少系统垃圾回收的次数。

• 消息的创建流程如图所示

Handler创建消息

Handler发送消息

• UI主线程初始化第一个Handler时会通过ThreadLocal创建一个Looper，该Looper与UI主线程一一对应。使用ThreadLocal的目的是保证每一个线程只创建唯一一个Looper。之后其他Handler初始化的时候直接获取第一个Handler创建的Looper。Looper初始化的时候会创建一个消息队列MessageQueue。至此，主线程、消息循环、消息队列之间的关系是1:1:1

• Hander持有对UI主线程消息队列MessageQueue和消息循环Looper的引用，子线程可以通过Handler将消息发送到UI线程的消息队列MessageQueue中

• Handler、Looper、MessageQueue的初始化流程如图所示

Handler发送消息

Handler处理消息

• UI主线程通过Looper循环查询消息队列UI_MQ，当发现有消息存在时会将消息从消息队列中取出。首先分析消息，通过消息的参数判断该消息对应的Handler，然后将消息分发到指定的Handler进行处理

• 子线程通过Handler、Looper与UI主线程通信的流程如图所示

Handler处理消息