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

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ą?

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.

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

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

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.

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.

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

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).