Porównanie bibliotek sieciowych Androida: OkHTTP, Retrofit i Volley [zamknięte]

Dwuczęściowe pytanie od programisty iOS uczącego się Androida, pracującego nad projektem Android, który będzie składał różne żądania od JSON do obrazu do strumieniowego pobierania audio i wideo:

1. Na iOS intensywnie korzystałem z projektu AFNetworking . Czy istnieje odpowiednik biblioteki dla systemu Android?

2. Przeczytałem o OkHTTP i Retrofit by Square, a także Volley, ale nie mam jeszcze doświadczenia w rozwijaniu z nimi. Mam nadzieję, że ktoś może podać konkretne przykłady najlepszych przypadków użycia dla każdego z nich. Z tego, co przeczytałem, wydaje się, że OkHTTP jest najsolidniejszym z trzech i może sprostać wymaganiom tego projektu (wspomnianym powyżej).

Mam nadzieję, że ktoś poda konkretne przykłady najlepszych przypadków użycia dla każdego z nich.

Użyj opcji Modernizuj, jeśli komunikujesz się z usługą internetową. Jeśli pobierasz obrazy, użyj biblioteki Picasso. Użyj OkHTTP, jeśli chcesz wykonywać operacje HTTP, które leżą poza Retrofit / Picasso.

Volley z grubsza konkuruje z Retrofit + Picasso. Na plus to jedna biblioteka. Z drugiej strony jest to jedna nieudokumentowana, nieobsługiwana biblioteka „rzuć kod na ścianę i zrób na nim prezentację I | O”.

EDYCJA - Volley jest teraz oficjalnie obsługiwany przez Google. Prosimy zapoznać się z Przewodnikiem dla programistów Google

Z tego, co przeczytałem, wydaje się, że OkHTTP jest najbardziej niezawodnym z 3

Modernizacja używa OkHTTP automatycznie, jeśli jest dostępna. Istnieje Jist Wharton, który łączy Volleya z OkHTTP.

i może obsłużyć wymagania tego projektu (wspomniane powyżej).

Prawdopodobnie nie użyjesz żadnego z nich do „strumieniowego pobierania plików audio i wideo”, zgodnie z konwencjonalną definicją „strumieniowania”. Zamiast tego platforma multimediów systemu Android obsłuży te żądania HTTP.

Biorąc to pod uwagę, jeśli zamierzasz wykonać własne strumieniowanie oparte na HTTP, OkHTTP powinien obsłużyć ten scenariusz; Nie pamiętam, jak dobrze Volley poradziłaby sobie z tym scenariuszem. Ani Modernizacja, ani Picasso nie są do tego przeznaczone.

Patrząc na perspektywę siatkówki, oto kilka zalet twojego wymagania:

Z jednej strony Volley jest całkowicie skoncentrowany na obsłudze indywidualnych, małych żądań HTTP. Jeśli więc obsługa żądań HTTP ma pewne dziwactwa, Volley prawdopodobnie ma dla ciebie haczyk. Z drugiej strony, jeśli masz dziwne podejście do przetwarzania obrazu, jedynym prawdziwym haczykiem jest ImageCache . „To nie jest nic, ale też nie jest wiele !,” ale ma więcej innych zalet, takich jak zdefiniowanie żądań, użycie ich z fragmentu lub działania jest bezbolesne, w przeciwieństwie do równoległych zadań AsyncTasks

Plusy i minusy Volley:

Co jest miłego w Volley?

• Część sieci to nie tylko obrazy. Siatkówka ma być integralną częścią zaplecza. Dla świeżego projektu opartego na prostej usłudze REST może to być duża wygrana.

• NetworkImageView jest bardziej agresywny w kwestii czyszczenia żądań niż Picasso i bardziej konserwatywny w zakresie wzorców użycia GC. NetworkImageView opiera się wyłącznie na silnych odwołaniach do pamięci i czyści wszystkie dane żądań, gdy tylko nowe żądanie zostanie utworzone dla ImageView lub gdy tylko ImageView zniknie z ekranu.

• Wydajność. Ten post nie oceni tego roszczenia, ale najwyraźniej dołożyli starań, aby zachować rozsądek w zakresie wzorców wykorzystania pamięci. Volley stara się również grupować wywołania zwrotne do głównego wątku, aby zmniejszyć przełączanie kontekstu.

• Najwyraźniej Volley też ma przyszłość. Sprawdź RequestFuture, jeśli jesteś zainteresowany.

• Jeśli masz do czynienia ze skompresowanymi obrazami w wysokiej rozdzielczości, Volley jest jedynym rozwiązaniem, które działa dobrze.

• Siatkówki można używać z Okhttp (nowa wersja Okhttp obsługuje NIO dla lepszej wydajności)

• Volley gra dobrze z cyklem życia Activity.

Problemy z Volley:
Ponieważ Volley jest nowy, niewiele rzeczy nie jest jeszcze obsługiwanych, ale zostało naprawione.

1. Wnioski wieloczęściowe (rozwiązanie: https://github.com/vinaysshenoy/enhanced-volley )

2. kod stanu 201 jest traktowany jako błąd, kod statusu od 200 do 207 jest teraz udaną odpowiedzią. (Naprawiono: https://github.com/Vinayrraj/CustomVolley )

   Aktualizacja: w najnowszej wersji Google volley błąd kodów statusu 2XX został naprawiony ! Dzięki Ficus Kirkpatrick!

3. jest mniej udokumentowany, ale wiele osób wspiera siatkówkę w github, dokumentację podobną do java można znaleźć tutaj . W witrynie dla programistów Androida możesz znaleźć przewodnik dotyczący przesyłania danych sieciowych za pomocą Volley . Kod źródłowy siatkówki można znaleźć w Google Git

4. Aby rozwiązać / zmienić Politykę przekierowań Volley Framework, użyj Volley z OkHTTP (CommonsWare wspomniane powyżej)

Możesz także przeczytać ładowanie tego obrazu Porównywanie salwy za pomocą Picassa

Modernizacja:

Jest wydany przez Square , oferuje bardzo łatwy w użyciu interfejs API REST (aktualizacja: Voila! Z obsługą NIO)

Zalety modernizacji:

• W porównaniu do Volley, kod REST API Retrofit jest krótki i zapewnia doskonałą dokumentację API i ma dobre wsparcie w społecznościach! Bardzo łatwo jest dodać do projektów.

• Możemy go używać z dowolną biblioteką serializacji, z obsługą błędów.

Aktualizacja: - Istnieje wiele bardzo dobrych zmian w Retrofit 2.0.0-beta2

• Wersja 1.6 Retrofit z OkHttp 2.0 jest teraz zależny od Okio do wsparcia java.io i java.nio co sprawia, że znacznie łatwiej dostępu, przechowywania i przetwarzania danych z wykorzystaniem ByteString i bufor zrobić kilka sprytnych rzeczy, aby zaoszczędzić CPU i pamięci. (FYI: To przypomina mi bibliotekę OIN Kousha z obsługą NIO!) Możemy użyć Retrofit razem z RxJava do łączenia i łączenia wywołań REST za pomocą rxObservables, aby uniknąć brzydkich łańcuchów oddzwaniania (aby uniknąć piekła zwrotnego !!) .

Minusy modernizacji dla wersji 1.6:

• Obsługa błędów związanych z pamięcią nie jest dobra (w starszych wersjach Retrofit / OkHttp) nie jestem pewien, czy została poprawiona dzięki Okio z obsługą Java NIO.

• Minimalna pomoc w wątkach może spowodować oddzwonienie, jeśli użyjemy tego w niewłaściwy sposób.

(Wszystkie powyższe minusy zostały rozwiązane w nowej wersji Retrofit 2.0 beta)

================================================== ======================

Aktualizacja:

Android Async vs Volley vs. Retrofit wydajności (milisekundy, im niższa wartość, tym lepiej):

(FYI powyżej informacji o testach modernizacyjnych poprawi się dzięki obsłudze JIO NIO, ponieważ nowa wersja OKhttp jest zależna od biblioteki NIO Okio)

We wszystkich trzech testach z różnymi powtórzeniami (1–25 razy) Volley był gdziekolwiek od 50% do 75% szybszy. Modernizacja zarejestrowała się imponująco od 50% do 90% szybciej niż AsyncTasks, uderzając w ten sam punkt końcowy tyle samo razy. W pakiecie testowym Dashboard przełożyło się to na ładowanie / parsowanie danych o kilka sekund szybciej. To ogromna różnica w świecie rzeczywistym. Aby testy były sprawiedliwe, czasy AsyncTasks / Volley obejmowały analizę JSON, ponieważ Retrofit robi to automatycznie.

RetroFit wygrywa w teście porównawczym!

Ostatecznie zdecydowaliśmy się na Retrofit dla naszej aplikacji. Jest nie tylko absurdalnie szybki, ale dość dobrze wpasowuje się w naszą istniejącą architekturę. Byliśmy w stanie stworzyć nadrzędny interfejs zwrotny, który automatycznie wykonuje obsługę błędów, buforowanie i paginację bez żadnego wysiłku dla naszych interfejsów API. Aby połączyć się z Retrofit, musieliśmy zmienić nazwę naszych zmiennych, aby nasze modele były zgodne z GSON, napisać kilka prostych interfejsów, usunąć funkcje ze starego API i zmodyfikować nasze fragmenty, aby nie używać AsyncTasks. Teraz, gdy kilka fragmentów zostało całkowicie przetworzonych, jest to całkiem bezbolesne. Były pewne rosnące problemy i problemy, które musieliśmy przezwyciężyć, ale ogólnie poszło gładko. Na początku natrafiliśmy na kilka problemów technicznych / błędów, ale Square ma fantastyczną społeczność Google+, która była w stanie nam pomóc.

Kiedy stosować Volley ?!

Możemy użyć Volley, gdy musimy załadować obrazy, a także zużywać interfejsy API REST !, system kolejkowania połączeń sieciowych jest potrzebny dla wielu żądań n / w jednocześnie! również Volley ma lepszą obsługę błędów związanych z pamięcią niż Retrofit!

OkHttp może być używany z Volley, Retrofit domyślnie używa OkHttp ! Obsługuje SPDY , pule połączeń, buforowanie dysku, przezroczysta kompresja! Ostatnio ma pewne wsparcie dla java NIO z Okio biblioteką .

Źródło, źródło: volley-vs-retrofit autorstwa pana Josha Ruescha

Uwaga: w przypadku przesyłania strumieniowego zależy to od rodzaju przesyłania strumieniowego, takiego jak RTSP / RTCP.

RoboSpice vs. Salwa

Od https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ

• RoboSpice (RS) jest oparty na usługach i bardziej szanuje filozofię Androida niż Volley. Siatkówka jest oparta na wątkach i nie jest to sposób, w jaki przetwarzanie w tle powinno odbywać się na Androidzie. Ostatecznie możesz wykopać obie biblioteki lib i stwierdzić, że są całkiem podobne, ale nasz sposób przetwarzania w tle jest bardziej zorientowany na Androida, pozwala nam na przykład powiedzieć użytkownikom, że RS faktycznie robi coś w tle, co byłoby trudne do gry w siatkówkę (w rzeczywistości wcale tak nie jest).
• Zarówno RoboSpice, jak i siatkówka oferują ciekawe funkcje, takie jak ustalanie priorytetów, ponawianie zasad, anulowanie żądań. Ale RS oferuje więcej: bardziej zaawansowane buforowanie i to jest duże, z zarządzaniem pamięcią podręczną, agregacją żądań, innymi funkcjami, takimi jak odpowiadanie na oczekujące żądanie, zajmowanie się wygaśnięciem pamięci podręcznej bez polegania na nagłówkach serwera itp.
• RoboSpice robi więcej poza wątkiem interfejsu użytkownika: siatkówka deserializuje twoje POJO w głównym wątku, co jest okropne dla mnie. Dzięki RS Twoja aplikacja będzie bardziej responsywna.
• Jeśli chodzi o szybkość, zdecydowanie potrzebujemy wskaźników. RS stało się teraz bardzo szybkie, ale wciąż nie mamy tu co do tego mówić. Siatkówka powinna teoretycznie być nieco szybsza, ale RS jest teraz masowo równoległy ... kto wie?
• RoboSpice oferuje duży zakres kompatybilności z rozszerzeniami. Możesz go używać z okhttp, retrofit lub ormlite (beta), jackson, jackson2, gson, xml serializer, klientem google http, wiosną Androida ... Całkiem sporo. Siatkówki można używać z ok http i używa gson. Otóż ​​to.
• Volley oferuje więcej cukru z interfejsu użytkownika niż RS. Volley zapewnia NetworkImageView, RS zapewnia adapter spicelist. Pod względem funkcji nie jest to jak dotąd, ale uważam, że Volley jest bardziej zaawansowany w tym temacie.
• Od czasu pierwszej wersji RoboSpice rozwiązano ponad 200 błędów. Jest dość solidny i intensywnie wykorzystywany w produkcji. Siatkówka jest mniej dojrzała, ale jej baza użytkowników powinna szybko rosnąć (efekt Google).
• RoboSpice jest dostępny w maven central. Trudno znaleźć siatkówkę;)

AFNetworking dla Androida:

Szybka sieć Android jest tutaj

Szybka biblioteka sieciowa Android obsługuje wszystkie typy żądań HTTP / HTTPS, takie jak GET, POST, DELETE, HEAD, PUT, PATCH

Szybka biblioteka sieciowa Android obsługuje pobieranie dowolnego rodzaju plików

Szybka biblioteka sieciowa Android obsługuje przesyłanie dowolnego rodzaju plików (obsługuje przesyłanie wieloczęściowe)

Szybka biblioteka sieciowa Android obsługuje anulowanie żądania

Szybka biblioteka sieciowa Android obsługuje ustawianie priorytetu dla każdego żądania (NISKI, ŚREDNI, WYSOKI, NATYCHMIAST)

Szybka biblioteka sieciowa Android obsługuje RxJava

Ponieważ wykorzystuje OkHttp jako warstwę sieciową, obsługuje:

Szybka biblioteka sieciowa Android obsługuje obsługę HTTP / 2, dzięki czemu wszystkie żądania do tego samego hosta współużytkują gniazdo

Szybka biblioteka sieciowa Androida korzysta z puli połączeń, co zmniejsza opóźnienie żądań (jeśli HTTP / 2 nie jest dostępne)

Przezroczysty GZIP zmniejsza rozmiary pobierania

Szybka biblioteka sieciowa Android obsługuje buforowanie odpowiedzi, co całkowicie eliminuje sieć przy powtarzaniu żądań

Dzięki: Biblioteka jest tworzona przeze mnie

Asynchroniczny klient HTTP loopj vs. Volley

Specyfiką mojego projektu są małe żądania HTTP REST, co 1-5 minut.

Używam asynchronicznego klienta HTTP (1.4.1) przez długi czas. Wydajność jest lepsza niż użycie waniliowego serwera Apache httpClient lub połączenia HTTP URL. W każdym razie nowa wersja biblioteki nie działa dla mnie: wyjątek między bibliotekami przeciął łańcuch wywołań zwrotnych.

Przeczytanie wszystkich odpowiedzi zmotywowało mnie do spróbowania czegoś nowego. Wybrałem bibliotekę Volley HTTP.

Po pewnym okresie użytkowania, nawet bez testów, widzę wyraźnie, że czas reakcji spadł do 1,5x, 2x Volley.

Może Retrofit jest lepszy niż asynchroniczny klient HTTP? Muszę tego spróbować. Ale jestem pewien, że Volley nie jest dla mnie.

Aby dodać trochę do dyskusji z mojego doświadczenia w pracy z Volley:

1. Volley nie obsługuje przesyłania strumieniowego ani pobierania w żadnym sensie. Oznacza to, że całe ciało żądania musi znajdować się w pamięci i nie można użyć polecenia an OutputStreamdo zapisania treści żądania do gniazda, ani też nie można użyć polecenia InputStreamdo odczytu treści odpowiedzi, tak jak HttpURLConnectionrobi to podstawowo . Tak więc Volley jest kiepskim wyborem do przesyłania lub pobierania dużych plików. Twoje prośby i odpowiedzi powinny być małe. To jedno z największych ograniczeń Volleya, jakie osobiście spotkałem. Za to, co jest warte, OkHttp ma interfejsy do pracy ze strumieniami.

2. Brak oficjalnej dokumentacji jest denerwujący, chociaż udało mi się to obejść, czytając kod źródłowy, co jest dość łatwe do naśladowania. Bardziej kłopotliwe jest to, że o ile mogę stwierdzić, Volley nie ma oficjalnych wersji i nie ma artefaktu Maven ani Gradle, a zatem zarządzanie tym uzależnieniem staje się bardziej bolesne niż, powiedzmy, żadna z bibliotek Square . Po prostu klonujesz repozytorium, budujesz słoik i jesteś sam. Szukasz poprawki błędu? Pobierz i miej nadzieję, że tam jest. Możesz też dostać inne rzeczy; nie będzie to udokumentowane. Moim zdaniem oznacza to, że Volley jest nieobsługiwaną biblioteką strony trzeciej, mimo że baza kodu jest dość aktywna. Zastrzegający emptor.

3. Jako nit, powiązanie Content-Type z typem klasy / żądania (JsonObjectRequest, ImageRequest itp.) Jest dość niewygodne i nieco zmniejsza elastyczność kodu wywołującego, ponieważ jesteś przywiązany do istniejącej hierarchii typów żądań Volley. Podoba mi się prostota ustawiania Content-Type jako nagłówka, jak każdy inny (tak na marginesie, nie rób tego z Volley; skończysz z dwoma nagłówkami Content-Type!). To tylko moja osobista opinia i można to obejść.

Nie oznacza to, że Volley nie ma żadnych przydatnych funkcji. Z pewnością tak. Łatwo konfigurowalne zasady ponawiania, przejrzyste buforowanie, interfejs API anulowania oraz obsługa planowania żądań i równoczesnych połączeń to świetne funkcje. Po prostu wiedz, że nie jest on przeznaczony do wszystkich przypadków użycia HTTP (patrz punkt 1 powyżej) i że istnieją pewne problemy związane z uruchomieniem Volley w produkcji w Twojej aplikacji (punkt 2).

Niedawno znalazłem lib o nazwie ion, który przynosi trochę więcej do stołu.

ion ma wbudowaną obsługę pobierania obrazów zintegrowaną z ImageView, JSON (przy pomocy GSON), pliki i bardzo przydatną obsługę wątków interfejsu użytkownika.

Używam go w nowym projekcie i jak dotąd wyniki były dobre. Jego użycie jest znacznie prostsze niż Volley lub Retrofit.

Dodając do zaakceptowanej odpowiedzi i tego, co powiedział LOG_TAG .... aby Volley parsował twoje dane w wątku w tle, musisz podklasę, Request<YourClassName>ponieważ onResponsemetoda jest wywoływana w głównym wątku, a parsowanie w głównym wątku może spowodować opóźnienie interfejsu użytkownika, jeśli twoja odpowiedź jest duży. Przeczytaj tutaj, jak to zrobić.

Modernizacja 1.9.0 vs. RoboSpice

Używam obu w mojej aplikacji.

Robospice działa szybciej niż Retrofit za każdym razem, gdy analizuję zagnieżdżoną klasę JSON. Ponieważ Spice Manger zrobi wszystko za Ciebie. W ramach modernizacji musisz utworzyć GsonConverter i dokonać deserializacji.

Utworzyłem dwa fragmenty w tej samej aktywności i zadzwoniłem w tym samym czasie z dwoma rodzajami adresów URL.

09-23 20:12:32.830  16002-16002/com.urbanpro.seeker E/RETROFIT﹕   RestAdapter Init
09-23 20:12:32.833  16002-16002/com.urbanpro.seeker E/RETROFIT﹕ calling the method
09-23 20:12:32.837  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ initialzig spice manager
09-23 20:12:32.860  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ Executing the method
09-23 20:12:33.537  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ on SUcceess
09-23 20:12:33.553  16002-16002/com.urbanpro.seeker E/ROBOSPICE﹕ gettting the all contents
09-23 20:12:33.601  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation starts
09-23 20:12:33.603  16002-21819/com.urbanpro.seeker E/RETROFIT﹕ deseriazation ends

I jeszcze jedna opcja: https://github.com/apptik/jus

• Jest modułowy jak Volley, ale jest bardziej rozbudowany, a dokumentacja się poprawia, obsługując różne stosy HTTP i konwertery po wyjęciu z pudełka
• Ma moduł do generowania mapowań interfejsu API serwera, takich jak Retrofit
• Ma także obsługę JavaRx

I wiele innych przydatnych funkcji, takich jak markery, transformatory itp.