SDWebImage 中 Thumbnail 加载与内存缓存的深度解析

背景介绍

SDWebImage 作为 iOS 开发中最常用的图片加载库之一，其高效的缓存机制一直是其核心优势。在 5.15.7 版本中，开发者发现当使用 SDImageCoderDecodeThumbnailPixelSize 设置缩略图尺寸时，内存缓存似乎失效了，这引发了关于 SDWebImage 缓存机制的深入讨论。

问题现象

当开发者通过 SDWebImageContextOption.imageThumbnailPixelSize 设置缩略图尺寸时，后续加载同一 URL 的图片时，缓存类型总是显示为磁盘缓存或没有缓存，而不是预期的内存缓存。这导致在快速刷新界面时，由于需要频繁从磁盘加载图片，出现了明显的界面闪烁问题。

技术原理

SDWebImage 的缓存机制设计如下：

1. 默认加载流程：

   • 首先检查指定尺寸的缩略图是否已缓存
   • 如果没有，则检查完整尺寸的图片
   • 如果完整尺寸存在，则重新解码生成缩略图
   • 下载完整数据
   • 解码得到缩略图（内存中不会保留完整尺寸图片）
   • 缩略图写入内存缓存
   • 完整数据写入磁盘缓存

2. 缩略图处理逻辑： 在 SDImageCache.m 中，当检测到 SDWebImageContextImageThumbnailPixelSize 有值时，会设置 shouldCacheToMomery = NO，这意味着：

   • 不会检索内存缓存
   • 不会将解码后的图片存储到内存缓存

问题根源

经过深入分析，发现问题的根源在于：

1. 缓存写入时机：磁盘缓存写入是异步进行的，当开发者在一个 completionBlock 中立即触发新的图片加载时，磁盘可能尚未完成写入。

2. 内存缓存策略：SDWebImage 默认不会将根据完整尺寸生成的缩略图存储到内存缓存中，这是为了避免潜在的内存浪费。

3. 并发请求处理：当同时发起多个图片请求时，前序请求可能被取消，导致缓存状态不一致。

解决方案

针对这一问题，开发者可以采取以下几种解决方案：

1. 使用 waitStoreCache 选项： 在加载图片时添加 .waitStoreCache 选项，确保磁盘写入完成后再继续后续操作：

   imageView.sd_setImage(with: url, options: [.waitStoreCache], context: thumbnailContext)
   

2. 调整缓存策略： 通过设置 SDWebImageContextOriginalStoreCacheType 来控制原始图片的缓存行为，确保缩略图能够正确缓存。

3. 合理设计加载时机： 避免在 completionBlock 中立即触发新的图片加载，确保缓存已完全建立。

4. 版本升级： 考虑升级到 SDWebImage 5.18.8 或更高版本，其中对缓存行为进行了优化。

最佳实践

基于对 SDWebImage 缓存机制的深入理解，建议开发者在处理缩略图时：

1. 对于需要频繁刷新的界面，优先考虑使用内存缓存
2. 合理设置缩略图尺寸，平衡内存占用和图片质量
3. 在预加载图片时，明确等待缓存完成的时机
4. 对于列表等需要快速滚动的场景，可以适当增加内存缓存大小

总结

SDWebImage 的缓存机制设计精巧，但在特定场景下需要开发者深入理解其工作原理才能充分发挥性能优势。通过合理配置缓存策略和加载选项，可以显著提升图片加载效率，避免界面闪烁等问题。理解这些底层机制有助于开发者在实际项目中做出更合理的技术决策。