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

一、什么是Glide

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

二、Glide基础使用

接入依赖

XML 复制代码

// 核心依赖
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"，最基础的图片加载仅需一行

java 复制代码

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

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

java 复制代码

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 的一大优势是原生支持动图和视频帧加载

java 复制代码

// 加载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配置）：

缓存策略（DiskCacheStrategy）	说明	适用场景
`ALL`	缓存原始图片 + 解码后的缩放图片	频繁加载同一张图且尺寸固定（如列表项）
`NONE`	不缓存任何图片	实时更新的图片（如验证码、实时头像）
`DATA`/`ORIGINAL`	仅缓存原始图片（未解码、未缩放）	同一张图需要不同尺寸展示（如列表 + 详情页）
`RESOURCE`	仅缓存解码后的缩放图片	固定尺寸展示的图片（如首页 Banner）

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

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

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

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

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

缓存加载流程

四、Glide生命周期

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

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

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

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

`with()`参数类型	生命周期范围	核心行为
Activity/Fragment	与组件销毁同步	组件暂停（onStop）→ 请求暂停；组件销毁→ 请求取消
ApplicationContext	与应用进程同步	永不自动暂停 / 取消，仅进程销毁时清理

五、实际场景中的Glide

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

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

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

场景二：主动更新缓存

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

java 复制代码

// 示例：用图片的最后修改时间作为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 的优缺点分析（客观评价）

优点（为什么成为主流）

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

缺点（需要注意的坑）

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