第149篇图片加载原理：三级缓存与解码采样

先把结论放在前面：图片加载框架解决的核心问题有三个——把网络/磁盘的阻塞 IO 挪出主线程、把解码后的位图按目标尺寸管理以控制内存、把"哪个请求对应哪个 View"这件事在视图复用场景下管住。三者里，第三条最容易被忽略，也最容易出线上事故。这道题的分水岭从来不在会不会背三级缓存，而在能不能把"从请求发起到图显示出来"的完整链路讲顺。能讲清"为什么一个 View 复用了位置后旧请求不能直接设置结果"，说明真的处理过线上问题。一条请求的完整路径以常见的 Glide/Coil 类架构为例，一次加载的完整链路是：load(url, targetView, size) → 解析/规范化请求（URL、宽高、配置、签名） → 计算 cacheKey（关键：必须含所有影响结果的参数） → 查内存缓存（ActiveResource 活跃引用 → ResourceCache 弱引用 LruCache） 命中 → 立即设置（主线程） → 未命中 → 生成 EngineJob，调度到线程池 → 查内存缓存（二次，可能刚被别处加载完成） → 解码（BitmapFactory 采样 / Drawable 解码 / 视频帧） → 变换（centerCrop、圆角、模糊） → 存内存缓存 + 写磁盘缓存 → 回调主线程 → 设置到 target → 活跃期间进入 ActiveResource，引