Android Coil 3为什么没有沿用Glide那种BitmapPool体系？是偷懒、退化，还是一次正确的架构取舍？

摘要：Coil3放弃Glide式BitmapPool是适应现代Android环境的合理选择。随着Android系统优化（ART改进、硬件Bitmap普及）和设备内存提升，频繁分配Bitmap的性能损耗显著降低，而维护BitmapPool带来的架构复杂性和潜在风险（内存占用、图片错乱）日益凸显。Coil3优先采用不可变图片和硬件加速方案，简化资源管理，在大多数场景下更高效稳定。仅对特定高频软件解码场景（如图库快速滑动），BitmapPool仍可能有局部优势，但此时应优先优化缓存策略而非引入复杂池化机制。这一取舍体现了Coil轻量化、现代化的设计哲学。

对 Coil 3 的定位和现代 Android 环境来说，放弃 Glide 式 BitmapPool 是合理的，而且大多数场景是正确策略。
但对极端高频缩略图解码、老设备、纯软件 Bitmap、大规模图库场景，BitmapPool仍可能有局部收益，只是 Coil 不再把它作为通用内置能力。

1. BitmapPool 最初解决的是什么问题？

BitmapPool的核心目标不是“缓存图片内容”，而是：

复用 Bitmap 背后的像素内存，减少频繁分配和释放大块内存

例如反复解码 400x400 图片：

400 x 400 x 4 bytes ≈ 625 KB

如果列表快速滑动，每秒创建几十张 Bitmap，就会产生大量短生命周期大对象：

分配 Bitmap 显示 回收 再分配 Bitmap 再回收

这会带来：

1. Java / Native heap 压力；

2. GC 频繁；

3. 内存碎片；

4. UI 线程或 RenderThread 间接受影响；

5. 老 Android 设备上更明显卡顿。

Glide 的BitmapPool就是为了解决这个问题：

Bitmap 不马上释放 ↓ 放入池子 ↓ 下次解码时用 inBitmap 复用这块内存

2. Glide 为什么很依赖 BitmapPool？

Glide 的设计历史更早，它要覆盖非常多的 Android 版本和复杂场景：

Android 4.x / 5.x / 6.x 低内存设备 大量 RecyclerView 图片 频繁 transformation 大量软件 Bitmap

Glide 的完整资源管理体系包括：

ActiveResources MemoryCache BitmapPool ArrayPool EngineResource 引用计数 Target 生命周期绑定

它能较安全地判断：

这张 Bitmap 是否还在显示？ 是否还在 MemoryCache？ 是否可以回收到 BitmapPool？

所以 Glide 的 BitmapPool 不是一个简单池子，而是和它整套资源生命周期系统绑定的。

也就是说：

Glide 能做 BitmapPool，是因为它为此付出了很高的架构复杂度。

3. Coil 为什么逐渐放弃这种 BitmapPool？

主要有几个背景变化。

3.1 Android 新版本 Bitmap 分配成本下降

早期 Android 上，大 Bitmap 分配和释放非常容易造成卡顿。

但现代 Android：

ART 更成熟 GC 更优化 Bitmap 内存管理更稳定 设备内存更大 图片解码器更现代

BitmapPool的收益没有早期那么明显。

尤其是从 Android 8.0+ 开始，系统对 Bitmap / native allocation 的管理比早期好很多。

3.2 Hardware Bitmap 普及后，BitmapPool 的价值下降

Coil 默认更倾向于使用现代能力，比如：

Bitmap.Config.HARDWARE

Hardware Bitmap 的特点是：

不可变 immutable 不可被 Canvas 软件绘制修改 不能作为 inBitmap 复用 更适合 GPU 直接显示

但 BitmapPool 依赖的是：

BitmapFactory.Options.inBitmap

而inBitmap要求 Bitmap 通常必须是：

mutable software bitmap

所以两者天然冲突：

Hardware Bitmap 路线：更适合显示，减少 Java heap 压力 BitmapPool 路线：复用 mutable software Bitmap

Coil 的策略更偏向：

优先使用现代系统能力 + immutable image + 简化资源管理

而不是：

大量 mutable Bitmap + 手动池化复用

3.3 ImageDecoder 不适合 Glide 式 BitmapPool

Android P / API 28 引入了ImageDecoder，用于替代传统的BitmapFactory部分能力。

但ImageDecoder没有提供传统意义上好用的inBitmap复用入口。

也就是说，如果 Coil 大量使用现代解码链路：

ImageDecoder AnimatedImageDrawable Hardware Bitmap

那么 Glide 式 BitmapPool 的适用面会越来越窄。

3.4 BitmapPool 很容易引入隐蔽 bug

BitmapPool 最大的问题是：

你必须非常准确地知道一张 Bitmap 什么时候真的“不再被使用”。

如果判断错了，比如：

ImageView 还在显示 Bitmap A ↓ 你把 Bitmap A 放回池子 ↓ 下一张图复用了 Bitmap A 的内存 ↓ ImageView 上的旧图突然变成新图

可能出现：

花屏 闪图 图片错乱 Canvas: trying to use a recycled bitmap 硬件渲染异常 偶发崩溃

这些问题通常很难排查，因为它们和滑动速度、GC 时机、生命周期、缓存命中都有关系。

Coil 更强调简单、稳定、可预测，因此选择不内置这类高复杂度机制。

4. 放弃 BitmapPool 后，Coil 得到了什么收益？

4.1 架构更简单

没有 BitmapPool 后，Coil 的资源链路更简单：

Fetcher ↓ Decoder ↓ Image ↓ MemoryCache ↓ Target

不需要额外维护：

Bitmap 是否可复用 Bitmap 是否仍在显示 Bitmap 是否在内存缓存 Bitmap 是否 mutable Bitmap config 是否匹配 Bitmap 尺寸是否兼容

代码更少，bug 面更小。

4.2 更适合 immutable image

Coil 3 中Image有一个很重要的概念：

image.shareable

静态图片通常可以共享：

shareable = true

GIF / 动图结果通常不能共享：

shareable = false

Coil 通过这个机制避免错误复用有状态资源。

而 BitmapPool 要求大量资源是 mutable 的，这和shareable/ immutable 模型并不完全一致。

4.3 更适合 Hardware Bitmap

Hardware Bitmap 对显示路径友好：

更少 Java heap 占用 更适合 GPU 显示 减少软件像素内存压力

如果强行走 BitmapPool，很多情况下反而要禁用 hardware bitmap：

.allowHardware(false)

这会让图片重新回到软件 Bitmap 路线，未必更快，也未必更省内存。

4.4 避免池子本身占用内存

BitmapPool 不是免费的。

它会保留一批暂时不用的 Bitmap：

这些 Bitmap 没有显示 也没有作为图片内容缓存 只是等待下次复用

所以 BitmapPool 可能降低分配次数，但也可能提高常驻内存。

对图库这种场景，如果还有：

MemoryCache 磁盘缓存 缩略图缓存 RecyclerView 预加载

再加一个 BitmapPool，内存压力可能更高。

5. 放弃 BitmapPool 的代价是什么？

代价也很明确：

某些高频软件解码场景下，可能会增加 Bitmap 分配次数。

比如图库首页：

大量 400x400 缩略图 快速滑动 图片不断进入/离开屏幕 allowHardware(false) 需要 transformation 需要生成软件 Bitmap

这种场景下，如果没有 BitmapPool，可能出现：

Bitmap 分配频繁 Native heap 波动 GC 次数增加 偶发掉帧

所以不是说 BitmapPool 完全没价值，而是：

它不是现代 Android 图片库的通用默认最优解

6. Coil 放弃 BitmapPool 是正确的吗？

要分场景看。

6.1 对大多数 App：是正确的

普通 App 图片加载主要是：

头像 Banner Feed 图片 详情图 少量列表图

这些场景下，最佳策略通常是：

正确 resize 合理 memory cache 使用 hardware bitmap 避免过大原图解码 减少 transformation

而不是引入 BitmapPool。

所以对大多数 App 来说，Coil 放弃 BitmapPool 是正确的。

6.2 对 Coil 的产品定位：是正确的

Coil 的定位是：

轻量 Kotlin-first Coroutine-friendly API 简洁 易集成 现代 Android 优先

如果它也做一套 Glide 级别的 BitmapPool / 引用计数 / 生命周期资源管理，Coil 会越来越像 Glide，复杂度显著上升。

这不符合 Coil 的设计取向。

6.3 对极端场景：不一定绝对最优

这种场景确实更接近 Glide BitmapPool 最初擅长的领域：

大量尺寸接近的 Bitmap 频繁解码 频繁丢弃 重复滑动

这时 BitmapPool 可能有收益。

但仍然不建议优先在 Coil 3 里自己硬塞 BitmapPool。

更优先的顺序应该是：

1. 固定缩略图尺寸解码，比如 400x400 2. 建立稳定 memoryCacheKey 3. 复用 Coil MemoryCache 4. 做 400x400 磁盘缩略图缓存 5. 滑动中暂停重任务 6. 滑动停止后低优先级补图 7. 限制预解码数量和并发 8. 最后才考虑自定义 Decoder + BitmapPool

7. BitmapPool 和 MemoryCache 的区别

这个特别重要。

MemoryCache 缓存的是“图片内容”

key = image_uri_400x400 value = 已经解码好的 Bitmap/Image

命中后不需要重新解码。

收益是：

减少解码次数 减少 IO 减少 CPU 提升二次显示速度

BitmapPool 缓存的是“可复用内存块”

bitmap pixels buffer

它不关心图片内容。

收益是：

减少 Bitmap 内存重新分配 降低 GC/allocator 压力

但还是要重新解码图片。

所以：

MemoryCache 命中收益 > BitmapPool 命中收益

对图库反复滑动来说，优先把 400x400 缩略图放 MemoryCache / 磁盘缓存，通常比 BitmapPool 更直接有效。

8. 对场景的判断

因为 BitmapPool 只能在内存层面的Bitmap减少分配，而不能解决：

原图解码慢 GIF 首帧慢 视频抽帧慢 IO 慢 大图 downsample 慢

而痛点如果是：

缩略图生成和加载链路太重

不是单纯 Bitmap 分配太多。

9. 如果真的要 BitmapPool，什么时候值得做？

只有满足这些条件时才值得认真考虑：

1. 已经确认主要卡顿来自 Bitmap 分配 / GC； 2. 图片尺寸高度统一，比如都是 400x400； 3. 大部分是软件 Bitmap，不是 Hardware Bitmap； 4. 可以控制 Bitmap 生命周期； 5. MemoryCache / 磁盘缩略图缓存已经做好； 6. 仍然存在明显 allocator/GC 抖动； 7. 有能力维护自定义 Decoder。

否则，自定义 BitmapPool 很可能：

收益不明显 复杂度增加 内存占用升高 偶发图片错乱风险变大

10. 一句话总结

Coil 3 放弃 Glide 式 BitmapPool，背景是：

现代 Android 分配成本下降 Hardware Bitmap 普及 ImageDecoder 路线增强 BitmapPool 复杂且容易出错 Coil 追求轻量和稳定

收益是：

架构简单 bug 更少 更适合 immutable / hardware bitmap 避免池子额外占用内存 维护成本低

这个策略对大多数 App 是正确的。

但对极端场景，BitmapPool 仍可能有局部价值；只是更应该优先做：

固定尺寸解码 + 内存缓存 + 磁盘缩略图缓存 + 滑动期间降载

而不是优先在 Coil 3 中重建 Glide 的 BitmapPool。

好好学习，天天向上