看文章 Android图片加载框架最全解析（三），深入探究Glide的缓存机制 的评论区关于 activeResources 有多种版本的讨论和结论, 我回溯了一下历史源码, 看当时为什么要做这样的改动
改动记录
对应的commitID = e743a1f03f24e33270f38de883b508d4312a7f69, message=Cache resources only after no remaining consumers.
改动内容描述
添加 Engine#activeResources 和 resourceReferenceQueue, 以弱引用的方式来保存active资源,
最关键的改变是, Engine#load 从 lruCache.get(key) 改为 lruCache.remove(key), 根据LRU算法, 更改之前的代码淘汰规则是每当从缓存里获取到一个资源, 就把这个资源移动到队列头部, 记为最新访问的, 按照概率来说, 连续对同一资源的访问的情况是很小的, 这样这个资源很难被回收, 直到缓存满, 导致lruCache一直处于高占用内存状态; 更改之后, 每次命中一次缓存, 都会从lruCache中立即移除这个资源缓存, 有效的避免了高内存占用问题, 更严重的情况是, 如果系统内存紧张, 也不能立即把这些永远也不可能第三次访问的资源给销毁来缓解内存问题(代码是2014年, 内存普遍很小).
而在改为 remove(key) 之后, 把这个刚刚remove掉的资源, 重新保存在activeResource中, 如果后续有第三次访问这个资源, 并且这个被弱引用的资源还没有被回收的话, 可以拿出来直接使用了,
结论
觉得 activeResources 只有缓解LRUCache内存压力的目的, 与提高访问效率, 防止内存泄漏没有关系, 也不是为了保护正在使用的图片不被回收, 正在使用的图片, 是被强引用着的, 系统是不会剥夺正在使用的资源.
