Comparaison des bibliothèques de réseau Android : OkHTTP, Retrofit, et Volley

Question

Question en deux parties d'un développeur iOS apprenant Android, travaillant sur un projet Android qui effectuera une variété de requêtes allant du JSON à l'image en passant par le téléchargement en streaming d'audio et de vidéos :

1. Sur iOS, j'ai beaucoup utilisé le projet AFNetworking. Y a-t-il une bibliothèque équivalente pour Android ?

2. J'ai lu des informations sur OkHTTP et Retrofit de Square, ainsi que sur Volley, mais je n'ai pas encore d'expérience dans le développement avec eux. J'espère que quelqu'un pourra fournir des exemples concrets des meilleurs cas d'utilisation pour chacun d'eux. D'après ce que j'ai lu, il semble qu'OkHTTP soit le plus robuste des trois et pourrait gérer les exigences de ce projet (mentionnées ci-dessus).

Answer 1

Je souhaite que quelqu'un puisse fournir des exemples concrets des meilleurs cas d'utilisation pour chacun.

Utilisez Retrofit si vous communiquez avec un service Web. Utilisez la bibliothèque similaire Picasso si vous téléchargez des images. Utilisez OkHTTP si vous devez effectuer des opérations HTTP en dehors de Retrofit/Picasso.

Volley rivalise grosso modo avec Retrofit + Picasso. Le plus est qu'il s'agit d'une seule bibliothèque. Le moins est qu'il s'agit d'une bibliothèque non documentée, non supportée, "jetez le code par-dessus le mur et faites-en une présentation I|O".

EDIT - Volley est désormais officiellement pris en charge par Google. Veuillez consulter le Guide du développeur Google

D'après ce que j'ai lu, il semble qu'OkHTTP soit le plus robuste des 3

Retrofit utilise automatiquement OkHTTP s'il est disponible. Il y a un Gist de Jake Wharton qui connecte Volley à OkHTTP.

et pourrait répondre aux exigences de ce projet (mentionné ci-dessus).

Probablement, vous n'utiliserez aucun d'entre eux pour le "téléchargement en streaming de fichiers audio et vidéo", selon la définition classique du "streaming". Au lieu de cela, le framework multimédia d'Android gérera ces requêtes HTTP pour vous.

Cela dit, si vous envisagez de faire votre propre streaming basé sur HTTP, OkHTTP devrait gérer ce scénario; je ne me souviens pas comment Volley gérerait ce scénario. Ni Retrofit ni Picasso ne sont conçus pour cela.

Answer 2

Si l'on considère le point de vue de Volley, voici quelques avantages pour vos besoins :

Volley, quant à lui, est totalement axé sur la gestion de petites requêtes HTTP individuelles. Ainsi, si votre gestion des requêtes HTTP présente quelques bizarreries, Volley a probablement un crochet pour vous. Si, d'un autre côté, vous avez une bizarrerie dans votre gestion des images, le seul vrai crochet que vous avez est ImageCache . "Ce n'est pas rien, mais ce n'est pas beaucoup non plus". mais il a d'autres avantages comme Une fois que vous avez défini vos requêtes, les utiliser à partir d'un fragment ou d'une activité est sans douleur, contrairement aux AsyncTasks parallèles.

Avantages et inconvénients de Volley :

Qu'est-ce qui est bien avec Volley ?

• La mise en réseau n'est pas réservée aux images. Volley se veut partie intégrante de votre back-end. Pour un nouveau projet basé sur un simple service REST, cela pourrait être une grande victoire.

• NetworkImageView est plus agressif dans le nettoyage des requêtes que Picasso, et plus conservateur dans ses schémas d'utilisation du GC. NetworkImageView s'appuie exclusivement sur des références de mémoire fortes et nettoie toutes les données de requête dès qu'une nouvelle requête est faite pour une ImageView, ou dès que cette ImageView quitte l'écran.

• Performance. Ce billet n'évaluera pas cette affirmation, mais il est clair qu'ils ont clairement pris soin d'être judicieux dans leurs schémas d'utilisation de la mémoire. Volley s'efforce également de regrouper les callbacks dans le thread principal afin de pour réduire le changement de contexte.

• Volley a apparemment aussi des avenirs. Consultez RequestFuture si vous êtes intéressés.

• Si vous avez affaire à des images compressées à haute résolution, Volley est la solution idéale. la seule solution qui fonctionne bien.

• Volley peut être utilisé avec Okhttp (la nouvelle version d'Okhttp supporte NIO pour de meilleures performances).

• Volley s'intègre parfaitement dans le cycle de vie de l'activité.

Problèmes avec Volley :
Comme Volley est nouveau, certaines choses ne sont pas encore supportées, mais elles sont corrigées.

1. Demandes multipartites (Solution : https://github.com/vinaysshenoy/enhanced-volley )

2. Le code d'état 201 est considéré comme une erreur, les codes d'état de 200 à 207 sont maintenant des réponses positives (corrigé) : https://github.com/Vinayrraj/CustomVolley )

   Mise à jour : dans la dernière version de Google volley, le bogue des codes d'état 2XX est fixe Merci à Ficus Kirkpatrick !

3. il est moins documenté mais de nombreuses personnes soutiennent volley sur github, on peut y trouver une documentation de type java aquí . Sur le site web des développeurs Android, vous pouvez trouver un guide pour Transmission de données de réseau à l'aide de Volley . Le code source de volley est disponible à l'adresse suivante Google Git

4. Résoudre/changer Politique de redirection de Volley Utilisation du cadre Volley avec OkHTTP (CommonsWare mentionné ci-dessus)

Vous pouvez également lire ceci Comparaison entre le chargement d'images de Volley et Picasso

Rénovation :

Il est publié par Carré Il offre des API REST très faciles à utiliser (Mise à jour : Voila ! avec le support NIO)

Avantages de la modernisation :

• Par rapport à Volley, le code de l'API REST de Retrofit est bref et fournit une excellente documentation sur l'API et bénéficie d'un bon soutien de la part des communautés ! Il est très facile de l'ajouter dans les projets.

• Nous pouvons l'utiliser avec n'importe quelle bibliothèque de sérialisation, en gérant les erreurs.

Mise à jour : - Il y a beaucoup de très bons changements dans Retrofit 2.0.0-beta2

• La version 1.6 de Retrofit with OkHttp 2.0 est maintenant dépendante de Okio pour soutenir java.io y java.nio qui facilite grandement l'accès, le stockage et le traitement de vos données à l'aide de Chaîne d'octets y Tampon de faire des choses intelligentes pour économiser le processeur et la mémoire. (Pour information : cela me rappelle l'histoire de la L'OIN de Koush avec support NIO !) Nous pouvons utiliser Rétrofit avec RxJava pour combiner et enchaîner des appels REST en utilisant rxObservables pour éviter les vilaines chaînes de callbacks (pour éviter l'enfer du callback !!) .

Les inconvénients de Retrofit pour la version 1.6 :

• La fonctionnalité de gestion des erreurs liées à la mémoire n'est pas bonne (dans les anciennes versions de Retrofit/OkHttp). Je ne sais pas si elle a été améliorée avec Okio et le support Java NIO.

• L'assistance minimale en matière de filtrage peut entraîner un enfer de rappel si l'on utilise cette méthode. d'une manière inappropriée.

(Tous les problèmes ci-dessus ont été résolus dans la nouvelle version de Retrofit 2.0 beta)

\========================================================================

Mise à jour :

Comparaison des performances entre Android Async, Volley et Retrofit (en millisecondes, la valeur la plus faible étant la meilleure) :

(Pour information, les informations ci-dessus sur les benchmarks Retrofit s'amélioreront avec la prise en charge de java NIO car la nouvelle version d'OKhttp dépend de la bibliothèque NIO Okio).

Dans les trois tests avec des répétitions variables (1 - de 50 % à 75 % plus rapide. Retrofit a obtenu un score impressionnant de 50 % à 90 % plus rapide que les AsyncTasks, en atteignant le même point de le même nombre de fois. Sur la suite de tests Dashboard, cela s'est traduit par que le chargement et l'analyse des données s'effectuaient plusieurs secondes plus rapidement. Il s'agit là d'une différence énorme dans le monde réel. Pour que les tests soient équitables, l'option temps pour AsyncTasks/Volley incluent l'analyse JSON comme le fait Retrofit Retrofit le fait automatiquement pour vous.

RetroFit remporte un test de référence !

Finalement, nous avons opté pour Retrofit pour notre application. Non seulement non seulement il est ridiculement rapide, mais il s'intègre très bien dans notre architecture existante. Nous avons pu créer une interface Callback qui effectue automatiquement la gestion des erreurs, la mise en cache et la et la pagination, avec peu ou pas d'effort pour nos API. Afin de fusionner avec Retrofit, nous avons dû renommer nos variables pour rendre nos modèles GSON écrire quelques interfaces simples, supprimer des fonctions de l'ancienne API l'ancienne API, et modifier nos fragments pour ne pas utiliser AsyncTasks. Maintenant que nous quelques fragments complètement convertis, c'est assez facile. Il y a eu Il y a eu quelques difficultés de croissance et des problèmes que nous avons dû surmonter, mais dans l'ensemble cela s'est déroulé sans problème. mais dans l'ensemble, tout s'est bien passé. Au début, nous avons rencontré quelques problèmes techniques, mais Square dispose d'une fantastique communauté Google+ qui qui nous a aidés à résoudre ces problèmes.

Quand utiliser Volley ?!

Nous pouvons utiliser Volley lorsque nous avons besoin de charger des images ainsi que de consommer des API REST, un système de file d'attente d'appels réseau est nécessaire pour de nombreuses requêtes n/w en même temps ! De plus, Volley gère mieux les erreurs liées à la mémoire que Retrofit !

OkHttp peut être utilisé avec Volley, Retrofit utilise OkHttp par défaut ! Il a SPDY support, pooling de connexions, mise en cache du disque, compression transparente ! Récemment, il a obtenu le support de java NIO avec Okio bibliothèque.

Source, crédit : volley-vs-retrofit par M. Josh Ruesch

Nota: En ce qui concerne le streaming, cela dépend du type de streaming que vous souhaitez, comme RTSP/RTCP.

Answer 3

RoboSpice Vs. Volley

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

• RoboSpice (RS) est basé sur le service et plus respectueux de la philosophie Android que Volley. Volley est basé sur des threads et ce n'est pas la manière dont le traitement en arrière-plan devrait se passer sur Android. En fin de compte, vous pouvez creuser dans les deux bibliothèques et constater qu'elles sont assez similaires, mais notre façon de faire le traitement en arrière-plan est plus orientée Android, cela nous permet, par exemple, d'informer les utilisateurs que RS est effectivement en train de faire quelque chose en arrière-plan, ce qui serait difficile pour Volley (en fait, pas du tout).
• RoboSpice et volley offrent tous deux de belles fonctionnalités comme la priorisation, les stratégies de réessai, l'annulation de requête. Mais RS offre plus : une mise en cache plus avancée et c'est important, avec une gestion du cache, une agrégation de requêtes, plus de fonctionnalités comme le rebranchement à une requête en attente, la gestion de l'expiration du cache sans se fier aux en-têtes du serveur, etc.
• RoboSpice fait plus en dehors du fil UI : volley va désérialiser vos POJOs sur le fil principal, ce qui est horrible à mon avis. Avec RS, votre application sera plus réactive.
• En termes de vitesse, nous avons définitivement besoin de mesures. RS est maintenant très rapide, mais nous n'avons toujours pas de chiffres à mettre ici. Volley devrait théoriquement être un peu plus rapide, mais RS est désormais massivement parallèle... qui sait ?
• RoboSpice offre une large gamme de compatibilité avec des extensions. Vous pouvez l'utiliser avec okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android... Pas mal. Volley peut être utilisé avec ok http et utilise gson. c'est tout.
• Volley offre plus de sucreries pour l'interface utilisateur que RS. Volley propose NetworkImageView, RS propose un adaptateur spicelist. En termes de fonctionnalité, ce n'est pas si loin, mais je pense que Volley est plus avancé sur ce sujet.
• Plus de 200 bugs ont été résolus dans RoboSpice depuis sa sortie initiale. C'est plutôt robuste et largement utilisé en production. Volley est moins mature mais sa base d'utilisateurs devrait croître rapidement (effet Google).
• RoboSpice est disponible sur maven central. Volley est difficile à trouver ;)

Answer 4

Client HTTP asynchrone bouclej vs. Volley

Les spécificités de mon projet sont de petites demandes HTTP REST, toutes les 1 à 5 minutes.

J'utilise un client HTTP asynchrone (1.4.1) depuis longtemps. Les performances sont meilleures que l'utilisation du client HTTP Apache vanille ou d'une connexion URL HTTP. Quoi qu'il en soit, la nouvelle version de la bibliothèque ne fonctionne pas pour moi : l'exception d'interruption de la chaîne de rappels de la bibliothèque.

En lisant toutes les réponses, cela m'a motivé à essayer quelque chose de nouveau. J'ai choisi la bibliothèque HTTP Volley.

Après l'avoir utilisé pendant un certain temps, même sans tests, je vois clairement que le temps de réponse est réduit à 1,5x, 2x Volley.

Peut-être que Retrofit est meilleur qu'un client HTTP asynchrone ? Je dois essayer. Mais je suis sûr que Volley n'est pas pour moi.

Answer 5

Juste pour ajouter un peu à la discussion d'après mon expérience de travail avec Volley :

1. Volley ne gère pas du tout le streaming des téléchargements ou des téléversements. C'est-à-dire que l'ensemble du corps de la requête doit être en mémoire et vous ne pouvez pas utiliser un OutputStream pour écrire le corps de la requête sur la socket sous-jacente, ni un InputStream pour lire le corps de la réponse, comme le fait le HttpURLConnection de base. Ainsi, Volley est un mauvais choix pour téléverser ou télécharger de gros fichiers. Vos requêtes et réponses doivent être petites. C'est l'une des plus grandes limitations de Volley que j'ai rencontrée personnellement. Pour ce que ça vaut, OkHttp possède des interfaces pour travailler avec les flux.

2. Le manque de documentation officielle est agaçant, bien que j'aie pu contourner cela en lisant le code source, qui est assez facile à suivre. Ce qui est encore plus ennuyeux, c'est que, autant que je sache, Volley n'a pas de versions officielles et aucun artefact Maven ou Gradle, et donc le gérer en tant que dépendance devient plus un casse-tête que, disons, l'une des bibliothèques publiées par Square. Vous clonez simplement un dépôt, compilez un jar, et vous êtes seul. Vous recherchez une correction de bogue ? Téléchargez en espérant qu'elle soit là. Vous pourriez obtenir d'autres choses aussi ; cela ne sera pas documenté. À mon avis, cela signifie effectivement que Volley est une bibliothèque tierce non supportée, même si la base de code est raisonnablement active. Caveat emptor.

3. À titre de remarque, avoir le Content-Type lié à la classe/au type de requête (JsonObjectRequest, ImageRequest, etc.) est un peu maladroit et réduit la flexibilité du code appelant, car vous êtes lié à la hiérarchie des types de requête existante de Volley. J'aime la simplicité de simplement définir Content-Type comme un en-tête comme pour tout autre (ne faites pas ça avec Volley, d'ailleurs ; vous vous retrouverez avec deux en-têtes Content-Type!). C'est juste mon opinion personnelle, cependant, et cela peut être contourné.

Cela ne signifie pas que Volley n'a pas quelques fonctionnalités utiles. Il en a certainement. Des politiques de réessai facilement personnalisables, la mise en cache transparente, une API d'annulation et la prise en charge de la planification des requêtes et des connexions simultanées sont des fonctionnalités géniales. Il faut juste savoir que ce n'est pas destiné à tous les cas d'utilisation HTTP (voir point 1 ci-dessus), et qu'il y a quelques casse-têtes impliqués dans la mise de Volley en production dans votre application (point 2).