android 图片加载时可能因内存/磁盘缓存未及时失效，导致新生成的同名缓存文件（如相同路径或 url）仍显示旧图像；需主动清除缓存或绕过缓存机制才能确保视图展示最新 bitmap。
android 图片加载时可能因内存/磁盘缓存未及时失效，导致新生成的同名缓存文件（如相同路径或 url）仍显示旧图像；需主动清除缓存或绕过缓存机制才能确保视图展示最新 bitmap。
在 Android 开发中，当通过 Bitmap 动态生成图片并保存到应用缓存目录（如 context.getCacheDir()）后，再使用 ImageView 加载该图片时，常遇到“图片内容已更新但界面上仍显示旧图”的问题。这并非 Android “保存了图像到内存”那么简单，而是由多级缓存协同作用导致的典型现象：
- 内存缓存（LruCache）：主流图片库（Glide、Picasso、Coil）默认启用，按 key（如文件路径或 URL）索引 Bitmap；
- 磁盘缓存（DiskCache）：将解码后的 Bitmap 或原始文件缓存在 getCacheDir() 下，复用时跳过解码；
- 系统级资源缓存：BitmapFactory.decodeFile() 在某些场景下也可能被底层复用（尤其当文件路径、尺寸、采样率完全一致时）。
因此，仅删除目标图片文件（如 new File(cacheDir, "img.png").delete()）往往无效——因为内存缓存中仍保留旧 Bitmap 引用，磁盘缓存索引也未清理，甚至图片库可能直接命中缓存而根本不重新读取文件。
✅ 正确做法不是粗暴清空整个缓存目录（虽能临时解决，但影响其他功能），而是精准失效缓存 + 强制重加载：
✅ 推荐解决方案（兼顾健壮性与性能）
1. 使用唯一缓存 Key（推荐）
为每次生成的图片生成带时间戳或哈希值的唯一文件名，从根本上避免缓存冲突：
String uniqueName = "dynamic_" + System.currentTimeMillis() + ".png"; File cacheFile = new File(context.getCacheDir(), uniqueName); // ... 保存 Bitmap 到 cacheFile // 加载时使用此唯一路径，无缓存干扰 imageView.setImageURI(Uri.fromFile(cacheFile));
2. 主动清除图片库缓存（以 Glide 为例）
若必须复用同一路径，加载前通知 Glide 清除对应资源：
// 清除内存 & 磁盘缓存（需在主线程调用）
Glide.get(context).clearMemory(); // 内存缓存（同步）
new Thread(() -> {
Glide.get(context).clearDiskCache(); // 磁盘缓存（需子线程）
}).start();
// 加载前确保缓存已清，再强制跳过缓存
Glide.with(context)
.load(cacheFile)
.skipMemoryCache(true) // 跳过内存缓存
.diskCacheStrategy(DiskCacheStrategy.NONE) // 跳过磁盘缓存
.into(imageView);
3. 手动刷新文件系统（辅助手段）
部分设备对文件替换响应延迟，可触发媒体扫描（适用于外部存储）或调用 MediaStore 更新（内部缓存不适用），但对 getCacheDir() 通常无效，不推荐作为主方案。
⚠️ 注意事项：
- ❌ 避免直接调用 deleteCache(Context) 全局清空缓存——会清除所有组件缓存（如网络请求、数据库临时文件），引发性能抖动与异常；
- ✅ 若必须复用文件路径，请配合 File.setLastModified(System.currentTimeMillis()) 更新时间戳，部分图片库会据此判断新鲜度；
- ? 调试时可用 adb shell ls -l /data/data/
/cache/ 查看缓存文件状态，确认是否真被替换。
总结：图片不更新的本质是缓存一致性问题。最佳实践是 「避免冲突」＞「清除缓存」＞「强制跳过」 ——优先采用唯一文件名设计，辅以图片库的缓存控制 API，既保证显示正确性，又维持应用整体缓存效率。
