Handler的初级、中级、高级问法，你都掌握了吗？

八卦谈佚名 ▪ 2024-03-06 06:29:25

Handler是Android中的消息处理机制，是一种线程间通信的解决方案，同时你也可以理解为它天然的为我们在主线程创建一个队列，队列中的消息顺序就是我们设置的延迟的时间，如果你想在Android中实现一个队列的功能，不妨第一时间考虑一下它。本文分为三部分：

Handler的源码和常见问题的解答

一个线程中最多有多少个Handler，Looper，MessageQueue？
Looper死循环为什么不会导致应用卡死，会耗费大量资源吗？
子线程的如何更新UI，比如Dialog，Toast等？系统为什么不建议子线程中更新UI?
主线程如何访问网络？
如何处理Handler使用不当造成的内存泄漏？
Handler的消息优先级，有什么应用场景？
主线程的Looper何时退出？能否手动退出？
如何判断当前线程是安卓主线程？
正确创建Message实例的方式？

Handler深层次问题解答

ThreadLocal
epoll机制
Handle同步屏障机制
Handler的锁相关问题
Handler中的同步方法

Handler在系统以及第三方框架的一些应用

HandlerThread
IntentService
如何打造一个不崩溃的APP
Glide中的运用

Handler的源码和常见问题的解答

下面来看一下官方对其的定义：

A Handler allows you to send and process Message and Runnable objects associated with a thread's MessageQueue.
Each Handler instance is associated with a single thread and that thread's message queue. When you create a new Handler it is bound to a Looper.
It will deliver messages and runnables to that Looper's message queue and execute them on that Looper's thread.
大意就是Handler允许你发送Message/Runnable到线程的消息队列(MessageQueue)中，每个Handler实例和一个线程以及那个线程的消息队列相关联。当你创建一个Handler时应该和一个Looper进行绑定（主线程默认已经创建Looper了，子线程需要自己创建Looper），它向Looper的对应的消息队列传送Message/Runnable同时在那个Looper所在线程处理对应的Message/Runnable。下面这张图就是Handler的工作流程
Handler工作流程图

可以看到在Thread中，Looper的这个传送带其实就一个死循环，它不断的从消息队列MessageQueue中不断的取消息，最后交给Handler.dispatchMessage进行消息的分发，而Handler.sendXXX,Handler.postXXX这些方法把消息发送到消息队列中MessageQueue，整个模式其实就是一个生产者-消费者模式，源源不断的生产消息，处理消息，没有消息时进行休眠。MessageQueue是一个由单链表构成的优先级队列（取的都是头部，所以说是队列）。
前面说过，当你创建一个Handler时应该和一个Looper进行绑定（绑定也可以理解为创建，主线程默认已经创建Looper了，子线程需要自己创建Looper），因此我们先来看看主线程中是如何处理的：

可以看到在ActivityThread中的main方法中，我们先调用了Looper.prepareMainLooper()方法，然后获取当前线程的Handler，最后调用Looper.loop()。先来看一下Looper.prepareMainLooper()方法

可以看到在Looper.prepareMainLooper()方法中创建了当前线程的Looper，同时将Looper实例存放到线程局部变量sThreadLocal(ThreadLocal)中，也就是每个线程有自己的Looper。在创建Looper的时候也创建了该线程的消息队列，可以看到prepareMainLooper会判断sMainLooper是否有值，如果调用多次，就会抛出异常，所以也就是说主线程的Looper和MessageQueue只会有一个。同理子线程中调用Looper.prepare()时，会调用prepare(true)方法，如果多次调用，也会抛出每个线程只能由一个Looper的异常，总结起来就是每个线程中只有一个Looper和MessageQueue。

再来看看主线程sMainThreadHandler = thread.getHandler()，getHandler获取到的实际上就是mH这个Handler。

mH这个Handler是ActivityThread的内部类，通过查看handMessage方法，可以看到这个Handler处理四大组件，Application等的一些消息，比如创建Service，绑定Service的一些消息。

最后我们查看Looper.loop()方法

在loop方法中是一个死循环，在这里从消息队列中不断的获取消息queue.next()，然后通过Handler(msg.target)进行消息的分发，其实并没有什么具体的绑定，因为Handler在每个线程中对应只有一个Looper和消息队列MessageQueue，自然要靠它来处理，也就是是调用Looper.loop()方法。在Looper.loop()的死循环中不断的取消息，最后回收复用。

这里要强调一下Message中的参数target(Handler)，正是这个变量，每个Message才能找到对应的Handler进行消息分发，让多个Handler同时工作。

再来看看子线程中是如何处理的，首先在子线程中创建一个Handler并发送Runnable

运行后可以看到错误日志，可以看到提示我们需要在子线程中调用Looper.prepare()方法，实际上就是要创建一个Looper和你的Handler进行“关联”。

添加Looper.prepare()创建Looper，同时调用Looper.loop()方法开始处理消息。

这里需要注意在所有事情处理完成后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于循环等待的状态，因此不需要的时候终止Looper，调用Looper.myLooper().quit()。

看完上面的代码可能你会有一个疑问，在子线程中更新UI（进行Toast）不会有问题吗，我们Android不是不允许在子线程更新UI吗，实际上并不是这样的，在ViewRootImpl中的checkThread方法会校验mThread != Thread.currentThread(),mThread的初始化是在ViewRootImpl的的构造器中，也就是说一个创建ViewRootImpl线程必须和调用checkThread所在的线程一致，UI的更新并非只能在主线程才能进行。

这里需要引入一些概念，Window是Android中的窗口，每个Activity和Dialog，Toast分别对应一个具体的Window，Window是一个抽象的概念，每一个Window都对应着一个View和一个ViewRootImpl，Window和View通过ViewRootImpl来建立联系，因此，它是以View的形式存在的。我们来看一下Toast中的ViewRootImpl的创建过程，调用toast的show方法最终会调用到其handleShow方法

这个mWM（WindowManager）的最终实现者是WindowManagerGlobal，其的addView方法中会创建ViewRootImpl，然后进行root.setView(view, wparams, panelParentView)，通过ViewRootImpl来更新界面并完成Window的添加过程。

setView内部会通过requestLayout来完成异步刷新请求，同时也会调用checkThread方法来检验线程的合法性。

因此，我们的ViewRootImpl的创建是在子线程，所以mThread的值也是子线程，同时我们的更新也是在子线程，所以不会产生异常，同时也可以参考这篇文章分析，写的非常详细。同理下面的代码也可以验证这个情况

在子线程中调用showDialog方法，先调用alertDialog.show()方法，再调用alertDialog.hide()方法，hide方法只是将Dialog隐藏，并没有做其他任何操作(没有移除Window)，然后再在主线程调用alertDialog.show()；便会抛出Only the original thread that created a view hierarchy can touch its views异常了。

2020-11-09 18:35:39.874 24819-24819/com.jackie.testdialog E/AndroidRuntime: FATAL EXCEPTION: main Process: com.jackie.testdialog, PID: 24819 android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views. at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:8191) at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1420) at android.view.View.requestLayout(View.java:24454) at android.view.View.setFlags(View.java:15187) at android.view.View.setVisibility(View.java:10836) at android.app.Dialog.show(Dialog.java:307) at com.jackie.testdialog.HandlerActivity$2.onClick(HandlerActivity.java:41) at android.view.View.performClick(View.java:7125) at android.view.View.performClickInternal(View.java:7102)

所以在线程中更新UI的重点是创建它的ViewRootImpl和checkThread所在的线程是否一致。

如何在主线程中访问网络

在网络请求之前添加如下代码

StrictMode（严苛模式）Android2.3引入，用于检测两大问题：ThreadPolicy（线程策略）和VmPolicy(VM策略)，这里把严苛模式的网络检测关了，就可以在主线程中执行网络操作了，一般是不建议这么做的。关于严苛模式可以查看这里。

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

这是因为 Android 的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：

首先加上锁机制会让UI访问的逻辑变得复杂
锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。

所以最简单且高效的方法就是采用单线程模型来处理UI操作。（安卓开发艺术探索）

子线程如何通知主线程更新UI（都是通过Handle发送消息到主线程操作UI的）

主线程中定义 Handler，子线程通过 mHandler 发送消息，主线程 Handler 的 handleMessage 更新UI。
用 Activity 对象的 runOnUiThread 方法。
创建 Handler，传入 getMainLooper。
View.post(Runnable r) 。

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

从前面的主线程、子线程的分析可以看出，Looper会在线程中不断的检索消息，如果是子线程的Looper死循环，一旦任务完成，用户应该手动退出，而不是让其一直休眠等待。（引用自Gityuan）线程其实就是一段可执行的代码，当可执行的代码执行完成后，线程的生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出，例如，binder 线程也是采用死循环的方法，通过循环方式不同与 Binder 驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。Android是基于消息处理机制的，用户的行为都在这个Looper循环中，我们在休眠时点击屏幕，便唤醒主线程继续进行工作。

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

主线程的Looper何时退出

在App退出时，ActivityThread中的mH（Handler）收到消息后，执行退出。

如果你尝试手动退出主线程Looper，便会抛出如下异常

为什么不允许退出呢，因为主线程不允许退出，一旦退出就意味着程序挂了，退出也不应该用这种方式退出。

Handler的消息处理顺序

在Looper执行消息循环loop()时会执行下面这行代码，msg.targe就是这个Handler对象

我们来看看dispatchMessage的源码

如果Message这个对象有CallBack回调的话，这个CallBack实际上是个Runnable，就只执行这个回调，然后就结束了，创建该Message的CallBack代码如下：

而handleCallback方法中调用的是Runnable的run方法。

2. 如果Message对象没有CallBack回调，进入else分支判断Handler的CallBack是否为空，不为空执行CallBack的handleMessage方法，然后return，构建Handler的CallBack代码如下：

最后才调用到Handler的handleMessage()函数，也就是我们经常去重写的函数，在该方法中做消息的处理。

使用场景

可以看到Handler.Callback 有优先处理消息的权利 ，当一条消息被 Callback 处理并拦截（返回 true），那么 Handler 的 handleMessage(msg) 方法就不会被调用了；如果 Callback 处理了消息，但是并没有拦截，那么就意味着一个消息可以同时被 Callback 以及 Handler 处理。我们可以利用CallBack这个拦截来拦截Handler的消息。

场景：Hook ActivityThread.mH ，在 ActivityThread 中有个成员变量 mH ，它是个 Handler，又是个极其重要的类，几乎所有的插件化框架都使用了这个方法。

Handler.post(Runnable r)方法的执行逻辑

我们需要分析平时常用的Handler.post(Runnable r)方法是如何执行的，是否新创建了一个线程了呢，实际上并没有，这个Runnable对象只是被调用了它的run方法，根本并没有启动一个线程，源码如下：

最终该Runnable对象被包装成一个Message对象，也就是这个Runnable对象就是该Message的CallBack对象了，有优先执行的权利了。

Handler是如何进行线程切换的

原理很简单，线程间是共享资源的，子线程通过handler.sendXXX，handler.postXXX等方法发送消息，然后通过Looper.loop()在消息队列中不断的循环检索消息，最后交给handle.dispatchMessage方法进行消息的分发处理。

如何处理Handler使用不当造成的内存泄漏？

有延时消息，在界面关闭后及时移除Message/Runnable，调用handler.removeCallbacksAndMessages(null)
内部类导致的内存泄漏改为静态内部类，并对上下文或者Activity/Fragment使用弱引用。

具体内存泄漏的分析和解决可以参考这篇文章。同时还有一个很关键的点，如果有个延时消息，当界面关闭时，该Handler中的消息还没有处理完毕，那么最终这个消息是怎么处理的？经过测试，比如我打开界面后延迟10s发送消息，关闭界面，最终在Handler（匿名内部类创建的）的handMessage方法中还是会收到消息（打印日志）。因为会有一条MessageQueue -> Message -> Handler -> Activity的引用链，所以Handler不会被销毁，Activity也不会被销毁。

正确创建Message实例

通过 Message 的静态方法 Message.obtain() 获取；
通过 Handler 的公有方法 handler.obtainMessage()

所有的消息会被回收，放入sPool中，使用享元设计模式。

Handler深层次问题解答

ThreadLocal

ThreadLocal为每个线程都提供了变量的副本，使得每个线程在某一时间访问到的并非同一个对象，这样就隔离了多个线程对数据的数据共享。

如果让你设计一个ThreadLocal，ThreadLocal 的目标是让不同的线程有不同的变量 V，那最直接的方法就是创建一个 Map，它的 Key 是线程，Value 是每个线程拥有的变量 V，ThreadLocal 内部持有这样的一个 Map 就可以了。你可能会设计成这样

实际上Java的实现是下面这样，Java 的实现里面也有一个 Map，叫做 ThreadLocalMap，不过持有 ThreadLocalMap 的不是 ThreadLocal，而是 Thread。Thread 这个类内部有一个私有属性 threadLocals，其类型就是 ThreadLocalMap，ThreadLocalMap 的 Key 是 ThreadLocal。

精简之后的代码如下

在Java的实现方案中，ThreadLocal仅仅只是一个代理工具类，内部并不持有任何线程相关的数据，所有和线程相关的数据都存储在Thread里面，这样的设计从数据的亲缘性上来讲，ThreadLocalMap属于Thread也更加合理。所以ThreadLocal的get方法，其实就是拿到每个线程独有的ThreadLocalMap。

还有一个原因，就是不容易产生内存泄漏，如果用我们的设计方案，ThreadLocal持有的Map会持有Thread对象的引用，这就意味着只要ThreadLocal对象存在，那么Map中的Thread对象就永远不会被回收。ThreadLocal的生命周期往往都比线程要长，所以这种设计方案很容易导致内存泄漏。

而Java的实现中Thread持有ThreadLocalMap，而且ThreadLocalMap里对ThreadLocal的引用还是弱引用，所以只要Thread对象可以被回收，那么ThreadLocalMap就能被回收。Java的实现方案虽然看上去复杂一些，但是更安全。

ThreadLocal与内存泄漏

但是一切并不总是那么完美，如果在线程池中使用ThreadLocal可能会导致内存泄漏，原因是线程池中线程的存活时间太长，往往和程序都是同生共死的，这就意味着Thread持有的ThreadLocalMap一直都不会被回收，再加上ThreadLocalMap中的Entry对ThreadLocal是弱引用，所以只要ThreadLocal结束了自己的生命周期是可以被回收掉的。但是Entry中的Value却是被Entry强引用的，所以即便Value的生命周期结束了，Value也是无法被回收的，从而导致内存泄漏。

所以我们可以通过try{}finally{}方案来手动释放资源

以上ThreadLocal内容主要参考自这里。

epoll机制

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

这里有一篇深度好文聊聊IO多路复用之select,poll,epoll详解，这边拿文章中的最后两段话：

表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

之所以选择Handler底层选择epoll机制，我感觉是epoll在效率上更高。在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。)

Handler的同步屏障机制

如果有一个紧急的Message需要优先处理，该怎么做？这其实涉及到架构方面的设计了，通用场景和特殊场景的设计。你可能会想到sendMessageAtFrontOfQueue()这个方法，实际也远远不只是如此，Handler中加入了同步屏障这种机制，来实现[异步消息优先]执行的功能。

postSyncBarrier()发送同步屏障，removeSyncBarrier()移除同步屏障

同步屏障的作用可以理解成拦截同步消息的执行，主线程的 Looper 会一直循环调用 MessageQueue 的 next() 来取出队头的 Message 执行，当 Message 执行完后再去取下一个。当 next() 方法在取 Message 时发现队头是一个同步屏障的消息时，就会去遍历整个队列，只寻找设置了异步标志的消息，如果有找到异步消息，那么就取出这个异步消息来执行，否则就让 next() 方法陷入阻塞状态。如果 next() 方法陷入阻塞状态，那么主线程此时就是处于空闲状态的，也就是没在干任何事。所以，如果队头是一个同步屏障的消息的话，那么在它后面的所有同步消息就都被拦截住了，直到这个同步屏障消息被移除出队列，否则主线程就一直不会去处理同步屏幕后面的同步消息。

而所有消息默认都是同步消息，只有手动设置了异步标志，这个消息才会是异步消息。另外，同步屏障消息只能由内部来发送，这个接口并没有公开给我们使用。

Choreographer 里所有跟 message 有关的代码，你会发现，都手动设置了异步消息的标志，所以这些操作是不受到同步屏障影响的。这样做的原因可能就是为了尽可能保证上层 app 在接收到屏幕刷新信号时，可以在第一时间执行遍历绘制 View 树的工作。

Choreographer 过程中的动作也都是异步消息，这样可以确保 Choreographer 的顺利运转，也确保了第一时间执行 doTraversal（doTraversal → performTraversals 就是执行 view 的 layout、measure、draw），这个过程中如果有其他同步消息，也无法得到处理，都要等到 doTraversal 之后。

因为主线程中如果有太多消息要执行，而这些消息又是根据时间戳进行排序，如果不加一个同步屏障的话，那么遍历绘制 View 树的工作就可能被迫延迟执行，因为它也需要排队，那么就有可能出现当一帧都快结束的时候才开始计算屏幕数据，那即使这次的计算少于 16.6ms，也同样会造成丢帧现象。

那么，有了同步屏障消息的控制就能保证每次一接收到屏幕刷新信号就第一时间处理遍历绘制 View 树的工作么？

只能说，同步屏障是尽可能去做到，但并不能保证一定可以第一时间处理。因为，同步屏障是在 scheduleTraversals() 被调用时才发送到消息队列里的，也就是说，只有当某个 View 发起了刷新请求时，在这个时刻后面的同步消息才会被拦截掉。如果在 scheduleTraversals() 之前就发送到消息队列里的工作仍然会按顺序依次被取出来执行。

下面是部分详细的分析：

WindowManager维护着所有的Activity的DecorView和ViewRootImpl。在前面我们讲过，WindowManagerGlobal的addView方法中中初始化了ViewRootImpl，然后调用它的setView方法，将DecorView作为参数传递了进去。所以我们看看ViewRootImpl做了什么

在setView()方法里调用了DecorView的assignParent

参数是ViewParent，而ViewRootImpl是实现了ViewParent接口的，所以在这里就将DecorView和ViewRootImpl绑定起来了。每个Activity的根布局都是DecorView，而DecorView的parent又是ViewRootImpl，所以在子View里执行invalidate()之类的工作，循环找parent，最后都会找到ViewRootImpl里来。所以实际上View的刷新都是由ViewRootImpl来控制的。

即使是界面上一个小小的 View 发起了重绘请求时，都要层层走到 ViewRootImpl，由它来发起重绘请求，然后再由它来开始遍历 View 树，一直遍历到这个需要重绘的 View 再调用它的 onDraw() 方法进行绘制。

View.invalidate()请求重绘的操作最后调用到的是ViewRootImpl.scheduleTraversals()，而ViewRootImpl.setView()方法中调用了requestLayout方法

最终也调用到了scheduleTraversals()方法，其实这个方法是屏幕刷新的关键。

其实打开一个 Activity，当它的 onCreate---onResume 生命周期都走完后，才将它的 DecoView 与新建的一个 ViewRootImpl 对象绑定起来，同时开始安排一次遍历 View 任务也就是绘制 View 树的操作等待执行，然后将 DecoView 的 parent 设置成 ViewRootImpl 对象。所以我们在onCreate~onResume中获取不到View宽高，界面的绘制也是在onResume之后才开始执行的。可以参考我前面的文章分析。

ViewRootImpl.scheduleTraversals()的一系列分析以及屏幕刷新机制可以参考这篇文章，这里的内容也是大部分参考它的，同步屏障相关的分析内容也在里面。

Choreographer主要作用是协调动画，输入和绘制的时间，它从显示子系统接收定时脉冲（例如垂直同步），然后安排渲染下一个frame的一部分工作。

可通过Choreographer.getInstance().postFrameCallback()来监听帧率情况；

调用方式在Application中注册

丢帧的原因：造成丢帧大体上有两类原因，一是遍历绘制 View 树计算屏幕数据的时间超过了 16.6ms；二是，主线程一直在处理其他耗时的消息，导致遍历绘制 View 树的工作迟迟不能开始，从而超过了 16.6 ms 底层切换下一帧画面的时机。

Handler锁相关问题

既然可以存在多个Handler往MessageQueue中添加数据（发送消息时各个Handler可能处于不同线程），那它内部是如何确保线程安全的？

Handler.sendXXX，Handler.postXXX最终会会调到MessageQueue的enqueueMessage方法

源码如下：

其内部通过synchronized关键字保证线程安全。同时messagequeue.next()内部也会通过synchronized加锁，确保取的时候线程安全，同时插入也会加锁。这个问题其实不难，只是看你有没有了解源码。

Handler中的同步方法

如何让handler.post消息执行之后然后再继续往下执行，同步方法runWithScissors

Handler在系统以及第三方框架的一些应用

HandlerThread

HandlerThread继承于Thread，顾名思义，实际上是Handler和Thread的一个封装，已经为我们封装的很好很安全了，内部也通过synchronized来保证线程安全，比如getLooper方法

在线程的run方法里，所以当线程启动之后才能创建Looper并赋值给mLooper，这里的阻塞就是为了等待Looper的创建成功。同时该方法是用Public修饰的，说明该方法是提供外部调用的，Looper创建成功提供给外部使用。

IntentService

简单看一下源码就能看到Handler的应用，Handler的handMessage最终会回调到onHandleIntent方法。

如何打造一个不崩溃的程序

打造一个不崩溃的程序，可以参考我的这篇文章

Glide中的应用

Glide 相信大应该非常熟悉了，我们都知道Glide生命周期的控制（如果不了解，可以看下Glide相关文章的分析，跟LiveData 是同一个原理）是通过添加一个空的Fragment到Activity 或者Fragment中，然后通过FragmentMannager管理Fragment的生命周期，从而达到生命周期的控制。下面是节选了Glide一段添加Fragment的代码：

看了上面的代码，大家可能会有疑惑。

Fragment添加到FragmentManager为什么还要保存到map容器里（第4步）？
判断Fragment是否已添加为啥还要从map容器判断（第2步），FragmentManager 去find 不就可以做到了吗？

其实答案很简单，学了Handler原理之后我们知道：就是在第5步执行完之后并没有将Fragment添加到FragmentManager（事件排队中），而是发送添加Fragment的事件。接下来我们看代码

添加Fragment 最终会走到FragmentManagerImpl的 scheduleCommit方法，我们可以看到他是通过Handler 发送事件。

这也就解释了为什么第5步执行完之后Fragment为什么没有立即添加到FragmentManager，所以需要Map缓存Fragment来标记是否有Fragment添加。再接着有了第6步发送移除Map缓存的消息，因为Handler处理消息是有序的。