Picasso v / s Imageloader v / s Fresco vs Glide [zamknięte]

344

Wyniki:

  1. Różnica pomiędzy Picasso v / s ImageLoader tutaj ...
  2. Informacje o bibliotece GLIDE tutaj ...
  3. Niedawno Facebook wydał nową bibliotekę obrazów o nazwie Fresco

Pytania:

  1. Jaka jest różnica między Picasso v / s Imageloader v / s Fresco
  2. Kiedy możemy użyć Glide
  3. Której biblioteki najlepiej użyć.
  4. Jeśli każda biblioteka ma swoje znaczenie, jakie one są?
Devrath
źródło
Interesuję się również freskami. ktoś może wyjaśnić różnicę?
Krit,
8
To nie jest miejsce do zadawania pytań na podstawie opinii
danny117
16
@ danny117 więc co możemy tutaj zrobić, jeśli nie mamy o tym pojęcia?
Anand Savjani,
2
@ShobhitPuri to narzędzie pomoże Ci sprawdzić liczbę metod
Nicholas Ng

Odpowiedzi:

189

Jestem jednym z inżynierów projektu Fresco. Więc oczywiście jestem stronniczy.

Ale nie musisz mi wierzyć na słowo. Wypuściliśmy przykładową aplikację, która pozwala porównać wydajność pięciu bibliotek - Fresco, Picasso, UIL, Glide i Volley Image Loader - obok siebie. Możesz go uzyskać w naszym repozytorium GitHub .

Powinienem również zauważyć, że Fresco jest dostępne w Maven Central, as com.facebook.fresco:fresco.

Fresco oferuje funkcje, których Picasso, UIL i Glide nie mają jeszcze:

  1. Obrazy nie są przechowywane w stercie Java, ale w stercie ashmem. Pośrednie bufory bajtów są również przechowywane w natywnej stercie. To pozostawia o wiele więcej pamięci dostępnej dla aplikacji. Zmniejsza to ryzyko wystąpienia błędów OutOfMemoryErrors. Zmniejsza to również liczbę czynności związanych z odśmiecaniem aplikacji, co prowadzi do lepszej wydajności.
  2. Progresywne obrazy JPEG można przesyłać strumieniowo, podobnie jak w przeglądarce internetowej.
  3. Obrazy można przycinać wokół dowolnego punktu, nie tylko środka.
  4. Obrazy JPEG można zmieniać natywnie. Pozwala to uniknąć problemu OOMing podczas próby zmniejszenia rozmiaru obrazu.

Jest wiele innych ( zobacz naszą dokumentację ), ale są one najważniejsze.

tyronen
źródło
1
Dzięki, czy możesz dołączyć do odpowiedzi wynik „Wydaliśmy przykładową aplikację, która pozwala porównać wydajność pięciu bibliotek” w formacie tabelarycznym?
mmlooloo,
1
Fresco ma więcej funkcji niż inne, ale jest też znacznie większe ..
ligi
4
dodali „s” z tyłu linku. github.com/facebook/fresco/tree/master/samples
JR Tan
@tyronen jestem zainteresowany Freskiem. Czy pozwala ładować lokalne obrazy zamiast z sieci? Dzięki
GmloMalo,
1
@wedi tak to jest.
tyronen
131

Pamiętaj, że jest to pytanie oparte w dużej mierze na opiniach, więc przestałem robić fiordy i zrobiłem szybki stół

wprowadź opis zdjęcia tutaj

Teraz porównanie bibliotek jest trudne, ponieważ przy wielu parametrach wszystkie cztery właściwie robią to samo, z wyjątkiem Fresco, ponieważ jest w nim cała masa nowych optymalizacji poziomu pamięci. Daj mi więc znać, czy chcesz podać pewne parametry zobacz porównanie dla mojego doświadczenia.

Przy najmniejszym użyciu Fresco odpowiedź może ewoluować, gdy będę ją nadal używać i rozumieć w przypadku bieżących exploitów. used personallySię, które korzystały z biblioteki conajmniej raz w wypełnionej aplikacji.

* Uwaga - Fresco obsługuje teraz animacje GIF oraz WebP

Vrashabh Irde
źródło
1
Jestem ciekawy niższej oceny „Możliwość dostosowania”, „Wykorzystania obrazu sieciowego” i „Łatwości użytkowania” dla Fresco. Jakie są podstawy tych ocen?
tyronen
1
Przeważnie po raz pierwszy użyje Fresco, aby lepiej zrozumieć, ta odpowiedź może ewoluować :)
Vrashabh Irde
1
@Slartibartfast Czy miałeś okazję wypróbować Fresco i najnowszą wersję Glide 3.0? Czy nadal oceniasz je tak samo?
Shobhit Puri
2
Przegapiłeś jeden ważny aspekt. ... rozmiar biblioteki. Jest to główny powód, dla którego Picasso i UImageLoader nie obsługują formatu GIF. Warto również uwzględnić licencje.
Codeversed
3
@AhamadullahSaikat Te, których osobiście użył.
Pierre
112

Fresco źródła | poza witryną
(-)
- Ogromny rozmiar biblioteki
- Brak wywołania zwrotnego z widokiem, parametry bitmapy
- SimpleDraweeView nie obsługuje zawartości wrap_content
- Ogromny rozmiar pamięci podręcznej
(+)
- Dość szybki program ładujący obrazy (dla małych i średnich obrazów)
- Duża funkcjonalność (przesyłanie strumieniowe, narzędzia do rysowania, zarządzanie pamięcią itp.)
- Możliwość ustawienia bezpośrednio w xml (na przykład zaokrąglone rogi)
- Obsługa GIF
- Obsługa WebP i Animated Webp


Źródła Picassa | poza witryną
(-)
- Powolne ładowanie dużych obrazów z Internetu do ListView
(+) - Mały rozmiar
biblioteki
- Mały rozmiar pamięci podręcznej
- Prosty w użyciu
- Interfejs użytkownika nie zawiesza się
- Obsługa WebP


Źródła poślizgu

(-)
- Duży rozmiar biblioteki
(+)
- Mały rozmiar pamięci podręcznej
- Prosty w użyciu
- Obsługa GIF
- Obsługa WebP
- Szybkie ładowanie dużych obrazów z Internetu do ListView
- Interfejs użytkownika nie zawiesza się
- BitmapPool ponownie wykorzystuje pamięć i a zatem mniejsze zdarzenia GC


Źródła Universal Image Loader

(-)
- Ograniczona funkcjonalność (ograniczone przetwarzanie obrazu)
- Wsparcie projektu zostało zatrzymane od 27.11.2015
(+)
- Mały rozmiar biblioteki
- Prosty w użyciu


Testowane przeze mnie na SGS2 (Android 4.1) (WiFi 8.43 Mbps)
Oficjalne wersje dla Java, nie dla Xamarin!
19 października 2015 r.

Wolę używać Glide.
Przeczytaj więcej tutaj .
Jak zapisać pamięć podręczną w pamięci zewnętrznej (karta SD) za pomocą Glide.

Włodzimierz Kulyk
źródło
4
„Dość szybki moduł ładujący obrazy” wydaje się być sprzeczny z „zamrażaniem aplikacji” dla Fresco.
TWiStErRob
2
Mam Picasso w projekcie Xamarin, a użycie pamięci było OGROMNE (używane do ładowania obrazów do widoku recyklera). OutOfMemorycały czas ...
Vahid Amiri,
@ VSG24 są 2 opcje: 1) używasz go źle. 2) Wersja lib dla Androida (java) nie jest taka sama dla Xamarain
Volodymyr Kulyk
1
Jako negatyw poślizgu (-) doświadczyłem dużo migotania. Załadowane obrazy zostałyby „zresetowane” znikąd
FRR
1
@RJFares Niedawno wypróbowałem najnowszą wersję, której można użyć, ImagePipelineConfig.setDownsampleEnabled(true)aby zapobiec jej zamrożeniu. Ale czasami pomija klatki GIF. Jeśli wyświetlasz tylko statyczne obrazy w swojej aplikacji, myślę, że możesz spróbować.
Kimi Chiu
109

Te odpowiedzi są całkowicie moją opinią

Odpowiedzi

  1. Picasso jest łatwym w użyciu programem ładującym, podobnie jak Imageloader. Fresco stosuje inne podejście do ładowania obrazu, jeszcze go nie użyłem, ale wydaje mi się, że to raczej rozwiązanie do pobierania obrazu z sieci i buforowania go, a następnie wyświetlania obrazów. potem na odwrót, jak Picasso / Imageloader / Glide, które według mnie bardziej pokazują obraz na ekranie, który również pobiera obrazy z sieci i buforuje je.

  2. Glide stara się być w pewnym stopniu wymienny z Picasso. Myślę, że kiedy zostały stworzone, Picasso ustawił się zgodnie ze specyfikacjami HTTP i pozwolił serwerowi decydować o zasadach buforowania i buforować pełny rozmiar i zmieniać rozmiar na żądanie. Szybkość jest taka sama z postępowaniem zgodnie ze specyfikacją HTTP, ale stara się mieć mniejszy ślad pamięci, przyjmując różne założenia, takie jak buforowanie obrazów o zmienionym rozmiarze zamiast obrazów o pełnym rozmiarze i wyświetlanie obrazów z RGB_565 zamiast RGB_8888. Obie biblioteki oferują pełną personalizację ustawień domyślnych.

  3. Trudno powiedzieć, która biblioteka jest najlepsza w użyciu. Picasso, Glide i Imageloader to dobrze szanowane i dobrze przetestowane biblioteki, z których wszystkie są łatwe w użyciu z domyślnymi ustawieniami. Zarówno Picasso, jak i Glide wymagają tylko 1 linii kodu, aby załadować obraz oraz mieć symbol zastępczy i obraz błędu. Dostosowanie zachowania również nie wymaga tak dużo pracy. To samo dotyczy Imageloadera, który jest również starszą biblioteką niż Picasso i Glide, jednak nie korzystałem z niego, więc nie mogę powiedzieć wiele o wydajności / zużyciu pamięci / dostosowaniach, ale patrząc na readme na github, mam wrażenie, że jest to również stosunkowo łatwy w użyciu i konfiguracji. Wybierając dowolną z tych 3 bibliotek, nie możesz podjąć złej decyzji, to bardziej kwestia osobistego gustu.Podobnie jak facebook SDK wciąż nie jest oficjalnie wydany na mavenCentral Nie korzystałem z facebooka sdk od września 2014 roku i wygląda na to, że wprowadzili pierwszą wersję online na mavenCentral w październiku 2014 roku. Więc może minąć trochę czasu, zanim będziemy mogli uzyskać dobra opinia na ten temat.

  4. między 3 wielkimi bibliotekami nazw uważam, że nie ma znaczących różnic. Jedyny, który się wyróżnia, to fresk, ale to dlatego, że ma inne podejście i jest nowy, a nie testowany w bitwie.

Egida
źródło
3
Drobna nit: wygląda na to, że Facebook SDK był oficjalnie dostępny jako AAR w Maven Central od jakiegoś czasu. developers.facebook.com/docs/android/…
2015 r.
1
dzięki za korektę, minęło trochę czasu, odkąd użyłem SDK na Facebooku, więc tego nie sprawdziłem. Nadal zajęło im to zbyt wiele czasu.
Aegis
1
Rok po przeczytaniu tego nadal zastanawiam się, czy powinienem użyć Frescoe i nadal nie rozumiem, dlaczego powinienem. Podczas gdy Glide i Picasso działają od razu po wyjęciu z pudełka, Frescoe musi po prostu zrobić tak wiele rzeczy, że nie wygląda na to, że jest tego warte i wielkości ....
frostymarvelous
Chcę zauważyć
Fabian Zeindl
Doświadczyłem również problemów z pamięcią podczas fresku, niestety wydaje się, że musi to być fresk lub szybowanie, jeśli potrzebujesz animowanego wsparcia gif. Również FWIW tutaj jest link do niektórych dodatkowych szczegółów porównania.
Nick
63

Ani Glide, ani Picasso nie są idealne. Sposób, w jaki Glide ładuje obraz do pamięci i buforuje, jest lepszy niż Picasso, dzięki czemu obraz ładuje się znacznie szybciej. Ponadto pomaga również zapobiegać popularnej aplikacji OutOfMemoryError w aplikacji. Ładowanie animacji GIF to funkcja zabijania zapewniana przez Glide. W każdym razie Picasso dekoduje obraz w lepszej jakości niż Glide.

Który wolę? Chociaż używam Picassa przez tak długi czas, muszę przyznać, że teraz wolę Glide. Ale zaleciłbym zmianę formatu bitmapy na ARGB_8888 i pozwolenie Glide'owi buforować zarówno obraz w pełnym rozmiarze, jak i rozmiar pierwszego. Reszta wykonałaby twoją robotę świetnie!

  • Liczba metod Picassa i Glide'a wynosi odpowiednio 840 i 2678.
  • Rozmiar Picassa (v2.5.1) wynosi około 118 KB, a Glide (v3.5.2) około 430 KB.
  • Glide tworzy buforowane obrazy według rozmiaru, podczas gdy Picasso zapisuje pełny obraz i przetwarza go, więc po załadowaniu pokazuje szybciej z Glide, ale zużywa więcej pamięci.
  • Domyślnie Glide zużywa mniej pamięci RGB_565.

+1 za pomocnika palety Picasso .

Jest post, który dużo mówi o postu Picasso kontra Glide

Daniel Gomez Rico
źródło
Doskonały artykuł. Teraz przechodzę na Glide. Nawet lepiej niż Picasso nie miałem tego na myśli. :)
Sufian,
1
Jednym z problemów, które widzę, jest to, że Glide wymaga API 10. To trochę problem, ponieważ nie mogę porzucić obsługi API 9 z mojej aplikacji. W przeciwnym razie z pewnością lepszy sposób.
Sufian
Czy możesz wyjaśnić, dlaczego używasz interfejsu API 9? po prostu ciekawy ...
Daniel Gomez Rico
Chyba że coś mi umknie, jest to obsługa wszystkich wersji Gingerbread.
Sufian,
1
Myślę, że to trochę subiektywne. Ale lepiej jest obsługiwać jak najwięcej urządzeń / wersji. Nie? :)
Sufian,
18

Chcę podzielić się z wami testem , który zrobiłem między Picasso, Universal Image Loader i Glide : https://bit.ly/1kQs3QN

Fresco nie wchodziło w zakres testów, ponieważ w projekcie, w którym przeprowadzałem test, nie chcieliśmy zmieniać naszych układów (z powodu widoku Drawee).

Polecam Universal Image Loader ze względu na jego dostosowanie, zużycie pamięci i równowagę między rozmiarem a metodami.

Jeśli masz mały projekt, wybrałbym Glide (lub spróbuję Fresco).

Shollmann
źródło