Android图片加载框架 Glide全面解析

一、什么是Glide

Glide 是 Android 平台最主流的图片加载与缓存框架，核心目标是：高效、安全、与生命周期强绑定地加载图片。专门解决 Android 系统中图片加载的各种痛点（比如内存溢出、加载慢、缓存管理复杂等），也是 Google 官方推荐的图片加载方案。

二、Glide基础使用

接入依赖

// 核心依赖 implementation 'com.github.bumptech.glide:glide:4.16.0' annotationProcessor 'com.github.bumptech.glide:compiler:4.16.0' // 可选：支持OkHttp作为网络请求引擎（推荐） implementation 'com.github.bumptech.glide:okhttp3-integration:4.16.0'

最简单的使用：Glide的核心设计是“流式API”，最基础的图片加载仅需一行

// 加载网络图片到ImageView Glide.with(context) // 绑定生命周期（Context/Activity/Fragment） .load("https://example.com/image.jpg") // 图片地址（网络/本地/资源ID） .into(imageView); // 目标ImageView

实际开发中可以对图片进行更多的控制

Glide.with(context) .load(imageUrl) // 占位图：加载中显示 .placeholder(R.drawable.placeholder) // 错误图：加载失败显示 .error(R.drawable.error) // 裁剪：按ImageView大小裁剪（避免拉伸） .centerCrop() // 缓存策略：跳过内存缓存（仅示例，按需使用） .skipMemoryCache(true) // 磁盘缓存策略：仅缓存原始图片 .diskCacheStrategy(DiskCacheStrategy.ORIGINAL) // 超时时间：设置网络请求超时（需结合OkHttp） .timeout(10000) // 缩略图：先加载10%清晰度的缩略图，再加载原图 .thumbnail(0.1f) .into(imageView);

另外 Glide 的一大优势是原生支持动图和视频帧加载

// 加载Gif动图 Glide.with(context) .asGif() // 指定加载Gif .load(gifUrl) .into(imageView); // 加载视频第一帧（本地视频路径） Glide.with(context) .asBitmap() // 指定加载静态位图 .load(Uri.fromFile(new File(videoPath))) .into(imageView);

三、 Glide的缓存原理

Glide 的高性能核心在于 “双层缓存 + 智能缓存策略”—— 它会优先从内存取图，内存没有再从磁盘取，磁盘没有才发起网络请求。理解缓存原理，才能精准控制图片的加载和更新。

缓存层级：内存缓存 + 磁盘缓存

内存缓存：优先快速获取

内存缓存的核心目标是 “快速读取”，避免频繁从磁盘 / 网络加载，减少 IO 耗时。

内存缓存可细分为活跃缓存和 LRU 内存缓存

活跃缓存

活跃缓存是 Glide 最顶层的缓存，属于逻辑缓存（无独立物理存储，仅通过引用管理资源状态），目的是 “防止当前界面显示的图片被内存缓存淘汰”。

实现方式：由ActiveResources类管理，底层是Map<Key, WeakReference<EngineResource<?>>>集合：

• Key：图片的唯一缓存标识；
• Value：图片资源（EngineResource）的弱引用，避免内存泄漏。同时通过EngineResource中的acquired（引用计数）变量跟踪资源使用状态。

作用：缓存当前正在界面上显示 / 使用的图片（比如 ListView 可见项、首页 Banner 的 ImageView 持有的 Bitmap），避免这些图片被 LRU 内存缓存的 “最近最少使用” 规则淘汰，导致界面 “闪图”。

关键特点：① 无容量限制：只要图片还在被使用（acquired > 0），就会留在活动资源中；② 引用计数管理：

• 当 ImageView 绑定图片时，acquired++，资源加入活动资源；
• 当 ImageView 销毁 / 图片被替换时，acquired--；若acquired == 0（资源不再使用），则将资源从活动资源移出，移入 LRU 内存缓存；③ 线程安全：通过锁机制保证多线程下资源状态的一致性，避免并发修改问题。

LRU 内存缓存

LRU 内存缓存是 Glide 内存缓存的第二层（活跃缓存之下、磁盘缓存之上），属于物理缓存（有独立的内存存储区域），目的是 “缓存闲置未使用的图片资源，复用资源以减少重复解码 / 加载，同时通过容量限制防止内存溢出”。

实现方式：由 LruResourceCache 类管理，底层是LinkedHashMap<Key, EngineResource<?>>集合（核心是 LinkedHashMap 的accessOrder=true特性实现 LRU 逻辑）：

• Key：与活跃缓存共用一套图片唯一缓存标识（由图片 URL、尺寸、缩放模式、转码规则等参数生成，保证同一张图片不同处理规则对应不同 Key）；
• Value：图片资源（EngineResource）的强引用（区别于活跃缓存的弱引用），通过强引用稳定存储闲置资源，同时复用 EngineResource 中的 acquired（引用计数）变量衔接活跃缓存的状态流转。

作用：缓存当前界面已不再显示 / 使用的图片资源（比如 ListView 滑出屏幕的 Item 图片、被替换的 Banner 图片），这些资源仍有复用价值（比如 ListView 滑回可见区域、再次加载同规格图片），通过内存缓存直接复用可避免重新从磁盘读取和解码，大幅提升二次加载速度；同时通过 LRU 规则限制总容量，防止无节制占用内存导致 OOM。

磁盘缓存：持久化存储

磁盘缓存的核心目标是 “持久化”，避免重复发起网络请求，节省流量和时间。

磁盘缓存有两种缓存内存：

资源缓存 (Resource Cache)：

• 原理：缓存解码并处理后（如改变尺寸、裁剪、应用滤镜后）的图片。

• 优点：再次加载时无需重新进行图像处理，加载速度最快。

数据缓存 (Data Cache)：

• 原理：缓存从网络拉取的原始图片数据（Source Data）。

• 优点：即便以后需要不同尺寸的同张图，也可以直接从磁盘获取原始文件进行解码。

Glide 的磁盘缓存策略（可通过diskCacheStrategy配置）：

• 核心类：DiskLruCache（同样基于 LRU 算法，默认缓存大小 250MB）；
• 存储路径：默认在/sdcard/Android/data/包名/cache/image_manager_disk_cache/，可自定义；
• 生命周期：磁盘缓存是持久化的，除非手动清理或达到缓存上限被 LRU 清理。

缓存 Key：Glide 如何识别 “同一张图”？

Glide 的缓存核心是 “缓存 Key 的生成”—— 只有 Key 相同，才会命中缓存。默认情况下，Glide 的缓存 Key 由以下因素决定：

1. 图片的原始 URL / 本地路径 / 资源 ID（核心标识）；
2. 图片的请求参数（如缩放尺寸、裁剪方式、转码格式等）；
3. 签名（Signature，可选，用于主动更新缓存）。

举个例子：同样的 URL，若一次请求centerCrop(100,100)，一次请求fitCenter(200,200)，Glide 会生成两个不同的 Key，对应两份磁盘缓存（缩放后的不同尺寸图片）。

缓存加载流程

四、Glide生命周期

Glide 区别于其他图片加载框架的核心特性之一，是与 Android 组件生命周期深度绑定。

原理：Glide 不直接监听 Activity/Fragment 的生命周期，而是采用 “无 UI 隐藏 Fragment” 的经典技巧实现间接感知，核心流程极简：

1. 调用Glide.with(context)时，Glide 会创建RequestManager（请求管理器）；
2. 若 context 是 Activity/Fragment，Glide 会向其内部添加一个无布局、无 UI 的SupportRequestManagerFragment；
3. 该 Fragment 的生命周期与宿主完全同步，会将onStart/onStop/onDestroy等事件传递给RequestManager；
4. RequestManager根据事件管控当前组件下的所有图片请求（暂停 / 恢复 / 取消）。

with 方法支持多种 Context 参数，直接决定请求的生命周期边界，是开发中需重点关注的点：

五、实际场景中的Glide

场景 1：判断是否需要更新缓存

Glide 是否使用缓存，本质是 “新请求的 Key 是否与缓存 Key 一致”。触发更新的核心是 “改变缓存 Key”，常见判断逻辑：

• 无需更新：图片 URL / 参数未变 → Key 一致 → 命中缓存；
• 需要更新：图片内容更新（但 URL 不变）→ 需修改 Key → 重新请求。

场景二：主动更新缓存

Signature 是 Glide 提供的 “缓存更新标识”—— 当 Signature 改变时，Glide 会认为是新请求，重新下载图片并更新缓存。

// 示例：用图片的最后修改时间作为Signature String imageUrl = "https://example.com/avatar.jpg"; // 从服务端获取图片的最后修改时间（如1690000000000） long lastModified = getImageLastModified(imageUrl); // 构建Signature（用StringSignature，也可自定义） Signature signature = new StringSignature(String.valueOf(lastModified)); Glide.with(context) .load(imageUrl) .signature(signature) // 添加签名 .diskCacheStrategy(DiskCacheStrategy.ALL) .into(imageView);

六、Glide 的优缺点分析（客观评价）

优点（为什么成为主流）

1. 生命周期绑定：自动跟随 Activity/Fragment 的生命周期，暂停 / 恢复加载，避免内存泄漏；
2. 缓存策略灵活：双层缓存 + 多维度缓存策略，兼顾速度和流量；
3. 格式支持全面：原生支持 JPG/PNG/Gif/WebP/ 视频帧，无需额外插件；
4. API 简洁易用：流式 API 设计，一行代码搞定基础加载，配置项丰富但不繁琐；
5. 性能优化到位：自动处理图片解码、内存复用（BitmapPool）、线程调度，减少 OOM；
6. 扩展性强：支持自定义网络引擎（OkHttp/Volley）、自定义缓存路径、自定义解码器。

缺点（需要注意的坑）

1. 默认缓存策略可能导致冗余：默认缓存 “原始图片 + 缩放图片”，若同一张图有多个尺寸，会占用更多磁盘空间；
2. Gif 加载性能一般：高帧率 Gif 加载可能出现卡顿，需结合GifDrawable优化；
3. 缓存 Key 生成复杂：默认 Key 包含多个参数，手动控制缓存时需注意参数一致性；
4. 升级成本：Glide 3.x 到 4.x 的 API 变动较大，老项目升级需修改大量代码；
5. 内存占用略高：对比 Fresco 的 “堆外内存”，Glide 的内存占用稍高（但可通过配置优化）。