Я вижу массу предложений для этого, но ни один (который я нашел) не учитывает всех факторов, а именно:
- Асинхронная загрузка, без дублирования (загрузчиков и растровых изображений), с отменой загрузки/назначения изображений, которые не будут дольше нужно в любом случае
- Адаптер может иметь несколько просмотров для одного и того же ID (вызовы getView (0) очень часты)
- Нет гарантии, что представление не будет потеряно, а не переработано (рассмотрите изменение/фильтрацию списка /GridView по тексту)
- Разделение представлений и данных/логики (насколько это возможно)
- НЕ запускать отдельный поток для каждой загрузки (видимое замедление UI). Использовать очередь/стек (LinkedBlockingQueue?) И пул потоков или somesuch.... но нужно закончить это, если активность уничтожена.
- Очистка растровых изображений, достаточно удаленных от текущей позиции в списке/сетке, желательно только тогда, когда требуется память.
- Вызов recycle() для каждого Bitmap, который должен быть отброшен.
- Внешняя память может быть недоступна (вообще или все время) и, если она используется, должна быть очищена (ТОЛЬКО изображения, загруженные здесь) как можно скорее. Также рассмотрите деятельность по уничтожению/восстановлению активности на Android.
- Измененные данные: удаленные записи (выберите в списке, кнопку для удаления, немедленное обновление) и добавлены в фоновый поток (список обновляется по требованию). Уже загруженные растровые изображения должны быть сохранены, так как поскольку записи, к которым они привязаны, все еще существуют.
- (необязательно) не полагайтесь на notifyDataSetChanged (который, afaik, обновляет все видимые, потенциально очень сложные, элементы списка) для обновление одного ImageView
- setTextFilterEnabled (true) (как в ArrayAdapter. Его реализация Filterable заменяет массив данных, видимый для другого адаптера методы, поэтому изменяются индексы представлений, поэтому они не могут быть используемые в качестве идентификаторов для ссылки на битмапы).
- Используется в ExpandableList (влияет на порядок отображения эскизов)
Пожалуйста, простите меня, если на это был дан ответ. Я искал месяцы и не нашел решения.
Требования кажутся мне разумными, но каждый из них добавляет измерение сложности, особенно Bitmap.recycle, которое нужно вызывать во время работы и уничтожения активности (обратите внимание, что onDestroy, даже onStop, не может быть вызван).
Это также мешает полагаться на SoftReferences, которые могли бы позаботиться о некоторых других моментах.
Да, это необходимо, или я получаю OutOfMemoryError даже после любого количества gc, sleep (20s, even), yield и огромных распределений массивов в try-catch (чтобы заставить контролируемую ситуацию с низкой памятью).
Поиск "OutOfMemoryError: размер растрового изображения превышает бюджет VM" или "андроидальный битмап".
Да, я передискретирую битмапы.
