29、图片加载之Coil：Kotlin协程图片库、轻量级、内存优化、与Compose结合

图片加载，几乎是每个App都绕不开的坎儿。

我早年做项目时，用的还是老牌的图片加载库。功能确实强大，但总觉得有点「重」。尤其是切换到Kotlin协程和Jetpack Compose之后，那种「为了一个图片加载，引入一堆依赖」的感觉越来越强烈。

直到我遇到了Coil。

说白了，Coil就是为Kotlin和协程而生的。它轻量、高效，而且跟Compose的配合堪称天衣无缝。今天我们就来聊聊它。

Coil是什么？为什么选它？

Coil的全称是Coroutine Image Loader。你看名字就知道，它从骨子里就是为协程设计的。

我个人的习惯是，选库先看包体积。Coil的APK增量只有大概150KB，而其他主流库动辄500KB往上。对于追求包体积的团队来说，这优势很明显。

另外，Coil在内存优化上做了不少文章。它默认使用更高效的解码方式，支持更精细的缓存策略。你想想看，一个图片库如果内存吃太多，那用户体验肯定好不了。

快速上手：在项目中集成Coil

集成Coil非常简单。你只需要在build.gradle里加一行依赖：

// 基础库
implementation("io.coil-kt:coil:2.6.0")

// 如果你用Compose，再加这个
implementation("io.coil-kt:coil-compose:2.6.0")

嗯，就这两行。没有复杂的配置，没有额外的初始化代码。

我记得第一次用的时候，还特意去翻文档找初始化入口。结果发现Coil是懒加载的，第一次加载图片时会自动创建ImageLoader实例。当然，你也可以手动配置全局的ImageLoader：

// 在Application中配置
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        // 可选：自定义配置
        ImageLoader.Builder(this)
            .memoryCachePolicy(CachePolicy.ENABLED)
            .diskCachePolicy(CachePolicy.ENABLED)
            .build()
    }
}

在Compose中使用Coil

这才是重头戏。Coil在Compose中的API设计得非常优雅，就是一个AsyncImage组件：

@Composable
fun CoilExample() {
    AsyncImage(
        model = "https://example.com/image.jpg",
        contentDescription = "示例图片",
        modifier = Modifier
            .fillMaxWidth()
            .height(200.dp),
        placeholder = painterResource(R.drawable.placeholder),
        error = painterResource(R.drawable.error)
    )
}

你看，就这么简单。一个AsyncImage搞定所有。它内部自动处理了协程的启动、取消、生命周期绑定。

我曾经在项目中遇到过一个坑：列表快速滑动时，图片加载请求会堆积。Coil怎么解决的？它利用协程的取消机制，当item滑出屏幕时，自动取消对应的加载请求。这比手动管理生命周期省心太多了。

内存优化：Coil是怎么做的？

内存优化是Coil的强项。我总结了几点关键设计：

优化点	说明
Bitmap复用	Coil使用BitmapPool来复用已回收的Bitmap，减少GC压力
内存缓存	基于LRU算法，默认大小为可用内存的25%
图片解码	默认使用RGB_565（而非ARGB_8888），内存占用减半
协程取消	请求取消时立即释放相关资源

这里有个细节值得注意。Coil默认使用RGB_565格式，这在大多数场景下肉眼几乎看不出区别，但内存占用直接砍半。如果你的图片对色彩精度要求极高，也可以手动改为ARGB_8888：

AsyncImage(
    model = imageUrl,
    contentDescription = null,
    imageLoader = ImageLoader.Builder(context)
        .bitmapConfig(Bitmap.Config.ARGB_8888)
        .build()
)

避坑指南：我曾经踩过的坑

用Coil这么久，也遇到过几个让人头疼的问题。分享出来，希望大家别走弯路。

坑一：图片变形

我曾经在项目中直接用了AsyncImage，没设置裁剪方式。结果图片被拉伸得不成样子。解决方案很简单，加上ContentScale：

AsyncImage(
    model = imageUrl,
    contentDescription = null,
    contentScale = ContentScale.Crop  // 裁剪居中
)

坑二：大图OOM

虽然Coil做了内存优化，但遇到超大图（比如4000x3000像素）还是可能出问题。我建议加上尺寸限制：

AsyncImage(
    model = ImageRequest.Builder(context)
        .data(imageUrl)
        .size(1024, 1024)  // 限制解码尺寸
        .build(),
    contentDescription = null
)

坑三：GIF加载卡顿

Coil支持GIF，但默认实现可能有点卡。如果你需要流畅播放GIF，建议加上coil-gif扩展库：

implementation("io.coil-kt:coil-gif:2.6.0")

知识体系：一张图看懂Coil

下面这张图，是我梳理的Coil核心知识体系。你可以把它当作一个快速索引：

进阶用法：自定义ImageLoader

如果你需要更精细的控制，可以创建自定义的ImageLoader。比如，我想给所有图片加上一个淡入动画：

val customImageLoader = ImageLoader.Builder(context)
    .crossfade(true)  // 启用淡入效果
    .crossfade(500)   // 淡入时长500ms
    .memoryCachePolicy(CachePolicy.ENABLED)
    .diskCache {
        diskCacheBuilder()
            .directory(cacheDir.resolve("image_cache"))
            .maxSizeBytes(50 * 1024 * 1024)  // 50MB磁盘缓存
            .build()
    }
    .build()

// 在Compose中使用
AsyncImage(
    model = imageUrl,
    imageLoader = customImageLoader,
    contentDescription = null
)

这里有个小技巧。磁盘缓存目录最好放在App的私有目录下，避免被用户清理。我见过有人把缓存放在外部存储，结果用户一清理就没了，体验很差。

性能对比：Coil vs 其他库

我简单做个对比，大家心里有个数：

特性	Coil	Glide	Picasso
APK增量	~150KB	~500KB	~120KB
协程支持	原生	需扩展	需扩展
Compose支持	原生	需扩展	需扩展
内存占用	低	中	中
GIF支持	需扩展	原生	不支持

说实话，没有完美的库。Coil在轻量化和Compose集成上优势明显，但GIF支持和生态丰富度上不如Glide。选哪个，看你的项目需求。

写在最后

Coil给我的感觉就是「刚刚好」。它不追求大而全，而是把最核心的事情做到极致。如果你正在用Kotlin + Compose，我强烈建议你试试Coil。它会让你的图片加载代码变得简洁、高效、易维护。

嗯，今天就聊到这里。希望这些经验对你有帮助。

---