做图片加载优化这件事几乎每一个应用都躲不掉。列表滑动卡顿、内存占用飙升、首屏白屏一闪而过排查到最后问题十有八九都出在图片上。Android 生态里Glide 算是我用过最顺手、也踩坑最多的一套图片加载框架。这篇不讲“一行代码加载图片”那种入门示范而是把 Glide 的缓存原理、生命周期绑定、加载策略、常见事故复盘一次说透。尤其是那些在文档里查不到、但线上真的会炸的细节。1. 项目概述与选型思考1.1 图片加载这个老问题到底难在哪先说清楚一个基本认知图片加载不是“把 URL 变成 Bitmap”那么轻松。一张 1080×1920 的图片解码成 ARGB_8888 位图后算下来是 1080×1920×4 字节大约 8MB 内存。要是界面上一屏 20 张缩略图全部按原图解码单屏就要吃掉 160MB。手机内存是有限的进程内存上限就摆在那里何况列表还在不断滑动、反复加载新图。几轮滑动下来GC 频繁触发掉帧、ANR、OOM 接踵而来。而 Glide 解决的不只是“解码快不快”的问题。它做到了三层缓存协作把已经加载过的图片从内存和磁盘里直接拿省掉网络请求和解码开销。它还能感知 Activity 或 Fragment 的生命周期界面销毁时自动取消加载避免无谓的请求和回调泄漏。配合 Bitmap 复用池让内存分配不再是零零散散的小碎块而是在一个可控大小的池子里循环使用。1.2 为什么当初没直接用系统 API系统自带的方法确实能加载图片比如 BitmapFactory 配合各种采样率设置。但真正落地就会发现只靠系统 API 做图片加载你需要自己处理网络请求、缓存、线程调度、生命周期、圆角裁切、GIF 解码、图片变换……每一个都是容易出问题的地方。尤其缓存策略做浅了命中率低做深了代码量爆炸。选 Glide 的原因很直接它把复杂策略以简洁 API 呈现同时没有把实现细节堵死。你可以通过 RequestOptions 控制几乎每一次加载的尺寸和策略也可以通过定制 AppGlideModule 在全局层面统一管控缓存目录、内存池大小、日志级别。这种“好上手、难场景也能兜住”的平衡才是它一直能留在项目里的理由。拿它和别的方案对比Picasso 轻量但缓存和变换能力弱Fresco 能力强但侵入性高需要替换整个 ImageViewCoil 是 Kotlin 协程时代的轻量选择但生态深度和 Glide 多年积累的坑位文档还是有差距。2. 缓存体系与生命周期原理2.1 三级缓存的工作链路Glide 的缓存分发机制可以类比成一个厨房正在用来炒菜的菜放在案板上冰箱里放着最近备好的菜菜市场则是需要出门才能买到的资源。Glide 里对应的是 ActiveResources、LruCache、DiskLruCache 三层。ActiveResources当前正在显示、被视图引用的图片。这层用的是弱引用保证加载中的图片不会被重复解码。LruCache内存缓存保存最近被回收的图片有大小上限按 LRU 策略淘汰。DiskLruCache磁盘缓存图片解码前先查磁盘缓存命中就直接读文件不重新走网络。加载请求发起后Glide 先去 ActiveResources 查有没有正在使用的同一张图有就直接复用没有再查 LruCache命中就把图片移回 ActiveResources内存没命中才去磁盘找磁盘命中就解码并回填内存缓存磁盘也找不到才真正发网络请求并把结果持久化到磁盘。2.2 内存缓存与 Bitmap 复用LruCache 存的不是 Bitmap 本身而是 Resource 对象。这么做的好处是Glide 可以在 Bitmap 被移出缓存后把它的内存放进 BitmapPool而不是立刻还给系统。新图片解码时优先从 BitmapPool 里拿一块尺寸、格式匹配的空白 Bitmap 复用把申请新内存的次数降到最低。这一步对减少 GC 压力尤其明显列表滑动时如果每次都要 new 一块几 MB 的大内存系统不得不频繁触发垃圾回收滑动的每一帧都可能卡一下。实际开发中我把内存缓存看成“最近访问的图片集合”。页面来回切换、列表反复上下滑命中内存缓存可以减少一次磁盘 IO。磁盘 IO 虽然比网络快但和内存相比仍然是几十倍的差距。性能优化往往是层层递进的每少一层耗时用户体验就能往上提一截。2.3 磁盘缓存策略Glide 的磁盘缓存默认策略是 AUTOMATIC它会在原始图和转换后的图之间做权衡。很多图可能只需要按某种尺寸显示缓存解码后的结果更省空间但如果同一个 URL 还会被其他地方以不同尺寸使用保留原始图反而更划算。AUTOMATIC 采用“一种方案能用就够”的思路要么存原始数据要么存转换结果避免同一张图在磁盘上存多份。手动控制时DiskCacheStrategy.DATA 只缓存原始网络数据适合同一个 URL 需要多种尺寸的场景DiskCacheStrategy.RESOURCE 只缓存解码后的资源适合固定尺寸列表DiskCacheStrategy.ALL 两个都缓存但磁盘占用会翻倍需要评估磁盘冗余度。有一点必须记住磁盘缓存的 key 不单单由 URL 决定还包含图片的宽高、变换信息。同一张图用了圆角变换之后缓存 key 就变了不算命中原来的缓存。3. 图片加载优化的关键操作3.1 尺寸裁剪先把大图挡在解码之前我见过太多项目直接 Glide.with(this).load(url).into(imageView)图能出来但内存也爆得悄无声息。列表里一个缩略图要显示的物理尺寸可能就 100×100直接把 1080×1920 的原始图完整解码每一张都白占了几 MB。解决办法是显式传入显示尺寸。Glide.with(this) .load(imageUrl) .override(300, 300) .centerCrop() .into(imageView)override 的作用是把要请求的图片宽高锁在指定范围Glide 解码时按这个目标尺寸做采样内存占用会从 8MB 降到 300×300×4也就是约 360KB。配合 centerCrop 截取居中区域视觉上仍然完整内部却省了一大截。还有一种情况是图片是纯色背景或展示大图详情页用 fitCenter 让图片保持完整比例缩放会更合适。有时不确定控件的最终尺寸可以用图片加载完再回调真实尺寸的方式但更好的做法是尽量用固定比例的布局约束。比如瀑布流里图片高度按宽度比例换算可以在 item 绑定前就直接算好 override。这个操作虽然不起眼却是列表流畅度的第一道防线。3.2 占位图、错误图与淡入动画占位图绝对不是随便放一张“稍后加载”的占位资源那么简单。加载速度快时占位图一闪而过加载慢时占位图成了用户的第一印象太大太复杂的资源本身就会拖低首屏。我建议占位图用轻量、纯色或简单描边的矢量资源避免网络图还没到先因为占位图解码占用内存。Glide.with(this) .load(url) .placeholder(R.drawable.placeholder) .error(R.drawable.error) .fallback(R.drawable.fallback) .transition(DrawableTransitionOptions.withCrossFade()) .into(imageView)placeholder 是加载前的占位error 是加载失败后的错误图fallback 是针对 URL 为空的场景。三种状态分开设置能避免把空数据和加载失败混在一起。transition 的淡入动画可以让图片出现时不那么生硬但也不要过度使用。列表快速滑动时如果每张图都做淡入视觉上反而会觉得闪。适合的做法是只有从磁盘或网络加载出来的图才带淡入缓存命中时不带过渡。3.3 缩略图与预加载网络环境差或者图片比较大的时候直接等高清图出来需要用户盯着空白很久。Glide 的 thumbnail 可以先用一个小比例版本占位再慢慢换上清晰图。Glide.with(this) .load(url) .thumbnail(0.1f) .into(imageView)thumbnail(0.1f) 的意思是先加载原图 10% 分辨率的一张图相当于一个快速预览。这个比例不是越高越好太高的话预览图和原图加载时间差不多失去意义。我一般选 0.1 到 0.2 之间。如果业务场景里明确知道有一张更小的缩略图地址也可以直接传入另一个 URL 作为 thumbnail。预加载则是“提前把可能要用的图加载进缓存”的套路。ViewPager 做图片浏览时除了当前页前一张和后一张都是高概率被查看的可以在 onCreate 阶段调 preload。Glide.with(this) .load(imageUrl) .override(1080, 1920) .preload()preload 不会把图显示到任何 ImageView它只负责把资源放进缓存。用户真正滑动过去时图片直接从内存或磁盘命中滑动体验接近本地相册。3.4 图片变换与自定义处理圆角、圆形头像、高斯模糊是高频需求。Glide 4 内置了 CircleCrop圆角可以直接通过 RequestOptions 的 transform 配置一般不再需要自己写转换器。Glide.with(this) .load(url) .circleCrop() .into(imageView)自定义变换就要小心了。BitmapTransformation 需要实现 transform 方法和 updateDiskCacheKey。updateDiskCacheKey 影响的是磁盘缓存 key如果不重写或每次返回同一个固定值Glide 会把不同用户自定义的变换结果混用于同一个缓存造成图片显示错乱的诡异现象。我自己写模糊变换时最初就漏了 updateDiskCacheKey结果 A 用户看到 B 用户的头像缩略图排查了很久才发现是缓存 key 的问题。class BlurTransformation( private val radius: Int ) : BitmapTransformation() { override fun transform( pool: BitmapPool, toTransform: Bitmap, outWidth: Int, outHeight: Int ): Bitmap { // 对 toTransform 做高斯模糊处理并返回 } override fun updateDiskCacheKey(messageDigest: MessageDigest) { messageDigest.update(blur_$radius.toByteArray(Charsets.UTF_8)) } }自定义变换还有一个隐藏点变换操作在后台线程执行但耗时的模糊算法如果写得不好会拖慢整个图片加载管线。模糊半径、缩放倍数都要控制别为了一个背景模糊把列表卡成幻灯片。4. 高级配置与性能调优4.1 全局配置定制 GlideModule每个项目对图片缓存的需求都不一样我不想在一百个调用点一个个传参数而是通过 AppGlideModule 全局统一配置。GlideModule class MyAppGlideModule : AppGlideModule() { override fun applyOptions(context: Context, builder: GlideBuilder) { val memoryCacheSize 20 * 1024 * 1024L // 20MB builder.setMemoryCache(LruResourceCache(memoryCacheSize)) builder.setBitmapPool(LruBitmapPool(memoryCacheSize)) val diskCacheDir File(context.cacheDir, image_cache) builder.setDiskCache { DiskLruCacheFactory(diskCacheDir, 100 * 1024 * 1024L) // 100MB } } }内存缓存和 BitmapPool 共用一份内存预算比较稳妥两者加起来别超过进程可用内存的太多了比例。磁盘缓存我习惯单独建目录不要和普通缓存文件混在一起方便问题诊断时直接看目录大小。需要注意如果加入了 GlideModule 但没有对应的 kapt 或 ksp 注解处理器配置生成的 GlideApp 类不会出现。这是新手最容易卡住的地方配完注解处理器再同步GlideApp.with() 才能正常调用。4.2 生命周期管理别让加载请求失控Glide.with() 的参数直接决定了加载请求的“存活时间”。传入 Activity那么在 Activity onStop 时会自动暂停未完成的请求onDestroy 时自动清掉和释放资源。传入 ApplicationContext则请求不绑定界面只要 App 进程还活着请求就会一路执行到底。首页首屏有几张图即使在 Activity 已经销毁的情况下也希望它们能够继续加载完并进入缓存这种场景才有必要用 ApplicationContext。其余绝大多数场景都应该传入 Activity 或 Fragment。否则容易出现一种线上事故页面销毁后回调还拿着已经销毁的 View 引用导致内存泄漏。Glide 内部有 RequestManager 生命周期管理其实就是替我们做了这些脏活。4.3 列表场景的细节优化列表里最容易翻车的几个点我在真实项目里都撞过。第一RecyclerView 的 Item 布局里不要有多余的嵌套图片容器每一层布局都会增加测量和绘制成本。第二ViewHolder 绑定图片时如果 item 里有多张图优先复用已有的加载请求类型避免每次 bind 都创建新的复杂 RequestOptions。第三列表快速滑动时可以考虑禁用图片加载等滑动停止再去填充图片。Glide 的 pauseAllRequests 可以做到这一点。override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { when (newState) { RecyclerView.SCROLL_STATE_IDLE - { Glide.with(recyclerView).resumeRequests() // 同时可以预加载下一页的关键图 } else - { Glide.with(recyclerView).pauseAllRequests() } } }这个功能还有一个附带好处减少图片加载线程的争抢滑动更顺。但要控制好恢复时机否则快速滑动后停下来大量图片同时开始加载出现一瞬间的闪烁需要配合占位图兜住体验。5. 常见问题与排查技巧5.1 图片不显示或错图图片完全不显示先排查网络层。Android 的 INTERNET 权限没配或者 URL 在测试环境是 HTTPS 但证书不通过图片都会静默失败并回调错误图。用 diskCacheStrategy 校验缓存时也要注意如果线上 URL 没变、图片却被后端替换了Glide 的磁盘缓存会让旧图片一直显示。解决方案是引入签名机制。Glide.with(this) .load(url) .signature(ObjectKey(20240501_v2)) .into(imageView)版本号变了缓存 key 就变了自然会去拉新图。后台更新图片时把版本号拼在 URL 里或者由业务下发 version 字段比强制清缓存更优雅。5.2 缓存不生效或磁盘占用过大缓存不生效优先看 key。比如同一个 URL回调时手动改了 Bitmap 并重新 set 进 ImageView并没有让 Glide 知道内容变化。只要不用 transform 或 signature缓存命运在第一次请求时就决定了。磁盘占用过大则要检查是不是所有图片都用了 DiskCacheStrategy.ALL。大量不同尺寸的列表图都缓存两份磁盘瞬间就能爆掉几百 MB。更隐蔽的问题是内存缓存命中率低。如果你在列表里用可变尺寸的控件但没有显式 overrideGlide 每次读到的控件宽高可能不固定生成的缓存 key 也不稳定等于缓存反复失效内存缓存形同虚设。统一把列表图的显示尺寸固定下来这一条就能换来肉眼可见的流畅度提升。5.3 OOM 依旧出现的排查方向已经用了 Glide还是 OOM多数问题出在大图解码和多图并发。Glide 默认不会把所有大图一次性解码成高分辨率位图但如果你在大图详情页直接加载一张超高分辨率的长图比如超过屏幕数倍的超长截图还是要主动做 downsampling。Glide.with(this) .load(longImageUrl) .override(1200, 20000) .into(imageView)按屏幕尺寸做上限约束把分辨率限定在合理范围内。同时不要在页面里一次性预加载几十张原图预加载的目标尺寸也要限制。另一个方向是检查是否有多个 Glide 实例混用配置比如误写了多个 GlideModule可能导致缓存池互相覆盖内存配置失效。5.4 GIF、模糊与特殊格式的细节GIF 是吃内存大户Glide 默认会把它当成动画播放。如果列表里只是需要展示一张动态图封面用 asBitmap 强制转成静态帧能省大量内存。反过来如果确实要播放 GIF要留意单帧尺寸不要过大多帧动画叠加的内存用量是图片总数乘以每帧占用。模糊背景这类效果经常有一个误区把原图整个模糊内存白耗。先缩小再模糊效果几乎一致内存却差了一个数量级。可以在自定义变换里先采样缩小到目标尺寸的十分之一再做模糊操作视觉上并无差别性能却能翻很多倍。Glide.with(this) .load(url) .transform(BlurTransformation(radius 15)) .override(200, 200) .into(backgroundView)blur 操作配合 override把整个模糊区域的尺寸控制在小范围再通过 ImageView 的 scaleType 放大铺满这是大多数模糊背景的推荐姿势。6. 实操总结与习惯建议我在多个项目里折腾一圈下来最深的感受是图片优化不是一个静态的配置而是一整套动态取舍。按不同场景决定加载尺寸列表图强制 override详情图按屏宽约束最大尺寸预加载只预热高概率展示的图全局缓存大小按业务图量估算而不是照抄模板。调试阶段我习惯打开 Glide 的日志开关看每次加载是命中内存、磁盘还是走了网络。这能非常直观地验证缓存策略是否生效。日志里如果发现同一张图反复走网络说明缓存 key 不稳定优先检查尺寸和变换。给还在优化列表流畅度的同学一个建议先不要急着追各种高级特性和第三方库把加载尺寸和生命周期这两个基础问题管好列表卡顿和内存问题大概率已经解决掉一大半。剩下那些细枝末节的调优才轮到缓存策略和自定义变换。图片加载优化是一场持续排查没有一劳永逸但每一步做扎实了用户是明显能感受到的。