Vergleich von Android-Netzwerkbibliotheken: OkHTTP, Retrofit und Volley

Question

Zweiteilige Frage von einem iOS-Entwickler, der Android lernt und an einem Android-Projekt arbeitet, das eine Vielzahl von Anfragen von JSON bis Bild bis Streaming-Download von Audio und Video durchführen wird:

1. Auf iOS habe ich das AFNetworking-Projekt umfangreich verwendet. Gibt es eine äquivalente Bibliothek für Android?

2. Ich habe mich über OkHTTP und Retrofit von Square sowie Volley informiert, habe jedoch noch keine Erfahrung mit der Entwicklung damit. Ich hoffe, dass jemand konkrete Beispiele für die besten Anwendungsfälle für jede dieser Bibliotheken geben kann. Aus dem, was ich gelesen habe, scheint OkHTTP die robusteste der drei zu sein und könnte die Anforderungen dieses Projekts (oben erwähnt) erfüllen.

Answer 1

Ich hoffe, dass jemand konkrete Beispiele für die besten Anwendungsfälle für jeden bereitstellen kann.

Verwenden Sie Retrofit, wenn Sie mit einem Webdienst kommunizieren. Verwenden Sie die Peer-Bibliothek Picasso, wenn Sie Bilder herunterladen. Verwenden Sie OkHTTP, wenn Sie HTTP-Operationen durchführen müssen, die außerhalb von Retrofit/Picasso liegen.

Volley konkurriert grob mit Retrofit + Picasso. Auf der positiven Seite handelt es sich um eine Bibliothek. Auf der negativen Seite handelt es sich um eine nicht dokumentierte, eine nicht unterstützte Bibliothek, bei der der Code einfach über die Mauer geworfen wird und eine I|O-Präsentation darauf durchgeführt wird.

EDIT - Volley wird nun offiziell von Google unterstützt. Bitte beachten Sie den Google Entwicklerleitfaden

Von dem, was ich gelesen habe, scheint OkHTTP die robusteste der 3 zu sein

Retrofit verwendet automatisch OkHTTP, wenn verfügbar. Es gibt einen Gist von Jake Wharton, der Volley mit OkHTTP verbindet.

und könnte die Anforderungen dieses Projekts (oben erwähnt) erfüllen.

Vermutlich werden Sie keines davon für den "Streaming-Download von Audio und Video" verwenden, gemäß der herkömmlichen Definition von "streaming". Stattdessen wird das Android-Media-Framework diese HTTP-Anfragen für Sie behandeln.

Trotzdem, wenn Sie versuchen möchten, Ihr eigenes auf HTTP basierendes Streaming durchzuführen, sollte OkHTTP dieses Szenario bewältigen; Ich erinnere mich nicht daran, wie gut Volley dieses Szenario bewältigen würde. Weder Retrofit noch Picasso sind dafür ausgelegt.

Answer 2

RoboSpice Vs. Volley

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

• RoboSpice(RS) basiert auf Services und respektiert die Android-Philosophie mehr als Volley. Volley basiert auf Threads und dies ist nicht der richtige Weg für die Hintergrundverarbeitung auf Android. Letztendlich kann man feststellen, dass beide Bibliotheken ziemlich ähnlich sind, aber unsere Art der Hintergrundverarbeitung ist mehr auf Android ausgerichtet. Wir können den Benutzern beispielsweise mitteilen, dass RS tatsächlich im Hintergrund etwas tut, was für Volley schwierig wäre (eigentlich überhaupt nicht).
• RoboSpice und Volley bieten beide schöne Funktionen wie Priorisierung, Wiederholungsrichtlinien, Anfrageabbruch. Aber RS bietet mehr: einen fortschrittlicheren Cache und das ist groß, mit Cache-Management, Anfrage-Aggregation, mehr Funktionen wie das Anschließen an eine ausstehende Anfrage, Umgang mit Cache-Ablauf ohne auf Server-Header angewiesen zu sein, etc.
• RoboSpice erledigt mehr außerhalb des UI-Threads: Volley deserialisiert Ihre POJOs im Hauptthread, was meiner Meinung nach schrecklich ist. Mit RS wird Ihre App reaktionsschneller sein.
• In Bezug auf Geschwindigkeit brauchen wir definitiv Metriken. RS ist jetzt super schnell geworden, aber wir haben immer noch keine Zahlen, die wir hier angeben können. Volley sollte theoretisch etwas schneller sein, aber RS ist jetzt massiv parallel... wer weiß?
• RoboSpice bietet eine große Kompatibilitätsbandbreite mit Erweiterungen. Sie können es mit okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml-Serializer, Google HTTP-Client, Spring Android verwenden... ziemlich viel. Volley kann mit Okhttp verwendet werden und verwendet Gson. Das war's.
• Volley bietet mehr UI-Zucker als RS. Volley bietet NetworkImageView, RS bietet einen SpiceList-Adapter. In Bezug auf Funktionen ist es nicht so weit, aber ich glaube, Volley ist in diesem Bereich fortschrittlicher.
• In RoboSpice wurden seit der ersten Veröffentlichung mehr als 200 Fehler behoben. Es ist ziemlich robust und wird intensiv in der Produktion eingesetzt. Volley ist weniger ausgereift, aber seine Benutzerbasis sollte schnell wachsen (Google-Effekt).
• RoboSpice ist auf Maven Central verfügbar. Volley ist schwer zu finden ;)

Answer 3

AFNetworking für Android:

Fast Android Networking ist hier

Die Fast Android Networking Library unterstützt alle Arten von HTTP/HTTPS-Anfragen wie GET, POST, DELETE, HEAD, PUT, PATCH

Die Fast Android Networking Library unterstützt das Herunterladen jeglicher Dateitypen

Die Fast Android Networking Library unterstützt das Hochladen beliebiger Dateitypen (unterstützt mehrfachen Upload)

Die Fast Android Networking Library unterstützt das Abbrechen einer Anfrage

Die Fast Android Networking Library unterstützt die Prioritäteneinstellung für jede Anfrage (NIEDRIG, MITTEL, HOCH, SOFORT)

Die Fast Android Networking Library unterstützt RxJava

Da sie OkHttp als Netzwerkschicht verwendet, unterstützt sie:

Die Fast Android Networking Library unterstützt HTTP/2, was allen Anfragen an denselben Host ermöglicht, einen Socket zu teilen

Die Fast Android Networking Library verwendet Verbindungspooling, das die Anforderungsverzögerung reduziert (wenn HTTP/2 nicht verfügbar ist)

Transparentes GZIP verkleinert die Downloadgrößen

Die Fast Android Networking Library unterstützt Response-Caching, um für wiederholte Anfragen das Netzwerk vollständig zu meiden

Danke: Die Bibliothek wurde von mir erstellt

Answer 4

Async HTTP-Client Loopj vs. Volley

Die Details meines Projekts sind kleine HTTP-REST-Anfragen, alle 1-5 Minuten.

Ich benutze seit langer Zeit einen asynchronen HTTP-Client (1.4.1). Die Leistung ist besser als bei der Verwendung des normalen Apache HttpClient oder einer HTTP-URL-Verbindung. Wie auch immer, die neue Version der Bibliothek funktioniert nicht für mich: Die Bibliotheksinterausnahme unterbricht die Kette der Rückrufe.

Das Lesen aller Antworten hat mich dazu motiviert, etwas Neues auszuprobieren. Ich habe mich für die Volley HTTP-Bibliothek entschieden.

Nachdem ich sie eine Weile benutzt habe, auch ohne Tests, sehe ich klar, dass die Reaktionszeit um das 1,5- bis 2-fache schneller ist als bei Volley.

Vielleicht ist Retrofit besser als ein asynchroner HTTP-Client? Das muss ich ausprobieren. Aber ich bin sicher, dass Volley nichts für mich ist.

Answer 5

Nur um etwas zum Thema hinzuzufügen, aus meiner Erfahrung mit der Arbeit mit Volley:

1. Volley behandelt keine Streaming-Uploads oder -Downloads in irgendeiner Weise. Das heißt, der gesamte Anforderungskörper muss im Speicher sein und Sie können kein OutputStream verwenden, um den Anforderungskörper in den zugrunde liegenden Socket zu schreiben, noch können Sie ein InputStream verwenden, um den Antwortkörper zu lesen, wie es das grundlegende HttpURLConnection tut. Also, Volley ist keine gute Wahl für das Hochladen oder Herunterladen großer Dateien. Ihre Anfragen und Antworten sollten klein sein. Dies ist eine der größten Einschränkungen von Volley, die ich persönlich festgestellt habe. OkHttp hat übrigens Schnittstellen zum Arbeiten mit Streams.

2. Das Fehlen offizieller Dokumentationen ist ärgerlich, obwohl ich das durch das Lesen des Quellcodes umgangen habe, was ziemlich einfach zu verstehen ist. Was ärgerlicher ist, ist, dass Volley meines Wissens nach keine offiziellen Release-Versionen hat und kein Maven- oder Gradle-Artefakt, wodurch das Verwalten als Abhängigkeit mehr Kopfschmerzen verursacht als beispielsweise bei den Bibliotheken, die Square veröffentlicht hat. Sie müssen einfach ein Repository klonen, ein Jar erstellen und sind auf sich allein gestellt. Auf der Suche nach einem Bugfix? Abrufen und hoffen, dass es da ist. Sie könnten auch einige andere Dinge bekommen; sie werden nicht dokumentiert sein. Meiner Meinung nach bedeutet dies effektiv, dass Volley eine nicht unterstützte Bibliothek von Drittanbietern ist, obwohl die Codebasis durchaus aktiv ist. Caveat emptor.

3. Als kleiner Kritikpunkt ist es etwas umständlich und reduziert die Flexibilität des Aufrufcodes etwas, wenn der Content-Type an die Klasse/Anforderungstyp (JsonObjectRequest, ImageRequest usw.) gebunden ist, da Sie an der bestehenden Anforderungstypenhierarchie von Volley gebunden sind. Ich mag die Direktheit, den Content-Type einfach wie jeden anderen Header festzulegen (übrigens nicht mit Volley machen; Sie bekommen zwei Content-Type-Header!). Das ist nur meine persönliche Meinung und es kann umgangen werden.

Das soll nicht heißen, dass Volley keine nützlichen Funktionen hat. Das hat es sicherlich. Leicht anpassbare Wiederholungsrichtlinien, transparentes Zwischenspeichern, eine Stornierungs-API und Unterstützung für Anforderungsplanung und gleichzeitige Verbindungen sind großartige Funktionen. Aber bedenken Sie, dass es nicht für alle HTTP-Anwendungsfälle gedacht ist (siehe Punkt 1 oben) und dass es einige Kopfschmerzen gibt, wenn Sie Volley in Ihrer App in die Produktion bringen (Punkt 2).