Handler工作机制及相关问题

Handler工作机制

本身是一个传送带模型

Handler

向传送带上输送Message的搬运工

调用 Handler.sendXXX() 发送Message

• sendXXX相关函数,最后都会调用 Handler.enqueueMessage(),然后调用 MessageQueue.enqueueMessage()函数将message放置到MessageQueue即消息队列中中
• 每一个Handler中都包含一个MessageQueue对象 ，该MessageQueue对象由 与该Handler 绑定Looper通过调用 looper.mQueue 获取
• 如果Handler在构建时没有传递Looper对象，则默认通过 Looper.myLooper() 获取

---

Message

传送带上的货物

• Message.target = 发送它的Handler对象，在 Handler.enqueueMessage()时被赋值

数据结构

• 多个Message的存储方式 ： 优先级队列
• Message中包含 众多描述自身的属性 和 next指针。其中next指针指向队列中下一个Message对象

---

MessageQueue: 消息队列是一个优先级队列

相当于传送带 根据时间先后顺序排队的队列 ; 取消息总是从头部获取

MessageQueue.enqueueMessage()

• 将Message放入消息队列中

MessageQueue.next()

• 将头部的Message从队列中取出 ( 当队列中的Message的when满足条件时 )
• 在Looper.loop()函数中的for循环中调用

Message中的when变量

• 每个message都有一个时间:when变量 ,由发送延时控制 ,控制插入队列中的message什么时候会执行; 队列中的message按此时间排序
• 新插入的message的时间(when变量)会依此比对 消息队列中的每一个Message的时间,从而将自身插入到合适的位置,也保证了messageQueue队列始终保持有序

---

Looper

传送带的动力

通过调用 Loop()函数(内部包含一个死循环，会一直循坏等待调用 MessageQueue.next()函数 )，实现传送带的持续工作

• loop函数的循环中 , 在 queue.next() 获取队列头部的message,当没有满足条件的message时,在此处一直等待
• 从队列中获取了Message之后,就会调用 message.target.dispatchMessage() --> handler.handleMessage(), 从而实现了整个过程。
• Message.target 便是 发送此Message的Handler对象
• 在 queue.next()中 会调用 natvie

相关问题

1.一个线程有几个handler

答案： 多个

2.一个线程有几个Looper

答案： 一个

如何保证一个线程中只有一个Looper对象？ 可从下面 ThreadLocal知识点 中获知

3.关于ThreadLocal

• 几乎所有的ThreadLocal对象都是 final 静态的
• 每个ThreadLocal对象都用来 标记 存储一组线程中的同一类型的数据； 而数据存储在 Thread.threadLocals 所获取的 TheadLocalMap中

以 标记存储Looper的ThreadLocal为例

• 它的实例化 ：

	static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

• set方法 调用位置：Looper.java中

   private static void prepare(boolean quitAllowed) {
   		//保证了每个线程中只有一个Looper
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        //调用ThreadLocal.set()方法
        sThreadLocal.set(new Looper(quitAllowed));
    }

-set方法的实现：

    public void set(T value) {
    	//获取到当前线程
        Thread t = Thread.currentThread();
        //获取当前线程绑定的ThreadLocalMap
        ThreadLocalMap map = getMap(t);

		//此处将sThreadLocal对象作为key，将Looper对象作为value，存储在了当前线程绑定的ThreadLocalMap中
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

• get方法的实现

    public T get() {
    	//获取当前线程对应的ThreadLocalMap 
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);

		//在ThreadLocalMap 中取出 key为sThreadLocal对象 的value，即为set中存储的 Looper对象
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }

所有的线程在 调用 Looper.loop()时，因为sThreadLocal是静态的，所以每一个线程对应的ThreadLocalMap存储Looper对象时，都用了同一个sThreadLocal对象作为key。

总结：

• 每一个线程中都有一个ThreadLocalMap的map集合，map的key值为 泛型为不同类型的ThreadLocal静态对象 ，value值为 ThreadLocal静态对象中泛型的实例。
• 当我们创建一个 泛型为A的ThreadLocal静态对象，标记着每个线程的ThreadLocalMap中可以存储一个 key值为ThreadLocal静态对象 value为A对象的键值对

4.Handler的内存泄露

原因

内部类持有外部类的引用 （Handler是一个匿名内部类，它会持有外部Activity的引用

为何其他的内部类不存在内部泄漏

延时发送的Message信息被存放在了Messagequeue中等待发送，因为Message的target持有了Handler对象，而Handler对象作为内部类又持有了外部类的引用，因而会发生内存泄露。而单纯的内部类不具备这种性质所以不会内存泄漏

如何解决

public class MainActivity extends AppCompatActivity {

    private MyHandler myHandler = new MyHandler(this);

	//通过实现静态内部类，消除与外部类的引用关联
    private static class MyHandler extends Handler {

		//使用弱引用，使GC可以在需要时回收mActivity
        private final WeakReference<Activity> mActivity;

        public MyHandler(Activity activity) {
            super(Looper.getMainLooper());
            mActivity = new WeakReference<>(activity);
        }
        @Override
        public void handleMessage(Message msg) {
            System.out.println(msg);
            
			//使用时先判断Actvitiy是否被回收
            if(mActivity.get() == null) {
                return;
            }
        }
    }
    ...
}

5.为何在主线程中Handler可以直接new Handler() 并使用

• ActivityThread 的 main()函数中 调用了 Looper.prepare() -> Looper.loop(); 已经完成了主线程Looper的
• 如果在子线程中使用Looper，必须调用 Looper.prepare() 和 Looper.loop() 函数

6.子线程应该如何维护Looper

1. 创建Looper： Looper.prepare()
2. 创建handler
3. 运行Looper： Looper.loop()
4. 终止 Looper： Looper.quitSafely() 否则子线程无法执行完成

为什么需要调用Looper.quitSafely()

• 子线程中调用Looper.loop()之后，loop()函数内部会一直处在 queue.next() 的等待 与 Message信息发送 的循环中，无法执行下面的语句。
• 当子线程的消息队列为空时，loop()函数中的 queue.next()函数会通过 nativePollOnce(ptr, nextPollTimeoutMillis)底层函数 使线程等待
• 调用Looper.quitSafely()函数 会清空消息队列中的全部消息，并会调用 nativeWake(mPtr) ，使 queue.next()函数中的 nativePollOnce函数 停止等待，从而使queue.next()返回null ，并终止loop()中的for循环(详见源码)。

7.当多个Handler同时向MessageQueue中添加数据，如何保证线程安全

• 在MessageQueue中的 enqueueMessage()插入数据函数 和 next() 取数据函数 中，同存在synchronized同步锁保证了线程的安全性
• Handler.sendMessageDelay()方法中的时间并不准确，因为同步锁存在耗时时间，而Message.when参数在发送时已经被设置。

8.如何合理的创建Message

了解sPool中Message的复用，需要了解Message的数据结构：链表数据结构
使用了享元模式，实现内存共享

应该通过obtain创建 （此时从sPool的头部取出闲置的Message，并减少了sPool的长度）

 public static Message obtain() {
        synchronized (sPoolSync) {
            if (sPool != null) {
                Message m = sPool;
                sPool = m.next;
                m.next = null;
                m.flags = 0; // clear in-use flag
                sPoolSize--;
                return m;
            }
        }
        return new Message();
    }

sPool:
一个Message对象，其链式结构的长度最大限制为50， 其数据结构的每一层级中的 next属性指向的 Message对象的自身属性被擦除 ，它的大小是 在Looper.quitSafely() / Looper.quit() 方法调用后最终在 Message.recycleUnchecked() 函数中往头部添加长度。 在 Message.obtain方法中从头部取出Message对象用于复用，并减少长度。

Message.recycleUnchecked() ： 此时会将清空数据的Message添加到sPool池子中

   @UnsupportedAppUsage
    void recycleUnchecked() {
        // Mark the message as in use while it remains in the recycled object pool.
        // Clear out all other details.
        flags = FLAG_IN_USE;
        what = 0;
        arg1 = 0;
        arg2 = 0;
        obj = null;
        replyTo = null;
        sendingUid = UID_NONE;
        workSourceUid = UID_NONE;
        when = 0;
        target = null;
        callback = null;
        data = null;

        synchronized (sPoolSync) {
            if (sPoolSize < MAX_POOL_SIZE) {
                next = sPool;
                sPool = this;
                sPoolSize++;
            }
        }
    }

9.Looper.loop()中的for循环为什么不会导致应用卡死

• 应用的所有事件都是在 Activity 、 Fragment的 生命周期中处理
• 生命周期函数的调用由 ActivityThread 的 main函数中的 Looper 通过handler机制（H内部类 继承 Handler） 进行统一管理
• Looper.loop()中的for循环中，queue.next()函数在队列为空时处于 block状态，在队列不为空时处于消息处理状态，循环本身并不会导致应用的卡死
• 当主线程的Looper在处理线程队列中的一个Message时，如果占用了过长的时间，此时会导致队列中后续的Message无法得到处理，此时才会引起应用的卡死