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

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

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

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

Пикассо:

  • Свободный интерфейс Пикассо хорош. Но, прыгая с «с», «в», «загружать», вы на самом деле не знаете, что стоит за сценой. Это путает то, что вернулось.

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

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

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

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

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

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

УИЛ:

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

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

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

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

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

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

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

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

Если вы прочтете это сообщение в G + by 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 не поддерживает пакетную обработку ответов на изображение, в то время как Picasso и Volley делают это по умолчанию.

Кроме того, мне не нравилась система дискового кэша 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() чтобы уменьшить использование памяти и избежать изменения размера растровых изображений в потоке пользовательского интерфейса. Пикассо активно развивается и поддерживается, и это, безусловно, большой плюс.

Волейбол не так сильно изменился, но я заметил два вопроса:

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

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

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.