Решение для локального кэширования изображений для Android: Square Picasso, Universal Image Loader, Glide, Fresco?

Я ищу библиотеку асинхронной загрузки и кеширования изображений в Android. Я собирался использовать Picasso, но обнаружил, что Universal Image Loader более популярен на GitHub. Кто-нибудь знает об этих двух библиотеках? Краткое изложение плюсов и минусов было бы здорово.

(Все мои изображения находятся на диске локально, поэтому мне не нужна сеть, поэтому я не думаю, что Volley подходит)

Обновление, сентябрь 2018: через несколько лет мне понадобилось почти то же самое для решения для локального кэширования изображений. На этот раз UIL не находился в активной разработке. Я сравнил популярные библиотеки, и вывод довольно простой: просто используйте Glide. Он намного более мощный и настраиваемый. Несколько лет назад мне пришлось выполнить форк и внести изменения в UIL. Glide поддерживает все мои варианты использования с точки зрения стратегии кэширования и нескольких уровней кэширования разрешения с настраиваемыми ключами. Просто используйте Glide!

Кушик Датта сравнивает в основном тест скорости. Его пост затронул только самые простые вещи и не касается локальных изображений. Я хотел бы поделиться своим опытом работы с Пикассо и UIL после того, как задал вопрос. И Picasso, и UIL могут загружать локальные изображения. Сначала я попробовал Picasso и был счастлив, но позже решил переключиться на UIL, чтобы получить больше возможностей настройки.

Пикассо:

• Беглый интерфейс Пикассо хорош. Но прыгая с "with", "into", "load", вы на самом деле не знаете, что за сценой. Непонятно, что вернули.

• Picasso позволяет указать точный размер цели. Это полезно, когда у вас нехватка памяти или проблемы с производительностью, вы можете обменять некоторое качество изображения на скорость.

• Изображения кешируются с указанием размера в своем ключе, это полезно при отображении изображений с разными размерами.

• Вы можете настроить размер кеш-памяти. Но его дисковый кеш предназначен только для HTTP-запросов. Для локальных изображений, если вы заботитесь о скорости загрузки, хорошо иметь дисковый кеш миниатюр, чтобы вам не приходилось каждый раз читать несколько МБ для изображения. У Picasso нет этого механизма изменения размера и сохранения эскизов на диске.

• Picasso не предоставляет доступ к своему экземпляру кеша. (Вы можете получить его при первой настройке Picasso и оставить его при себе ...).

• Иногда вам нужно асинхронно считывать изображение в растровое изображение, возвращаемое слушателем. Удивительно, но у Пикассо этого нет. "fetch ()" ничего не передает. get () - для синхронного чтения, а load () - для асинхронного рисования представления.

• У Picasso есть только несколько простых примеров на домашней странице, и вам придется прочитать неупорядоченный javadoc для расширенного использования.

UIL:

• UIL использует построители для настройки. Настроить можно практически все.

• UIL не позволяет вам указать размер, который вы хотите загрузить в представление. Он использует некоторые правила, основанные на размере представления. Он не такой гибкий, как Пикассо. У меня нет возможности загрузить изображение с более низким разрешением, чтобы уменьшить объем памяти. (Изменить: это поведение можно легко изменить, добавив аргумент ImageSize в исходный код и обойдя проверку размера представления)

• UIL предоставляет настраиваемый кеш диска, вы можете использовать его для кеширования миниатюр с указанным размером. Но это не идеально. Вот подробности . (Изменить: если вы заботитесь о скорости и хотите использовать несколько уровней кеширования эскизов, как в моем случае, вы можете изменить исходный код, позволить кешу диска использовать «memoryKey», а также сделать его чувствительным к размеру)

• UIL по умолчанию кеширует изображения разных размеров в памяти, и его можно отключить в конфигурации.

• UIL предоставляет доступ к резервной памяти и дисковой кэш-памяти.

• UIL предоставляет гибкие способы получения растрового изображения или загрузки в представление.

• UIL лучше в документации. UIL предоставляет подробные сведения об использовании на странице Github, и есть связанное руководство.

Я предлагаю начать с Пикассо, если вам нужно больше контроля и настройки, выберите UIL.

Если вы прочтете этот пост в G + от Koush, вы получите четкие решения для ваших недоразумений, я изложил это вкратце: Android-Universal-Image-Loader - победитель вашего требования!

• У Picasso самый лучший API изображений, если вы используете сеть!

• UrlImageViewHelper + AndroidAsync является самым быстрым. Однако игра с этими двумя другими замечательными библиотеками действительно показала, что API изображений довольно устарел.

• Залп гладкий; Мне очень нравится их подключаемый бэкэнд-транспорт,
  и я могу в конечном итоге добавить туда AndroidAsync. Управление приоритетом запроса
  и отменой отличное (если вы используете сеть)

• Android-Universal-Image-Loader - самый популярный в
  настоящее время. Легко настраиваемый.

Этот проект направлен на создание многоразового инструмента для асинхронной загрузки, кэширования и отображения изображений. Изначально он основан на проекте Федора Власова и с тех пор был значительно переработан и улучшен.

Предстоящие изменения в новой версии UIL (1.9.2):

Возможность вызова ImageLoader из потока пользовательского интерфейса New Disk Cache API (более гибкий). Новый LruDiscCache на основе DiskLruCache Джейка Уортона.

Учитывая, что все это Android-Universal-Image-Loader удовлетворяет вашим требованиям ( загрузка изображений происходит на диске локально )!

Я хотел бы поделиться своим опытом работы с этими 3 библиотеками: UIL, Picasso и Volley. Раньше я использовал UIL, но затем пришел к выводу, что не могу его рекомендовать, и я бы предложил вместо этого использовать Volley или Picasso, которые разработаны талантливыми командами. UIL совсем неплох, но ему не хватает внимания к деталям двух других библиотек.

Я обнаружил, что UIL менее хорош с производительностью пользовательского интерфейса; он имеет тенденцию блокировать поток пользовательского интерфейса больше, чем Volley или Picasso. Частично это может быть связано с тем, что UIL не поддерживает пакетирование ответов с изображениями, в то время как Пикассо и Воллей делают это по умолчанию.

Также мне не понравилась система дискового кеширования UIL. Хотя вы можете выбирать между различными реализациями, я должен указать, что на данный момент нет способа ограничить дисковый кеш UIL как по общему размеру, так и по времени истечения срока действия объекта. Volley и Picasso делают это, и они используют время истечения срока, возвращаемое сервером по умолчанию, в то время как UIL игнорирует его.

Наконец, UIL позволяет вам установить глобальную конфигурацию загрузчика изображений, которая включает в себя выбранный дисковый кеш и реализации и настройки кэша памяти, а также другие детали, но эта конфигурация будет применяться повсюду в вашем приложении. Так что, если вам нужна большая гибкость, например, два отдельных дисковых кэша, UIL не подходит. Volley, с другой стороны, позволяет вам иметь столько отдельных загрузчиков изображений, сколько вы хотите, каждый со своей конфигурацией. Picasso по умолчанию использует глобальный экземпляр, но также позволяет создавать отдельно настраиваемые экземпляры.

Подводя итог: Picasso имеет лучший API, но он использует глобальный дисковый кеш HTTP, общий для всех HttpURLConnectionэкземпляров, что в некоторых случаях может быть слишком ограничительным. Volley имеет лучшую производительность и модульность, но менее удобен для пользователя и потребует написания одного или двух собственных модулей, чтобы он работал так, как вы хотите. В целом я бы рекомендовал их обоих против UIL.

Изменить (18 декабря 2014 г.): все изменилось с тех пор, как я написал этот первоначальный ответ, и я почувствовал, что необходимо его улучшить:

Picasso 2.4 даже более настраиваемый, чем более старые версии, и при использовании с OkHttp (что настоятельно рекомендуется) он также может использовать отдельный дисковый кеш для каждого экземпляра, поэтому на самом деле нет никаких ограничений в том, что вы можете делать. Что еще более важно, я заметил, что производительность Picasso и OkHttp значительно улучшилась, и, на мой взгляд, теперь это самый быстрый загрузчик изображений для Android. Обратите внимание, что в моем коде я всегда использую .fit()в сочетании с .centerCrop()или .centerInside()для уменьшения использования памяти и избегаю изменения размера растрового изображения в потоке пользовательского интерфейса. Picasso активно развивается и поддерживается, и это, безусловно, большой плюс.

Volley не сильно изменился, но я заметил две проблемы с ним:

• Иногда при большой нагрузке некоторые изображения больше не загружаются из-за повреждения кеша диска.
• Миниатюры, отображаемые в NetworkImageView (с типом масштаба, установленным на centerCrop), довольно размыты по сравнению с тем, что вы получаете с другими библиотеками.

По этим причинам я решил отказаться от использования Volley.

UIL по-прежнему медленный (особенно дисковый кеш), и его API имеет тенденцию меняться довольно часто.

Я также протестировал эту новую библиотеку под названием Glide 3, которая утверждает, что она более оптимизирована, чем Picasso, с API-интерфейсом, подобным Picasso. По моему личному опыту, он на самом деле медленнее, чем Picasso и Volley, во время сетевых запросов при большой нагрузке, даже когда используется в сочетании с OkHttp. Хуже того, это вызвало несколько сбоев в моих приложениях под Lollipop при выходе из активности. У него по-прежнему есть 2 преимущества перед конкурентами:

• Он поддерживает декодирование анимированных GIF-файлов.
• Он помещает окончательные уменьшенные растровые изображения в дисковый кеш, что означает, что чтение из дискового кеша происходит очень быстро.

Заключение: теперь я рекомендую использовать Picasso + OkHttp, потому что он обеспечивает лучшую гибкость, API, производительность и стабильность в сочетании. Если вам нужна поддержка GIF, вы также можете рассмотреть Glide.

Я реализовал приложение, которое должно постоянно получать и показывать изображения из Интернета. Я собирался запрограммировать механизм кеширования изображений, до этого друг порекомендовал мне универсальный загрузчик изображений.

UIL очень хорошо настраивается. Он настолько настраиваемый, что новичок может легко сделать что-то не так. Однако в моем приложении UIL работал медленно и стал немного медленнее. Моим вариантом использования был ListView с изображениями.

Вчера я искал альтернативу UIL и открыл для себя Пикассо. Picasso было легко интегрировать и использовать: просто Picasso.context(context).load(url).into(imageview)и изображение можно было бы быстрее и плавно интегрировать.

Для меня Picasso - определенно тот API, который нужно использовать. Мой опыт работы с UIL был плохим.

Я думаю, что ImageLoader более настраиваемый и гибкий по сравнению с библиотекой Picasso.