Glide 实战与进阶配置指南
Glide 实战与进阶配置指南
在 Android 应用开发中，图片加载是一个极具挑战性的领域。它不仅涉及到网络请求、I/O 操作，更牵扯到复杂的内存管理（OOM 是图片加载最常见的问题）和生命周期管理。Glide，作为 Google 官方推荐的图片加载库，凭借其卓越的缓存机制、高效的 Bitmap 复用池以及与 Android 生命周期的深度绑定，成为了业界标杆。
本文将摒弃简单的 API 罗列，深入探讨 Glide 的进阶使用场景、全局配置方案以及在复杂列表中的性能调优策略。
一、 核心请求链路与配置
Glide 的流式 API 设计非常直观：with() 绑定生命周期，load() 指定数据源，into() 指定目标。但在工业级应用中，我们需要对这个流程进行精细化控制。
1.1 RequestOptions 与变换（Transformations）
在早期版本的 Glide 中，各种配置项散落在 DrawableRequestBuilder 中。而在目前的 Glide V4 中，所有与特定请求相关的配置都被抽离到了 RequestOptions 中。
val options = RequestOptions()
.placeholder(R.drawable.ic_placeholder)
.error(R.drawable.ic_error)
.override(500, 500) // 强制指定加载的宽高
.format(DecodeFormat.PREFER_RGB_565) // 降低内存消耗，默认是 ARGB_8888
Glide.with(context)
.load(imageUrl)
.apply(options)
.into(imageView)
深入理解 Transformations：
当我们调用 .circleCrop() 或应用自定义 Transformation 时，Glide 并不是在主线程对原始 Bitmap 进行裁剪，而是在后台解码线程（DecodeJob）完成这些 CPU 密集型操作。
如果你需要同时应用多个变换（例如：先裁剪后模糊），必须使用 MultiTransformation 或 .transforms()，直接多次调用 .transform() 会导致后一个覆盖前一个。
Glide.with(context)
.load(url)
// 顺序极其重要：先 CenterCrop 保证比例，再进行模糊，否则边缘模糊效果会被裁剪掉
.transforms(CenterCrop(), BlurTransformation(context, 25))
.into(imageView)
1.2 磁盘缓存策略的抉择（DiskCacheStrategy）
Glide 强大的原因之一在于其多层磁盘缓存设计。它不仅缓存原始数据（Data），还缓存经过变换后的结果（Resource）。通过 DiskCacheStrategy，我们可以控制缓存行为：
AUTOMATIC(默认): Glide 智能选择。如果是远程图片，只缓存原始数据；如果是本地图片，缓存变换后的结果。ALL: 既缓存原始数据，也缓存变换后的结果。这会占用更多磁盘空间，但在需要展示同一张图片的多种尺寸/形变时（如列表页用小图，详情页用大图），能极大提升加载速度。DATA: 只缓存未被处理过的原始数据（如网络下载的完整原图）。RESOURCE: 只缓存经过降采样、变换后的最终 Bitmap 数据。NONE: 彻底关闭磁盘缓存。
实战场景：
假设你的 App 中有一个用户头像，用户在其他设备上更改了头像，但 URL 并没有变（这在很多使用 OSS 的系统中很常见）。此时如果使用默认缓存，客户端会一直显示旧头像。
解法 1： 使用 signature() 添加时间戳或版本号作为缓存的附加 Key。
解法 2： 如果你确定该图片每次都要实时拉取，可以配置为 .diskCacheStrategy(DiskCacheStrategy.NONE).skipMemoryCache(true)。
二、 全局配置架构：AppGlideModule
在大型项目中，我们通常需要替换 Glide 的底层网络组件（例如用 OkHttp 替换默认的 HttpURLConnection），或者修改全局的缓存大小和 Bitmap 格式。这时需要使用 AppGlideModule。
通过 @GlideModule 注解，Glide 的注解处理器（Annotation Processor）会在编译时生成一个 GlideApp 类，提供更符合 Fluent API 风格的调用方式。
2.1 替换网络组件库为 OkHttp
默认的 HTTP 客户端在处理复杂网络环境（如连接池复用、HTTP/2 支持）时显得力不从心。我们可以通过注册组件，将 Glide 的网络层桥接到已有的 OkHttp 实例上，从而共享连接池和拦截器。
@GlideModule
class MyAppGlideModule : AppGlideModule() {
override fun applyOptions(context: Context, builder: GlideBuilder) {
// 配置全局内存缓存大小
val memoryCacheSizeBytes = 1024 * 1024 * 20 // 20mb
builder.setMemoryCache(LruResourceCache(memoryCacheSizeBytes.toLong()))
// 配置全局 Bitmap 格式为 RGB_565 (不包含透明度，内存减半)
builder.setDefaultRequestOptions(
RequestOptions().format(DecodeFormat.PREFER_RGB_565)
)
}
override fun registerComponents(context: Context, glide: Glide, registry: Registry) {
// 替换底层的 ModelLoader
// 假设已经有一个配置好的 OkHttpClient 全局实例
val okHttpClient = OkHttpClientManager.getGlobalClient()
registry.replace(
GlideUrl::class.java,
InputStream::class.java,
OkHttpUrlLoader.Factory(okHttpClient)
)
}
// 关闭清单解析，提升初始化速度
override fun isManifestParsingEnabled(): Boolean = false
}
三、 极致列表性能调优
在长列表（RecyclerView）中快速滑动时，如果图片加载逻辑不当，会引发严重的卡顿甚至 OOM。除了 Glide 自身的生命周期绑定，我们还需要在业务侧进行一些极限优化。
3.1 滑动时暂停加载 (Pause/Resume Requests)
当用户在快速 Fling 列表时，屏幕上闪过的图片其实并不需要真正被加载出来。让 Glide 在快速滑动时暂停所有的网络请求和解码任务，可以把宝贵的 CPU 资源和网络带宽让给列表的 Layout 和绘制。
recyclerView.addOnScrollListener(object : RecyclerView.OnScrollListener() {
override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) {
super.onScrollStateChanged(recyclerView, newState)
if (newState == RecyclerView.SCROLL_STATE_DRAGGING ||
newState == RecyclerView.SCROLL_STATE_SETTLING) {
// 滑动时暂停请求
Glide.with(context).pauseRequests()
} else if (newState == RecyclerView.SCROLL_STATE_IDLE) {
// 停止滑动时恢复请求
Glide.with(context).resumeRequests()
}
}
})
3.2 预加载机制 (Preloading)
为了实现类似 TikTok 那样的“零延迟”滚动体验，除了使用 ViewPager2，我们还可以利用 Glide 的预加载功能。
通过 Glide.with(context).load(url).preload(width, height)，Glide 会将图片提前下载并解码放入内存缓存中。当后续通过 into(imageView) 发起实际请求时，Glide 会直接命中内存缓存，实现瞬间渲染。
结合 RecyclerView 的 RecyclerViewPreloader，可以在用户即将滑动到特定位置前，提前触发几个 item 的图片预加载，从根本上消灭“白块”现象。
四、 总结
Glide 的 API 设计看似简单，但其底层隐藏了大量的策略与优化。熟练掌握 DiskCacheStrategy 的差异、理解如何利用 AppGlideModule 接入自定义的网络栈，以及在快速滚动场景中巧妙地暂停与预加载，是区分初级开发者与架构级工程师的重要标志。在接下来的章节中，我们将撕开 Glide 的源码外衣，深入探究其生命周期注入机制、线程池调度以及多级缓存的底层实现。