本质上，Glide 并不是“监听”或“观察” Activity，而是利用了 Android 系统给组件设定的生命周期回调强制执行规则，玩了一手“寄生”。
我把这个“自动管理”的底层流水线拆解为 4 个核心步骤，你一看就明白了：
第 1 步：偷偷“注入”一个隐形管家（创建空 Fragment）
当你调用Glide.with(this)时，Glide 内部会通过RequestManagerRetriever做一个小动作：
它拿到当前 Activity 的
FragmentManager（碎片管理器）。调用
beginTransaction.add()，向 Activity 的 View 树里添加一个隐藏的、大小为 0dp 的空白 Fragment（通常是SupportRequestManagerFragment）。
关键点：这个 Fragment 没有 UI，唯一的作用就是“寄生”在 Activity 的生命周期队列里。只要 Activity 活着，这个 Fragment 就跟着活着；Activity 被系统销毁，这个 Fragment 也必须执行销毁回调。
第 2 步：建立“订阅-通知”通道（注册监听器）
这个空 Fragment 内部维护了一个ActivityFragmentLifecycle类（可以理解为事件分发中心）。
在创建
RequestManager（图片请求总管）时，Glide 会把这个RequestManager作为监听器注册到空 Fragment 的Lifecycle列表里。此时，通道建立完毕：系统 -> 空 Fragment -> RequestManager。
第 3 步：系统强制回调触发“自动化”（执行映射逻辑）
这一步就是你要的“怎么样管理”。当用户操作手机时，Android 系统会强制调用 Fragment 的生命周期方法，Glide 只是在方法里塞入了对应的代码：
| 系统回调 | 空 Fragment 执行的动作 | 对 RequestManager 的实际影响 |
|---|---|---|
onStop()（按 Home 键或跳转新页面） | 遍历监听器列表，调用lifecycle.onStop() | 调用requestManager.pauseRequests()。网络请求立即暂停，正在解码的线程被中断，避免后台消耗 CPU。 |
onStart()（返回前台） | 遍历监听器，调用lifecycle.onStart() | 调用requestManager.resumeRequests()。恢复网络连接，继续读取流数据（不是重头下载，是断点续传）。 |
onDestroy()（Activity 被销毁） | 遍历监听器，调用lifecycle.onDestroy() | 调用requestManager.destroy()。遍历所有正在进行的请求，强制 clear()，回收 ImageView 的引用，防止 OOM 和内存泄漏。 |
第 4 步：特殊的“旋转屏幕”保活机制（setRetainInstance）
如果只是上面的逻辑，屏幕旋转时 Activity 重建，图片会被取消重下，这很浪费。
因此，Glide 在创建这个空 Fragment 时，会调用setRetainInstance(true)。
效果：当屏幕旋转时，这个空 Fragment不会被销毁，而是直接脱离旧的 Activity，附着到新的 Activity 上。
结果：因为 Fragment 没销毁，
onDestroy不会被调用，所以 Glide不会取消正在加载的图片。新 Activity 创建后，直接复用之前的下载进度，加载完直接显示，极其流畅。
一个核心“例外”让你更通透
如果你在子线程中调用Glide.with(context)，Glide 会检测到线程不是主线程，直接放弃绑定 Activity 生命周期，转而绑定Application的全局生命周期。
因为子线程无法操作FragmentManager（会报错），且子线程加载图片通常用于预加载缓存，不需要绑定页面可见性。这时候，“自动管理”失效，完全依赖你手动调用clear()。
总结一句话：Glide 不做主动监听，而是把自己伪装成系统必须照顾的“子组件”，借助系统强制执行的onStop/onDestroy回调，来触发自己的暂停和清理代码。
