Решение для локального кэширования изображений для Android: Square Picasso, Universal Image Loader, Glide, Fresco?
Я ищу асинхронную библиотеку загрузки и кэширования изображений в Android. Я собирался использовать Picasso, но обнаружил, что Universal Image Loader более популярен на GitHub. Кто-нибудь знает об этих двух библиотеках? Резюме плюсов и минусов было бы здорово.
(Все мои образы находятся на диске локально, поэтому мне не нужны сети, поэтому я не думаю, что Volley подходит)
5 ответов
Обновление, сентябрь 2018 года. Через несколько лет мне понадобилось почти то же самое для локального решения для кэширования изображений. На этот раз UIL не находился в активной разработке. Я сравнил популярные библиотеки, и вывод довольно прост: просто используйте Glide. Это гораздо более мощный и настраиваемый. Несколько лет назад мне пришлось раскошелиться и внести изменения в UIL. Glide поддерживает все мои варианты использования с точки зрения стратегии кэширования и многоуровневого кэширования разрешения с помощью пользовательских ключей. Просто используйте Glide!
Сравнение Koushik Dutta в основном для оценки скорости. Его пост затронул только самые элементарные вещи и не является специфическим для местных образов. Я хотел бы поделиться своим опытом с Пикассо и UIL после того, как я задал вопрос. И Picasso, и UIL могут загружать локальные изображения. Я сначала попробовал Picasso и был счастлив, но позже я решил переключиться на UIL для большего количества настроек.
Пикассо:
Свободный интерфейс Пикассо хорош. Но прыгая с "с", "в", "загрузить", вы на самом деле не знаете, что за сценой. Это сбивает с толку, что вернулся.
Пикассо позволяет вам указать точный размер цели. Это полезно, когда у вас проблемы с памятью или проблемы с производительностью, вы можете обменять некоторое качество изображения на скорость.
Изображения кэшируются с размером в его ключе, это полезно, когда вы отображаете изображения разных размеров.
Вы можете настроить размер кеша памяти. Но его дисковый кеш предназначен только для http-запросов. Для локальных изображений, если вы заботитесь о скорости загрузки, хорошо иметь миниатюрный дисковый кэш, чтобы вам не приходилось каждый раз считывать несколько МБ для изображения. В Picasso нет этого механизма изменения размера и сохранения миниатюр на диске.
Пикассо не предоставляет доступ к своему экземпляру кэша. (Вы можете ухватиться за него, когда вы впервые настроите Пикассо и сохраните его...).
Иногда вы хотите асинхронно прочитать изображение в растровое изображение, возвращаемое слушателем. Удивительно, но у Пикассо этого нет. Доза "fetch()" ничего не передает обратно. "get()" - для синхронного чтения, а "load()" - для асинхронного отображения представления.
У Пикассо есть только несколько простых примеров на главной странице, и вам придется прочитать неупорядоченный Javadoc для продвинутого использования.
УИЛ:
UIL использует компоновщики для настройки. Почти все можно настроить.
UIL не позволяет вам указать размер, который вы хотите загрузить в представление. Он использует некоторые правила, основанные на размере представления. Это не так гибко, как Пикассо. У меня нет возможности загрузить изображение с более низким разрешением, чтобы уменьшить объем памяти. (Редактировать: это поведение можно легко изменить, добавив аргумент ImageSize в исходный код и пропустив проверку размера представления)
UIL предоставляет настраиваемый дисковый кеш, вы можете использовать его для кэширования миниатюр с указанным размером. Но это не идеально. Вот подробности. (Изменить: если вы заботитесь о скорости и хотите использовать несколько уровней кэширования миниатюр, как в моем случае, вы можете изменить исходный код, разрешить кэшу диска использовать "memoryKey" и сделать его также чувствительным к размеру)
UIL по умолчанию кэширует изображения разных размеров в памяти, и это можно отключить в конфигурации.
UIL предоставляет доступ к резервной памяти и дисковому кешу, к которым вы можете получить доступ.
UIL предоставляет гибкие способы получения растрового изображения или загрузки в представление.
UIL лучше в документации. UIL подробно описывает использование на странице Github, и есть связанное руководство.
Я предлагаю начать с Picasso, если вам нужно больше контроля и настройки, перейдите на UIL.
Если вы прочитаете этот пост на G+ от Koush, вы получите четкие решения для ваших недоразумений, я поместил краткое изложение этого в том, что Android-Universal-Image-Loader является победителем для ваших требований!
Picasso имеет лучший API изображений, если вы используете сеть!
https://github.com/koush/UrlImageViewHelper + AndroidAsync - самый быстрый. Игра с этими двумя другими замечательными библиотеками действительно показала, что API изображений довольно устарел.
Залп гладкий; Мне очень нравятся их сменные бэкэнд-транспорты,
и может в конечном итоге сбросить AndroidAsync там. Приоритет запроса
и отмены управления отлично (если вы используете сеть)https://github.com/nostra13/Android-Universal-Image-Loader - самый популярный
В настоящее время. Высоко настраиваемый.
Этот проект направлен на предоставление многоразового инструмента для асинхронной загрузки изображений, кэширования и отображения. Первоначально он основан на проекте Федора Власова и с тех пор был значительно переработан и улучшен.
Предстоящие изменения в новой версии UIL (1.9.2):
Возможность вызывать ImageLoader из потока пользовательского интерфейса. Новый Disk Cache API (более гибкий). Новый LruDiscCache, основанный на DiskLruCache Джейка Уортона.
Учитывая все это Android-Universal-Image-Loader соответствует вашим требованиям (Загрузка изображений на диск локально)!
Я хотел бы поделиться своим опытом с этими 3 библиотеками: UIL, Picasso и Volley. Ранее я использовал UIL, но потом пришел к выводу, что не могу его порекомендовать, и я бы предложил вместо этого использовать Volley или Picasso, которые разработаны высококвалифицированными командами. UIL совсем неплох, но ему не хватает внимания к деталям двух других библиотек.
Я обнаружил, что UIL менее хорош с производительностью пользовательского интерфейса; он имеет тенденцию блокировать поток пользовательского интерфейса больше, чем Волей или Пикассо. Отчасти это может быть связано с тем, что UIL не поддерживает пакетную обработку ответов изображений, в то время как Пикассо и Волли делают это по умолчанию.
Также мне не понравилась система дискового кэша UIL. Хотя вы можете выбирать между различными реализациями, я должен отметить, что в настоящее время нет способа ограничить дисковый кеш UIL как по общему размеру, так и по времени истечения сущности. Волей и Пикассо делают это, и они используют время истечения, возвращаемое сервером по умолчанию, в то время как UIL игнорирует его.
Наконец, UIL позволяет вам установить глобальную конфигурацию загрузчика образов, которая включает в себя выбранные реализации дискового кэша и кэша памяти, а также другие детали, но эта конфигурация будет применяться везде в вашем приложении. Поэтому, если вам нужна большая гибкость, например, два отдельных дисковых кэша, для UIL нет смысла. Volley, с другой стороны, позволяет вам иметь столько отдельных загрузчиков изображений, сколько вам нужно, каждый со своей конфигурацией. Picasso по умолчанию использует глобальный экземпляр, но также позволяет создавать отдельно настраиваемые экземпляры.
Подводя итог: у Picasso лучший API, но он использует глобальный дисковый кеш HTTP, общий для всех HttpURLConnection случаи, которые могут быть слишком ограничительными в некоторых случаях. Volley обладает лучшей производительностью и модульностью, но менее удобен для пользователя и требует, чтобы вы написали один или два собственных модуля, чтобы он работал так, как вы хотите. В целом, я бы порекомендовал их обоих против UIL.
Изменить (18 декабря 2014): С тех пор, как я написал этот первоначальный ответ, все изменилось, и я почувствовал, что необходимо улучшить его:
Picasso 2.4 даже более настраиваемый, чем более старые версии, и при использовании с OkHttp (что настоятельно рекомендуется) он также может использовать отдельный дисковый кэш для каждого экземпляра, поэтому на самом деле нет никаких ограничений в том, что вы можете сделать. Что еще более важно, я заметил, что производительность Picasso и OkHttp значительно улучшилась, и, на мой взгляд, сейчас это самое быстрое решение для загрузки изображений для Android. Обратите внимание, что в моем коде я всегда использую .fit() в комбинации с .centerCrop() или же .centerInside() чтобы уменьшить использование памяти и избежать изменения размеров растрового изображения в потоке пользовательского интерфейса. Picasso активно развивается и поддерживается, и это, безусловно, большой плюс.
Залп не сильно изменился, но я заметил две проблемы с ним:
- Иногда при большой нагрузке некоторые изображения больше не загружаются из-за повреждения дискового кэша.
- Миниатюры, отображаемые в NetworkImageView (с типом масштаба, установленным на centerCrop), выглядят довольно размытыми по сравнению с тем, что вы получаете с другими библиотеками.
По этим причинам я решил прекратить использовать залп.
UIL все еще медленный (особенно кеш диска), и его API часто меняется.
Я также протестировал эту новую библиотеку под названием Glide 3, которая утверждает, что она более оптимизирована, чем Picasso, с Picasso-подобным API. Согласно моему личному опыту, он на самом деле медленнее, чем Пикассо и Волли, во время сетевых запросов под большой нагрузкой, даже когда используется в сочетании с OkHttp. Хуже того, это вызвало несколько сбоев с моими приложениями в Lollipop при выходе из активности. Он по-прежнему имеет 2 преимущества перед конкурентами:
- Поддерживает декодирование анимированных GIF-файлов.
- Он помещает окончательные уменьшенные растровые изображения в дисковый кеш, что означает, что чтение из дискового кеша выполняется очень быстро.
Вывод: теперь я рекомендую использовать Picasso + OkHttp, поскольку он обеспечивает наилучшую гибкость, API, производительность и стабильность в сочетании. Если вам нужна поддержка GIF, вы также можете рассмотреть Glide.
Я реализовал приложение, которое должно постоянно получать и показывать изображения из интернета. Я собирался запрограммировать механизм кэширования изображений, до этого мой друг рекомендовал мне универсальный загрузчик изображений.
UIL очень хорошо настраивается. Это настолько настраиваемо, что новичок может легко сделать что-то не так. Тем не менее, UIL был медленным в моем приложении, и он стал немного медленнее. Мой вариант использования был ListView с изображениями.
Вчера я искал альтернативу UIL и обнаружил Пикассо. Пикассо было легко интегрировать и использовать: просто Picasso.context(context).load(url).into(imageview) и изображение может быть быстрее и плавно интегрироваться.
Для меня Picasso - определенно API для использования. Мой опыт работы с UIL не был хорошим.
Я думаю, ImageLoader более настраиваемый и гибкий по сравнению с библиотекой Picasso.