关于在适配器中延迟加载位图的共识（重点是 Bitmap.recycle()）

Question

我看到了大量的建议，但没有一个（我发现）考虑到所有因素，这些因素是：

1. 异步下载，无重复（下载器和位图），并取消下载/分配不会发生的图像 无论如何不再需要
   
2. 一个适配器可以拥有同一个 ID 的多个视图（对 getView(0) 的调用非常频繁）
   
3. 无法保证视图不会丢失而不是回收（考虑 List/GridView 调整大小或按文本过滤）
   
4. 视图和数据/逻辑的分离（尽可能）
   
5. 不为每次下载启动单独的线程（UI 明显变慢）。使用队列/堆栈（LinkedBlockingQueue？）和线程池，或者 诸如此类......但如果活动被破坏则需要结束。
   
6. 清除距离列表/网格中当前位置足够远的位图，最好仅在需要内存时
   
7. 对每个要丢弃的位图调用 recycle()。
   
8. 外部存储器可能不可用（始终或始终），如果使用，应尽快清除（仅清除此处下载的图像）。 还要考虑 Android 的 Activity 销毁/重新创建。
   
9. 数据被更改：条目已删除（在列表中选择、删除按钮、立即刷新）并添加到后台线程（列表 按需刷新）。应保留已下载的位图，如 只要它们链接的条目仍然存在。
   
10. （可选）不依赖于notifyDataSetChanged（据我所知，它会刷新所有可见的、可能非常复杂的列表项） 更新单个 ImageView
    
11. setTextFilterEnabled(true)（如 ArrayAdapter 中所示。其 Filterable 的实现替换了其他 Adapter 可见的数据数组 方法，因此更改视图的索引，因此它们不能 用作链接到位图的 ID）。
    
12. 可在 ExpandableList 中使用（影响缩略图的显示顺序）

如果已回答此问题，请原谅我。我已经搜索了几个月，但没有找到解决方案。

这些要求对我来说似乎很合理，但每一个都增加了一个维度的难度，尤其是 Bitmap.recycle，它需要在运行期间和 Activity 销毁时调用（注意 onDestroy，甚至 onStop 可能不会被调用）。
这也排除了对软引用的依赖，软引用本来可以解决其他一些问题。
是的，这是必要的，否则即使在尝试捕获中进行任意数量的 gc、睡眠（20 秒，甚至）、yield 和巨大的数组分配（以强制控制低内存情况）后，我也会遇到 OutOfMemoryError。
搜索“OutOfMemoryError：位图大小超出 VM 预算”或“android 位图回收”。
是的，我正在对位图进行重新采样。