Local image caching rozwiązanie dla Androida: Plac Picasso, Universal Image Loader, Glide, Fresco?

Szukam biblioteki asynchronicznego ładowania i buforowania obrazów w Androidzie. Zamierzałem użyć Picassa, ale okazało się, że Universal Image Loader jest bardziej popularny na Githubie. Czy ktoś wie o tych dwóch bibliotekach? Podsumowanie plusów i minusów byłoby świetne.

(Wszystkie moje obrazy są na dysku lokalnie, więc nie potrzebuję sieci, dlatego uważam, że to nie pasuje)

Author: x.y, 2013-11-15
Source

5 answers

Aktualizacja wrzesień 2018: po kilku latach potrzebowałem prawie tego samego dla lokalnego rozwiązania buforowania obrazów. Tym razem UIL nie był aktywnie rozwijany. Porównałem popularne biblioteki i wniosek jest dość prosty: wystarczy użyć Glide. Jest znacznie bardziej wydajny i konfigurowalny. Lata temu musiałem rozwidlać i wprowadzić zmiany w UIL. Glide obsługuje wszystkie moje przypadki użycia pod względem strategii buforowania i wielu poziomów buforowania rozdzielczości za pomocą niestandardowych kluczy. Wystarczy użyć Ślizgaj się!

Porównanie Koushika Dutty jest głównie dla benchmarku prędkości. Jego post dotyczył tylko bardzo podstawowych rzeczy i nie jest specyficzny dla lokalnych obrazów. Chciałbym podzielić się moimi doświadczeniami z Picassem i UILEM po tym, jak zadałem pytanie. Zarówno Picasso, jak i UIL mogą ładować lokalne obrazy. Po raz pierwszy próbowałem Picassa i byłem szczęśliwy, ale później zdecydowałem się przełączyć na UIL, aby uzyskać więcej opcji dostosowywania.

Picasso:

  • Przyjemny interfejs Picassa. Ale skakanie z "Z", "do", "załadować" nie wiesz, co jest za sceną. To mylące, co wróciło.

  • Picasso pozwala określić dokładny rozmiar docelowy. Jest to przydatne, gdy masz problemy z pamięcią lub wydajnością, możesz wymienić jakość obrazu na szybkość.

  • Obrazy są buforowane z rozmiarem w kluczu, jest to przydatne podczas wyświetlania obrazów o różnych rozmiarach.

  • Możesz dostosować rozmiar pamięci podręcznej. Ale jego pamięć podręczna dysku jest tylko dla żądań http. W przypadku obrazów lokalnych, jeśli zależy ci na szybkości ładowania, dobrze jest mieć pamięć podręczną dysku miniatur, dzięki czemu nie musisz za każdym razem czytać kilku Mb dla obrazu. Picasso nie posiada takiego mechanizmu zmiany rozmiaru i zapisywania miniatur na dysku.

  • Picasso nie ujawnia dostępu do swojej instancji pamięci podręcznej. (Możesz go złapać, gdy po raz pierwszy skonfigurujesz Picasso i trzymaj go w pobliżu...).

  • Czasami chcesz asynchronicznie odczytać obraz na bitmapę zwrócony przez słuchacza. O dziwo Picasso tego nie ma. "fetch ()" nie przekazuje niczego z powrotem. "get ()" służy do odczytu synchronicznie, a" load () " do asynchronicznie rysowania widoku.

  • Picasso ma tylko kilka prostych przykładów na stronie głównej, a będziesz musiał przeczytać nieuporządkowany javadoc dla zaawansowanych zastosowań.

UIL:

  • UIL używa konstruktorów do personalizacji. Prawie wszystko można skonfigurować.

  • UIL nie pozwala określić rozmiaru, który ma zostać załadowany do widoku. Używa pewnych reguł opartych na rozmiarze widoku. Nie jest tak elastyczny jak Picasso. Nie mam sposobu, aby załadować obraz o niższej rozdzielczości, aby zmniejszyć zużycie pamięci. (Edit: to zachowanie można łatwo zmodyfikować, dodając argument ImageSize w kodzie źródłowym i pomijając sprawdzanie rozmiaru widoku)

  • UIL zapewnia konfigurowalną pamięć podręczną dysku, możesz jej użyć do buforowania miniatur o określonym rozmiarze. Ale to nie jest idealnie. Oto szczegóły . (Edit: jeśli zależy ci na szybkości i chcesz mieć wiele poziomów buforowania miniatur, jak w moim przypadku, możesz zmodyfikować kod źródłowy, pozwolić pamięci podręcznej na użycie "memoryKey" i sprawić, że będzie ona również wrażliwa na rozmiar)

  • UIL domyślnie buforuje obrazy o różnych rozmiarach w pamięci i może być wyłączony w konfiguracji.

  • UIL wyświetla pamięć zapasową i pamięć podręczną dysku, do której możesz uzyskać dostęp.

  • UIL zapewnia elastyczne sposoby Pobierz bitmapę lub Załaduj do widoku.

  • UIL jest lepszy w dokumentacji. UIL podaje szczegółowe zastosowania na stronie Github, a tam jest połączony samouczek.

Proponuję zacząć od Picassa, jeśli potrzebujesz większej kontroli i personalizacji, wybierz UIL.

 80
Author: x.y,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-09-15 22:58:17

Jeśli czytasz to post na G+ przez Koush otrzymasz jasne rozwiązania dla swoich nieporozumień, umieściłem podsumowanie tego, w tym Android-Universal-Image-Loader jest zwycięzcą dla Twoich wymagań!

  • Picasso ma najładniejsze API obrazu, jeśli używasz sieci!

  • UrlImageViewHelper + AndroidAsync jest najszybszy. Zabawa z tymi pozostałe dwie wielkie biblioteki naprawdę podkreśliły, że image API jest jednak dość przestarzały.

  • Volley jest slick; naprawdę lubię ich pluggable backend transports,
    i może skończyć się upuszczeniem AndroidAsync tam. Priorytet żądania
    zarządzanie anulowaniem jest świetne (jeśli korzystasz z sieci)

  • Android-Universal-Image-Loader jest najpopularniejszym spośród nich
    obecnie. Wysoce konfigurowalny.

Ten projekt ma na celu zapewnienie instrumentu wielokrotnego użytku dla asynchronicznych Ładowanie, buforowanie i wyświetlanie obrazu. Oryginalnie opiera się na Fedorze Projekt Własowa i został znacznie zreformowany i Ulepszony od więc.

Nadchodzące zmiany w nowej wersji UIL (1.9.2):

Możliwość wywołania ImageLoader z interfejsu threadNew Disk Cache API (bardziej elastyczny). Nowy Lrudiscache na podstawie Jake ' a Whartona DiskLruCache.

Biorąc pod uwagę wszystkie Android-Universal-Image-Loader spełnia Twoje wymagania (Loading the images are on disk local )!

 72
Author: LOG_TAG,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-11-10 23:29:28

Chciałbym podzielić się moim doświadczeniem z tymi 3 bibliotekami: UIL, Picasso i Volley. Wcześniej korzystałem z UIL, ale potem doszedłem do wniosku, że naprawdę nie mogę go polecić i sugerowałbym użycie Volley lub Picasso, które są rozwijane przez bardzo utalentowane zespoły. UIL wcale nie jest zły, ale brakuje mu dbałości o szczegóły pozostałych dwóch bibliotek.

Stwierdziłem, że UIL jest mniej miły dla wydajności UI; ma tendencję do zamykania wątku UI bardziej niż Volley czy Picasso. To może to być częściowo spowodowane faktem, że UIL nie obsługuje grupowania odpowiedzi obrazu, podczas gdy Picasso i Volley robią to domyślnie.

Nie podobał mi się też system pamięci podręcznej dysku UIL. Chociaż możesz wybierać pomiędzy różnymi implementacjami, muszę podkreślić, że w tej chwili nie ma sposobu, aby ograniczyć pamięć podręczną dysku UIL zarówno przez całkowity rozmiar i czas wygaśnięcia encji. Volley i Picasso robią to, i używają domyślnego czasu wygaśnięcia zwracanego przez serwer, podczas gdy UIL ignoruje to.

Wreszcie, UIL pozwala ustawić globalną konfigurację image loader, która zawiera wybrane implementacje pamięci podręcznej dysku i pamięci podręcznej oraz ustawienia i inne szczegóły, ale ta konfiguracja będzie stosowana wszędzie w aplikacji. Jeśli więc potrzebujesz większej elastyczności, takiej jak dwie oddzielne pamięci podręczne, nie ma mowy o UIL. Volley z drugiej strony pozwala na posiadanie tak wielu oddzielnych ładowarek obrazów, jak chcesz, każdy z własną konfiguracją. Picasso używa globalnej instancji przez domyślne, ale także pozwala na budowanie osobno konfigurowalnych instancji.

Podsumowując: Picasso ma najlepsze API, ale używa globalnej pamięci podręcznej dysku HTTP współdzielonej między wszystkimi instancjami HttpURLConnection, co w niektórych przypadkach może być zbyt restrykcyjne. Volley ma najlepszą wydajność i modułowość, ale jest mniej przyjazny dla użytkownika i będzie wymagał napisania własnego modułu lub dwóch, aby działał tak, jak chcesz. Ogólnie polecam je zarówno przeciwko UIL.

Edit (Dec 18 2014): Wszystko się zmieniło, odkąd napisałem tę wstępną odpowiedź i uznałem, że trzeba ją poprawić:

Picasso 2.4 jest jeszcze bardziej konfigurowalny niż starsze wydania, a gdy jest używany z OkHttp (co jest wysoce zalecane), jest również w stanie użyć oddzielnej pamięci podręcznej dysku dla każdej instancji, więc naprawdę nie ma ograniczeń w tym, co możesz zrobić. Co ważniejsze, zauważyłem, że wydajność Picassa i OkHttp znacznie się poprawiła i moim zdaniem jest to teraz najszybszy image loader rozwiązanie dla Androida, kropka. Proszę zauważyć, że w moim kodzie zawsze używam .fit() w połączeniu z .centerCrop() lub .centerInside(), aby zmniejszyć zużycie pamięci i uniknąć zmiany rozmiaru bitmap w wątku UI. Picasso jest aktywnie rozwijany i wspierany, a to z pewnością duży plus.

Volley nie zmienił się tak bardzo, ale zauważyłem dwa problemy z nim w międzyczasie:

  • czasami przy dużym obciążeniu niektóre obrazy nie są ładowane z powodu uszkodzenia pamięci podręcznej dysku.
  • miniatury wyświetlane w Sieciimageview (z typem skali ustawionym na centerCrop) są dość niewyraźne w porównaniu z innymi bibliotekami.

Z tych powodów postanowiłem przestać używać Volley.

UIL jest nadal powolny (szczególnie pamięć podręczna dysku), a jego API ma tendencję do częstych zmian.

Przetestowałem również nową bibliotekę o nazwie Glide 3 , która twierdzi, że jest bardziej zoptymalizowana niż Picasso z API podobnym do Picassa. Według mojego osobistego doświadczenia to w rzeczywistości wolniejszy niż Picasso i Volley podczas żądań sieciowych pod dużym obciążeniem, nawet gdy jest używany w połączeniu z OkHttp. Co gorsza, spowodowało to kilka awarii z moimi aplikacjami pod lizakiem podczas opuszczania aktywności. Nadal ma 2 przewagi nad konkurentami:

  • obsługuje dekodowanie animowanych GIFów
  • umieszcza ostateczną skalowaną bitmapę w pamięci podręcznej dysku, co oznacza, że odczyt z pamięci podręcznej dysku jest niezwykle szybki.

Wniosek: I teraz polecam używać Picasso + OkHttp, ponieważ zapewnia najlepszą elastyczność, API, wydajność i stabilność w połączeniu. Jeśli potrzebujesz wsparcia GIF, Możesz również rozważyć Glide.

 45
Author: BladeCoder,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-12-18 01:03:36

Zaimplementowałem aplikację, która powinna stale pobierać i wyświetlać obrazy z Internetu. Miałem zaprogramować mechanizm pamięci podręcznej obrazów, wcześniej znajomy polecił mi universal image loader.

UIL jest bardzo dobrze konfigurowalny. Jest tak konfigurowalny, że początkujący może łatwo zrobić coś złego. Jednak UIL był powolny w mojej aplikacji i stał się nieco wolniejszy. Moim przypadkiem użycia był Widok listy z obrazami.

Wczoraj Szukałem alternatywy dla UIL i ja odkryliśmy Picassa. Picasso był łatwy w integracji i użyciu: po prostu Picasso.context(context).load(url).into(imageview) i obraz mógł być szybszy i płynny być zintegrowany.

Dla mnie Picasso jest zdecydowanie API do użycia. Moje doświadczenia z UIL nie były dobre.

 7
Author: Samuel L,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-06-23 18:07:27

Myślę, że ImageLoader jest bardziej konfigurowalny i elastyczny w porównaniu do biblioteki Picassa.

 0
Author: Jin Ding,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-07-27 03:25:30