Місцеве рішення кешування зображень для Android: Square Picasso, Universal Image Loader, Glide, Fresco?


89

Я шукаю асинхронну бібліотеку для завантаження та кешування зображень в Android. Я збирався використовувати Пікассо, але виявив, що Universal Image Loader є більш популярним на GitHub. Хтось знає про ці дві бібліотеки? Короткий виклад плюсів і мінусів буде чудовим.

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

Відповіді:


80

Оновлення вересня 2018 року: Через кілька років мені знадобилося майже те саме для рішення локального кешування зображень. Цього разу UIL ще не активно розвивався. Я порівняв популярні бібліотеки, і висновок є досить безглуздим: просто використовуйте Glide. Це набагато потужніше і налаштовується. Багато років тому мені довелося розщедритися та внести зміни до UIL. Glide підтримує всі мої випадки використання з точки зору стратегії кешування та декількох рівнів кешування роздільної здатності за допомогою спеціальних клавіш. Просто використовуйте Glide!

Порівняння Кушика Дутти здебільшого стосується еталону швидкості. Його допис торкався лише найпростіших речей і не є специфічним для місцевих зображень. Я хотів би поділитися своїм досвідом з Пікассо та UIL після того, як я задав питання. Як Пікассо, так і UIL можуть завантажувати локальні зображення. Спочатку я спробував Пікассо і був щасливий, але згодом вирішив перейти на UIL, щоб отримати більше можливостей налаштування.

Пікассо:

  • Вільний інтерфейс Пікассо приємний. Але стрибаючи з "з", "в", "навантажити", ви насправді не знаєте, що за кадром. Збиває з пантелику те, що повернуто.

  • Пікассо дозволяє вказати точний розмір цілі. Це корисно, коли у вас є проблеми з тиском пам’яті або продуктивністю, ви можете змінити якість зображення на швидкість.

  • Зображення кешуються з розміром у ключі, це корисно, коли ви відображаєте зображення з різними розмірами.

  • Ви можете налаштувати розмір кеш-пам'яті. Але його кеш-диск призначений лише для запитів http. Для локальних зображень, якщо ви дбаєте про швидкість завантаження, добре мати кеш диска мініатюр, щоб не потрібно було читати кілька МБ для зображення щоразу. Пікассо не має цього механізму зміни розміру та збереження ескізів на диску.

  • Пікассо не надає доступ до свого екземпляру кешу. (Ви можете отримати його під час першого налаштування Пікассо та тримати його поруч ...).

  • Іноді хочеться асинхронно прочитати зображення у растровому зображенні, яке повертає слухач. Дивно, що цього у Пікассо немає. доза "fetch ()" нічого не передає назад. "get ()" - для синхронного читання, а "load ()" - для асинхронного малювання подання.

  • Пікассо має лише кілька простих прикладів на домашній сторінці, і вам доведеться прочитати невпорядкований javadoc для вдосконаленого використання.

UIL:

  • UIL використовує конструктори для налаштування. Майже все можна налаштувати.

  • UIL не дозволяє вказати розмір, який потрібно завантажити у подання. Він використовує деякі правила, засновані на розмірі подання. Він не такий гнучкий, як Пікассо. Я не можу завантажити зображення з нижчою роздільною здатністю, щоб зменшити обсяг пам'яті. (Редагувати: цю поведінку можна легко змінити, додавши аргумент ImageSize у вихідний код і обійшовши перевірку розміру подання)

  • UIL забезпечує настроюваний кеш диска, ви можете використовувати його для кешування мініатюр із заданим розміром. Але це не ідеально. Ось деталі . (Редагувати: якщо ви дбаєте про швидкість і хочете кілька рівнів кешування ескізів, як у моєму випадку, ви можете змінити вихідний код, дозволити кешу диска використовувати "memoryKey" і зробити його також чутливим до розміру)

  • UIL за замовчуванням кешує зображення різного розміру в пам'яті, і його можна вимкнути в конфігурації.

  • UIL надає резервну пам'ять та кеш-пам'ять диска, до яких ви маєте доступ.

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

  • UIL краще в документації. UIL надає детальне використання на сторінці Github, і є пов’язаний навчальний посібник.

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


Я насправді застряг між ними обома ... По суті, я збираюся повернути зображення зі свого сервера, що зберігаються в каталозі там ... так що через http-дзвінки, а потім зберігати їх для кешування (ескіз та звичайний розмір, я, мабуть, збережу обидва розміри в моєму каталозі) ... чи пікассо - шлях тоді?
Lion789

@ Lion789 Picasso робить лише кеш локальної пам’яті для локальних файлів, і він використовує HttpResponseCache для кешування мережевих дисків, ви повинні це вивчити. UIL має настроюваний кеш диска, ви можете внести деякі невеликі зміни, щоб дозволити йому приймати різні розміри зображень / ескізів. Можливо, спочатку спробуйте Пікассо, якщо ви вважаєте його занадто обмеженим, перейдіть за UIL та налаштуйте
XY

Тож Пікассо може завантажувати менші зображення! Тоді мені не потрібно завантажувати 8-мегапіксельні! Дякую, ви допомогли мені!
Арон Лорінч

Чи можете ви відповісти на це запитання? stackoverflow.com/questions/35433895/…
Усман Рана

UIL does not allow you to specify the size you want to load into a viewне правда на 100% .. з UIL можна скористатисяpublic void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options, ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener)
Мартін Млостек

72

Якщо ви прочитаєте цю публікацію на G + від Koush, ви отримаєте чіткі рішення для ваших плутанин, я помістив короткий виклад цього, оскільки Android-Universal-Image-Loader є переможцем для ваших вимог!

  • Пікассо має найкращий API зображень, якщо ви використовуєте мережу!

  • UrlImageViewHelper + AndroidAsync - це найшвидший. Граючи з цими двома іншими чудовими бібліотеками, справді підкреслили, що API зображень досить застарілий.

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

  • Android-Universal-Image-Loader - найпопулярніший на сьогоднішній
    день. Дуже настроюється.

Цей проект має на меті забезпечити багаторазовий інструмент для асинхронного завантаження, кешування та відображення зображень. Спочатку він базується на проекті Федора Власова і з тих пір був значно реконструйований та вдосконалений.

Найближчі зміни в новій версії UIL (1.9.2):

Можливість виклику ImageLoader з потоку інтерфейсу, API нового дискового кешу (більш гнучкий). Новий LruDiscCache на основі DiskLruCache Джейка Уортона.

Враховуючи всі ці набори Android-Universal-Image-Loader, ви відповідаєте вашим вимогам ( завантаження зображень відбувається на диск локально )!


Я починав з Пікассо і закінчив перехід на Universal, незважаючи на те, що все було повністю реалізовано. Пікассо має кращий інтерфейс API, але також має багато проблем. Це був останній цвях у труні.
Лісандро

45

Я хотів би поділитися своїм досвідом із цими 3 бібліотеками: UIL, Picasso та Volley. Раніше я використовував UIL, але тоді я прийшов до висновку, що не можу насправді рекомендувати його, і я б запропонував використовувати Volley або Picasso замість них, які розроблені дуже талановитими командами. UIL зовсім не поганий, але йому бракує уваги до деталей інших двох бібліотек.

Я виявив, що UIL є менш приємним із виконанням інтерфейсу; він, як правило, блокує потік інтерфейсу більше, ніж Волей або Пікассо. Частково це може бути пов’язано з тим, що UIL не підтримує пакетне реагування на зображення, тоді як Пікассо та Воллі роблять це за замовчуванням.

Крім того, мені не сподобалась система кешування диска UIL. Хоча ви можете вибирати між різними реалізаціями, мені потрібно зазначити, що на даний момент немає можливості обмежити кеш-пам’ять диска UIL як загальним розміром, так і часом закінчення сутності. Волей і Пікассо роблять це, і вони використовують час закінчення, повернутий сервером за замовчуванням, тоді як UIL ігнорує його.

Нарешті, UIL дозволяє встановити глобальну конфігурацію завантажувача зображень, яка включає обрані реалізації кеш-пам’яті диска та кешу пам’яті та налаштування та інші деталі, але ця конфігурація буде застосована скрізь у вашому додатку. Отже, якщо вам потрібна більша гнучкість, як два окремі дискові кеші, для UIL це не можна. Volley, з іншого боку, дозволяє вам мати скільки завгодно окремих завантажувачів зображень, кожен зі своєю конфігурацією. Пікассо за замовчуванням використовує глобальний екземпляр, але також дозволяє створювати окремо налаштовані екземпляри.

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

Редагувати (18 грудня 2014 р.): З моменту написання цієї початкової відповіді все змінилося, і я відчув, що це потрібно вдосконалити:

Picasso 2.4 є навіть більш налаштованим, ніж попередні версії, і при використанні з OkHttp (що настійно рекомендується) він також може використовувати окремий кеш диска для кожного екземпляра, тому насправді немає обмежень у тому, що ви можете зробити. Що ще важливіше, я помітив, що продуктивність Picasso та OkHttp значно покращилася, і, на мій погляд, це зараз найшвидше рішення для завантаження зображень для Android. Зверніть увагу, що в моєму коді я завжди використовую .fit()в поєднанні з .centerCrop()або .centerInside()для зменшення використання пам'яті та уникнення зміни розмірів растрових зображень в потоці інтерфейсу користувача. Пікассо активно розробляється і підтримується, і це, безумовно, великий плюс.

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

  • Іноді під великим навантаженням деякі зображення більше не завантажуються через пошкодження кешу диска.
  • Ескізи, що відображаються в NetworkImageView (із типом масштабу, встановленим на centerCrop), досить розмиті в порівнянні з тим, що ви отримуєте в інших бібліотеках.

З цих причин я вирішив припинити користуватися Volley.

UIL все ще працює повільно (особливо кеш диска), і його API має тенденцію змінюватися досить часто.

Я також протестував цю нову бібліотеку під назвою Glide 3, яка стверджує, що вона оптимізована більше, ніж Пікассо з API, подібним до Пікассо. Згідно з моїм особистим досвідом, це насправді повільніше, ніж Пікассо та Волей, під час мережевих запитів під великим навантаженням, навіть коли використовується в поєднанні з OkHttp. Гірше, це призвело до декількох збоїв у роботі моїх програм під льодяником, коли виходили з активності. Він все ще має 2 переваги перед конкурентами:

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

Висновок: Зараз я рекомендую використовувати Picasso + OkHttp, оскільки він забезпечує найкращу гнучкість, API, продуктивність та стабільність у поєднанні. Якщо вам потрібна підтримка GIF, ви також можете розглянути Glide.


1
Щоб вирішити свою останню точку на UIL, ви можете створити скільки завгодно різних ImageLoaderкласів та конфігурацій. Вам просто потрібно підклас ImageLoaderкласу. Дивіться тут: github.com/nostra13/Android-Universal-Image-Loader/issues/…
TalkLittle

Схоже на хак, але дякую за підказку, це добре знати.
BladeCoder

3
Не можу сказати, що я погоджуюся з настроями, ми використовуємо тут Пікассо, у мене є альбом із 500+ зображеннями з високою роздільною здатністю, і я стикався з проблемами продуктивності та пам'яті, пробував UIL, і речі миттєво вирішувались. Це було зроблено на мінімальній вибірці, яка відокремила наші проблеми, які ми спостерігали.
HaMMeReD

Якщо ви відображаєте зображення, які мають набагато вищу роздільну здатність, ніж екран, або багато ескізів зображень із високою роздільною здатністю, вам обов’язково слід зняти вибірку. Я думаю, що UIL робить це автоматично, а Пікассо - ні, якщо ви не вказали правильні параметри, отже, проблеми з пам'яттю. Я особисто вважаю за краще використовувати NetworkImageView у Volley, це віджет, який зменшує вибірку завантаженого зображення до власного розміру.
BladeCoder

В UIL клас DisplayImageOptions можна використовувати, якщо ми не хочемо змінювати або застосовувати якусь іншу обробку до певного зображення.
Рахул Растогі,

7

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

UIL дуже добре настроюється. Він настільки настроюється, що новачок може легко зробити щось не так. Однак UIL працював повільно в моєму додатку, і він став трохи повільнішим. Моїм випадком використання був ListView із зображеннями.

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

Для мене Пікассо - це, безумовно, API для використання. Мій досвід роботи з UIL був поганим.


Для майбутніх читачів: Краще від Пікассо - це Glide. Погляньте
тампрашант

0

Я думаю, що ImageLoader є більш настроюваним та гнучким порівняно з бібліотекою Пікассо.


8
Як? допоможе невелике пояснення.
Дарпан,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.