Android - Хранение изображений загружено с сети
Мне связали вопрос с тем, должен ли (и как) я сохранить изображения, загруженные от сети. Скажем, я называю веб-сервис из своего приложения для Android. В этом веб-сервисе я получаю URL для изображения в сети. Я загружаю и показываю это изображение на левой стороне пункта списка в ListView. Мой вопрос, какой метод я должен использовать для того, чтобы возможно сохранить изображение? Если я:
- Спасите его к SDCard, проверив, существует ли это, когда ListView создан (по последующим запросам) и повторно загружающий по мере необходимости (обновляя изображение иногда, в случае, если это изменяется).
- Сохраните его в тайнике, используя Context.getCacheDir (), но возможно будучи вынужденным повторно загружать его чаще, так как я не могу полагаться на изображение, остающееся в тайнике.
- Всегда загружайте его и никогда не храните изображение.
Сами файлы изображения довольно маленькие, но я ожидаю, что у некоторых пользователей могли быть десятки этих маленьких изображений, загружал/хранил. Который работал бы лучше всего, и/или каков предпочтительный метод?
Как вопрос о стороне, я должен загрузить все изображения в моем ListView сначала (и возможно захватывать UI в течение некоторого времени), или загрузите их асинхронно, но покажите заполнителю, графическому тем временем (который мог бы быть немного более «ужасным»)? Каков стандарт здесь?
3 ответа
О том, где хранить: Ответ зависит от того, что загружается и сколько. Тогда вы делаете выбор.
Например: если вы загружаете что-то, что это временно, меньше в количестве (менее удаленных вариантах) и размером (меньше памяти) и является локальным для активности, то вам следует рассмотреть возможность проведения изображений в памяти с использованием SoftReferences. Софоки могут привести к появлениям, но поскольку количество предметов мало, он должен быть доступным.
Тем не менее, если количество загруженных элементов превышает определенный порог (значение большее значение и память), вы должны рассмотреть возможность уменьшения выборов, а также потребление памяти времени выполнения, кэшируя их. Здесь вы можете либо выбирать, чтобы сохранить их на SDCard или на временном хранилище (Cache Camestiers Local для приложения). Для предметов, которые являются небольшими и удерживают значение только в контексте приложения (E.G миниатюры), пользователь в основном не будет использовать его вне вашего приложения. Итак, вы можете хранить такие вещи в каталоге кэша. Лучшая часть использования их состоит в том, что вам не нужно чистить беспорядок. Он обрабатывается автоматически. Это может привести к повторному выборам.
Однако, если загруженные элементы большие размеры и могут стоять в одиночестве за пределами контекста приложения, такого как изображения, видео, аудиожисты, то SDCARD должен быть вашим вариантом. Вы также должны прочитать: Обработка больших растровых изображений, чтобы избежать ошибки OOM во время BitmapFactory.DeCodeStream (..)
Обратите внимание, что вы также можете проверить, можно увидеть, можно ли использовать базу данных здесь. Увидеть это
Некоторые соображения во время ленивых предметов погрузки в ListView: Вы должны сделать загрузку на заднем плане и не заблокировать ui ust. Вы должны рассмотреть возможность отображения временного изображения, пока элемент загружается. Это очевидно во многих родных приложениях. Для примера реализации ленивой нагрузки см. Это . Кроме того, для больших списков вы можете реализовать шаблон SLASEDADAPTER (проверьте демонстрацию API). Он в основном киоски загружают, пока список прокручивается.
Пример проектов, которые могут помочь вам здесь:
Проект полки Romain Guyeain использует два уровня кэширования, в котором он использует кэш памяти (HASHMAP, содержащий Softreferences) и хранение на SDCard. Просматривайте исходный код здесь
Есть также несколько библиотек открытых исходных кодов, которые Mark Murphy писал (CWAC) и Droidfu, которые могут помочь здесь.
Удачи!
В отношении вашего «побочного вопроса» - я думаю, что загрузка их асинхронно будет предпочтительным поведением, особенно поскольку вам нужно учитывать, что с сетевыми транзакциями, это может не просто быть «блокировать пользовательский интерфейс», Но «заблокировать UI постоянно», если он никогда не загружается.
Если вы считаете это поведение уродливым, хотя вы могли бы установить таймер (1 или 2 секунды), который дает несколько изображений шансов загрузить, и если они все загружены или истек, истек В любом случае показывают пользовательские пользователи с изображениями заполнителя и позвольте остальной нагрузке асинхронно. Это было бы способом предотвратить постоянные замки в любом случае.
Что касается первой части вашего вопроса, я думаю, что он несколько зависит от контекста и типа изображений, которые вы отображаете. Однако с большинством веб-активов, однако, я думаю, что является предпочтительным подходом, поскольку вы, безусловно, не хотите загружать несколько раз на одном сеансе, но вы, вероятно, не хотите есть постоянное хранение.
Что касается вашего «побочного вопроса» - я думаю, что асинхронная загрузка была бы предпочтительным поведением, тем более что вы должны учитывать, что с сетевыми транзакциями это может не просто быть «заблокировать пользовательский интерфейс на некоторое время», но «заблокировать пользовательский интерфейс навсегда», если он никогда не загружается.
Чтобы избежать этого, если мы говорим о WebImageView от droid-fu, вы можете изменить функцию ImageLoader.java initialize () на эту
static int alive=-1;
public static synchronized void initialize(Context context) {
if (executor == null) {
executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);
}
else if(alive==executor.getActiveCount()){
executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(DEFAULT_POOL_SIZE);
}
alive=executor.getActiveCount();
if (imageCache == null) {
imageCache = new ImageCacheHope(context, 25, 5);
}
}