Coil图像加载库中自定义Fetcher的API重复调用问题分析

问题背景

在使用Coil图像加载库(版本2.6.0)开发Android应用时，开发者在RecyclerView中加载图片遇到了一个棘手问题：尽管实现了自定义的ImageIdFetcher并设置了缓存机制，但在快速滚动列表时，系统仍然会频繁调用API获取图片数据，导致性能下降和网络资源浪费。

问题现象

开发者观察到，当快速滚动包含图片列表的RecyclerView时，自定义Fetcher会不断发起网络请求，而不是从缓存中读取已加载过的图片。更具体地说，代码频繁进入了catch块，捕获到的异常是JobCancellationException: DeferredCoroutine was cancelled。

技术分析

自定义Fetcher的工作原理

开发者实现的自定义ImageIdFetcher主要逻辑如下：

1. 首先尝试从磁盘缓存读取图片
2. 如果缓存不存在，则通过网络API获取图片数据
3. 将获取到的Base64编码图片数据解码并写入磁盘缓存
4. 返回图片数据供Coil渲染

问题根源

经过分析，问题主要出在以下几个方面：

1. 异常处理不完善：当前的try-catch块捕获了所有Exception，包括协程的取消异常(JobCancellationException)。当用户快速滚动列表时，Coil会取消未完成的图片加载任务，而当前代码没有正确处理这种取消情况。

2. 缓存机制可能失效：虽然实现了磁盘缓存，但在快速滚动场景下，可能由于任务被取消导致缓存写入不完整，或者缓存键生成方式存在问题。

3. Base64解码开销：每次从API获取数据后都进行Base64解码，这在频繁调用的场景下会带来额外的性能负担。

解决方案

1. 正确处理协程取消

在自定义Fetcher中，应当区分普通异常和协程取消异常。对于取消异常，应该直接重新抛出，而不是当作普通错误处理：

} catch (e: Exception) {
    if (e is CancellationException) throw e  // 专门处理取消异常
    snapshot?.closeQuietly()
    throw e
}

或者更优雅的方式是使用ensureActive()检查协程状态：

} catch (e: Exception) {
    coroutineContext.ensureActive()  // 如果协程已取消会抛出CancellationException
    snapshot?.closeQuietly()
    throw e
}

2. 优化缓存策略

确保磁盘缓存的键生成方式足够唯一且稳定。当前的实现结合了图片ID和尺寸信息，这基本合理，但可以进一步验证：

private val diskCacheKey
    get() = options.diskCacheKey ?: "image_id:${imageId};width:${options.size.width};height:${options.size.height}"

3. 减少不必要的解码操作

考虑将Base64解码后的数据直接缓存，避免每次从缓存读取时都需要解码：

// 写入缓存时直接存储解码后的字节数据
fileSystem.write(editor.data) {
    val imgBytesData = Base64.decode(response, Base64.DEFAULT)
    this.write(imgBytesData)
}

最佳实践建议

1. 合理设置缓存策略：确保磁盘缓存和内存缓存都正确配置并启用。

2. 优化图片加载优先级：对于RecyclerView中的图片，可以设置适当的加载优先级，确保可见项优先加载。

3. 考虑使用占位图：在图片加载过程中显示占位图，提升用户体验。

4. 监控和日志：添加适当的日志记录，帮助诊断缓存命中率和API调用情况。

5. 测试验证：在不同网络条件和滚动速度下测试图片加载行为，确保缓存机制在各种场景下都能正常工作。

总结

在Coil中实现自定义Fetcher时，正确处理协程取消异常和优化缓存机制是关键。特别是在RecyclerView这种频繁创建和销毁视图的场景下，需要特别注意资源的管理和任务的取消。通过上述改进措施，可以显著减少不必要的API调用，提升应用性能和用户体验。