Glide 三部曲之请求生命周期管控

通过查看这几段源码，我们可以得出一个结论，Glide 拿到 FragmentActivity 的用处是为了在 Activity 里面创建一个 Fragment，那么问题又来了，它创建 Fragment 是要做什么事？接下来让我们继续追踪一下源码。

接下来让我们把目光放到一个类上面，ActivityFragmentLifecycle，光看名字就知道这个是我们要讲的主角之一：生命周期管理，接下来我们看看这个类在 Fragment 里面做了什么事

那么问题又来了，Glide 这样做的目的又是什么？是为了解决什么问题而做的？
这个问题非常值得我们去思考，首先我们要知道，Glide 是通过网络请求获取图片的资源，网络请求是异步的，也就是必须在子线程中，而 Activity 是运行在主线程中，正常的情况是 Glide 请求完毕之后 Activity 再销毁，但是这个并不能代表所有的请求都会按照这个逻辑来执行，往往是 Glide 还没有请求完毕 Activity 已经销毁了这种情况也非常常见，为了避免这种情况，我们必须知道 Activity 什么时候销毁，然后赶在 Activity 销毁之前把网络请求取消。
这个时候 Fragment 发挥了很大的作用，我们都知道 Fragment 是依附于 Activity，同时这两者的生命周期是绑定在一起的，Glide 通过 Fragment 的生命周期就能知道 Activity 的生命周期。
那么问题又来了，刚刚 Glide.with 有很多重载方法，万一它传入的不是 FragmentActivity，而是其他类型的对象，那么 Glide 又会怎么处理呢？
我就是不给你传入 FragmentActivity，而是直接传入 Activity，让 Glide 创建不了 Fragment 对象，这样它就监听不到 Activity 的生命周期了
接下来让我们看看 Glide 应对 Activity 对象会做什么不一样的处理？

看到这里，我们要纠正一个误区，不是一定要 FragmentActivity 才能创建 Fragment，其实 Activity 对象也是可以的，只不过这个是 Android 3.0 之后的特性
app.Fragment、support.Fragment 的思想和用法和 Activity 和 Fragment Activity 大同小异，这里直接略过
再来跟大家讲讲 Fragment，它又是怎么监听生命周期的

分析上面的源码，我们可以知道，你如果给 Glide 传入的是一个 Context 对象，它会自动推导 Context 的类型，究竟是 FragmentActivity 呢还是 Activity 呢，如果两种都不是呢？万一是 Application 的 Context 呢？接下来继续看源码

看到这段源码，我们又发现了一个 Lifecycle 类，只不过这次跟我们之前看到的 ActivityFragmentLifecycle 类不一样，因为它换了一个马甲：ApplicationLifecycle

让我们再回顾一下这个类，经过比对不难发现，ApplicationLifecycle 类没有生命周期之类的方法回调
所以到这里，我们也不难断定，当我们传入的 Context 对象经过推导之后不是 Activity 或者 FragmentActivity 对象，那么 Glide 会把这个请求当做一个全局请求，何为全局请求，请求的生命周期和应用的生命周期保持一致，只要应用不被杀死，那么这个网络请求在请求完毕之前就不会消失。

Glide 请求生命周期主要利用一个无界面的 Fragment，然后绑定到 Activity / Fragment 上面，由此来感知 Activity / Fragment 的生命周期，从而赶在 Activity / Fragment 对象销毁之前把网络请求移除掉，另外如果我们传入的 Context 对象不是 Activity / Fragment，Glide 会默认将这个网络请求作为一个全局请求，这样就完成了 Glide 对网络请求的生命周期控制。