Консенсус по ленивой загрузке битмапов в адаптере (выделение на Bitmap.recycle ())

Я вижу массу предложений для этого, но ни один (который я нашел) не учитывает все факторы, а факторы:

  1. Асинхронная загрузка без дублирования (загрузчиков и растровых изображений) с отменой загрузки / назначения изображений, которые больше не нужны в любом случае
  2. Адаптер может иметь несколько просмотров для одного и того же ID (вызовы getView (0) очень часты)
  3. Нет гарантии, что представление не будет потеряно вместо повторного использования (рассмотрите изменение / фильтрацию списка / GridView по тексту)
  4. Разделение представлений и данных / логики (насколько это возможно)
  5. НЕ запускать отдельный поток для каждой загрузки (видимое замедление UI). Использовать очередь / стек (LinkedBlockingQueue?) И пул потоков или что-то … но нужно прекратить это, если действие уничтожено.
  6. Очистка растровых изображений, достаточно удаленных от текущей позиции в списке / сетке, желательно только тогда, когда требуется память
  7. Вызов recycle () для каждого Bitmap, который должен быть отброшен.
  8. Внешняя память может быть недоступна (вообще или все время) и, если она используется, должна быть очищена (ТОЛЬКО изображения, загруженные здесь) как можно скорее. Также рассмотрите деятельность по уничтожению / восстановлению активности Android.
  9. Измененные данные: удаленные записи (выберите в списке, кнопку для удаления, немедленное обновление) и добавлены в фоновый поток (список обновляется по требованию). Уже загруженные растровые изображения должны храниться до тех пор, пока записи, к которым они привязаны, все еще существуют.
  10. (Необязательно) не полагаются на notifyDataSetChanged (который, afaik, обновляет все видимые, потенциально очень сложные элементы списка) для обновления одного ImageView
  11. SetTextFilterEnabled (true) (как в ArrayAdapter. Его реализация Filterable заменяет массив данных видимым для других методов Adapter, поэтому меняет индексы представлений, поэтому они не могут использоваться в качестве идентификаторов для ссылки на Bitmaps).
  12. Используется в ExpandableList (влияет на порядок отображения эскизов)

Пожалуйста, простите меня, если на это был дан ответ. Я искал месяцы и не нашел решения.

Требования кажутся мне разумными, но каждый из них добавляет измерение сложности, особенно Bitmap.recycle, которое нужно вызывать во время работы и уничтожения активности (обратите внимание, что onDestroy, даже onStop, не может быть вызван).
Это также мешает полагаться на SoftReferences, которые могли бы позаботиться о некоторых других моментах.
Да, это необходимо, или я получаю OutOfMemoryError даже после любого количества gc, sleep (20s, even), yield и огромных распределений массивов в try-catch (чтобы заставить контролируемую ситуацию с низкой памятью).
Найдите «OutOfMemoryError: размер растрового изображения превышает бюджет VM» или «андроидальный битмап».
Да, я передискретирую битмапы.

Solutions Collecting From Web of "Консенсус по ленивой загрузке битмапов в адаптере (выделение на Bitmap.recycle ())"