handler机制_Handler机制与原理

为什么会出现内存泄漏问题呢&＃xff1f;

• 分析

  
  

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

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

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

• 解决的办法

  
  

  • 使用静态内部类 &＃43; 弱引用的方式

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

  • 在外部类对象被销毁时&＃xff0c;将MessageQueue中的消息清空

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

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

Message的存储形式是什么

• Message的存储是链表的形式&＃xff0c;next相当于链表的尾指针

新的首部如果阻塞了&＃xff0c;需要唤醒线程。为什么会有线程的阻塞呢&＃xff1f;

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

一个线程可以有几个Looper、几个MessageQueue和几个Handler&＃xff1f;

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

可以在子线程直接创建一个Handler吗&＃xff1f;会出现什么问题&＃xff0c;那该怎么做&＃xff1f;

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

Looper死循环为什么不会导致应用卡死&＃xff0c;会消耗大量资源吗&＃xff1f;

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

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

Handler原理

Handler创建消息

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

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

Handler发送消息

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

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

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

Handler处理消息

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

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

Framework精编内核解析在开源项目&＃xff1a;https://github.com/Android-Alvin/Android-LearningNotes 中已收录&＃xff0c;里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等&＃xff0c;资源持续更新中…