Android-Universal-Image-Loader 详解：Android 图片加载库的先驱与退场
在 Glide、Coil、Fresco 一统天下的今天，可能很难想象 2012–2015 年 Android 图片加载的"事实标准"是另一个库——nostra13/Android-Universal-Image-Loader（简称 UIL）。它以 16.8k Star 的体量，定义了一代人对"图片加载 + 内存/磁盘缓存 + 多线程"的全部想象，被作者自嘲为"现代图片加载库的伟大祖先"。但它早在 2015 年底就已停止维护。本文既讲它的设计、配置与用法（供阅读老代码），也讲清它为何退场、现在该用什么。
1、项目概述与历史地位
Android-Universal-Image-Loader（UIL）由 nostra13 开发，是 Android 早期最具影响力的图片加载库。截至快照，仓库有 16.8k Star、6k Fork，采用 Apache 2.0 协议。作者在 README 里自称"The great ancestor of modern image-loading libraries"（现代图片加载库的伟大祖先）。
它的生命周期被标注为"UIL [27.11.2011 - 27.11.2015]"，恰好四年。
历史影响：
- 定义了"图片加载 + 双缓存 + 多线程 + 配置化"的标准范式
- 后续的 Glide、Picasso、Fresco 在不同程度上延续了它的思路
- 至今仍有大量历史项目在使用，是阅读老代码时绕不开的一环
2、已停止维护：重要前提
在进入用法之前，必须先讲清它的状态：UIL 已停止维护。作者在公告里写道"Really have no time for development... so I stop project maintaining since Nov 27"，自 2015 年 11 月 27 日起不再更新，最终版本停留在 1.9.5。
这意味着：
- 不支持新的 Android API、Java 新特性、AndroidX
- 对新机型、新图片格式（如 WebP、动图）支持薄弱
- 无安全更新、无 bug 修复
- 新项目切勿选用，老项目应规划迁移
3、核心特性
放在 2011 年，它的功能相当全面，几乎把"图片加载"能想到的维度都做成了可配置项。
功能列表：
- 多线程加载（异步或同步）
- 高度可配置：线程池、下载器、解码器、内存缓存、磁盘缓存
- 每次加载可单独定制：占位图、缓存开关、解码参数、Bitmap 后处理
- 内存与磁盘双缓存（文件系统或 SD 卡）
- 加载过程监听，含下载进度回调
- 支持 Android 4.1+
4、初始化与配置
使用前需在 Application 中用 ImageLoaderConfiguration 初始化单例，把线程池与缓存策略一次性配好。
// 在 Application 的 onCreate 中初始化
ImageLoaderConfiguration config = new ImageLoaderConfiguration.Builder(this)
.threadPoolSize(3) // 线程池大小
.memoryCacheSize(2 * 1024 * 1024) // 内存缓存约 2MB
.diskCacheSize(50 * 1024 * 1024) // 磁盘缓存约 50MB
.build();
ImageLoader.getInstance().init(config);初始化要点：
1. 在 Application 的 onCreate 里构建 ImageLoaderConfiguration
2. 按需配置线程池大小、内存缓存与磁盘缓存容量及位置
3. 调用 ImageLoader.getInstance().init(config) 完成全局初始化
4. 之后在任意位置用 ImageLoader.getInstance() 取单例使用
5、显示图片、URI 与加载方式
每次显示前可用 DisplayImageOptions 配置占位图、缓存开关与 Bitmap 配置，再交给 ImageLoader 加载。
// 每次显示的选项：占位图、缓存开关、Bitmap 配置
DisplayImageOptions options = new DisplayImageOptions.Builder()
.showImageOnLoading(R.drawable.placeholder) // 加载中占位
.showImageForEmptyUri(R.drawable.empty) // URI 为空占位
.showImageOnFail(R.drawable.error) // 失败占位
.cacheInMemory(true) // 内存缓存
.cacheOnDisk(true) // 磁盘缓存
.bitmapConfig(Bitmap.Config.RGB_565) // 省内存的 Bitmap 配置
.build();
// 异步加载并显示到 ImageView
ImageLoader.getInstance().displayImage(imageUri, imageView, options);
// 同步加载拿 Bitmap（勿在主线程调用）
Bitmap bmp = ImageLoader.getInstance().loadImageSync(imageUri);支持的 URI scheme：
- http:// 网络图、file:/// 本地文件、content:// ContentProvider
- assets:// 资源、drawable:// Drawable（作者提示尽量少用，优先 setImageResource）
三种加载方式：
- displayImage：解码后直接显示到 ImageView，最常用
- loadImage：异步加载，回调里返回 Bitmap
- loadImageSync：同步加载返回 Bitmap，切勿在主线程调用
6、为何被取代：与现代库的差距
UIL 的设计在 2011 年相当先进，但放到今天已明显落后，这也是它被 Glide、Coil 等取代的根本原因。
主要差距：
- 缺少生命周期感知：不像 Glide 自动绑定 Activity / Fragment 生命周期
- API 偏冗长：需手写 Configuration 与 Options，Glide / Coil 一行链式即可
- 默认性能不如 Glide：缺 BitmapPool、按控件尺寸自动缩放较弱
- 动图、WebP 支持薄弱，也无 Kotlin 协程友好封装
- 已停维多年，生态与文档不再更新
7、迁移建议与现状
既然 UIL 已停维，合理的做法是理解它、然后迁移走。常见的替代库如下。
迁移目标：
- Glide：功能全面、生态成熟，最主流的替代选择
- Coil：Kotlin 优先、协程驱动、轻量，新项目首选
- Fresco：Facebook 出品，三级缓存、内存优化强，适合重度图片场景
- Picasso：Square 出品，API 简洁，轻量场景可用
迁移步骤：
1. 盘点项目中 UIL 的调用点（displayImage / loadImage / 全局配置）
2. 选定替代库，多数团队会在 Glide 与 Coil 之间二选一
3. 用统一的图片加载包装层收口，按页面逐步替换
4. 老代码可暂时保留 UIL 以便理解，但不再新增使用
8、总结
Android-Universal-Image-Loader 是 Android 图片加载库的"伟大祖先"，16.8k Star，定义了"加载 + 双缓存 + 多线程 + 配置化"的范式，影响了一代库的设计。但它自 2015 年 11 月 27 日起停止维护，最终版本停留在 1.9.5，在新项目里已无立足之地。理解它的设计与用法，对阅读老代码、把握 Android 图片加载的演进脉络仍有价值。
对于开发者：新项目直接用 Glide 或 Coil；仍在使用 UIL 的老项目，应规划向 Glide / Coil 迁移，并用统一的图片加载包装层收口、逐步替换。把 UIL 当作一份值得理解的历史遗产，而不是未来的技术选型。
