En regardant la perspective Volley, voici quelques avantages pour votre besoin:
Volley, d'une part, se concentre totalement sur la gestion de petites requêtes HTTP individuelles. Donc, si la gestion de vos requêtes HTTP a des bizarreries, Volley a probablement un crochet pour vous. Si, d'autre part, vous avez une bizarrerie dans la gestion de votre image, le seul vrai crochet que vous avez est ImageCache . "Ce n'est pas rien, mais ce n'est pas beaucoup!". mais il a plus d'autres avantages comme Une fois que vous définissez vos demandes, les utiliser à partir d'un fragment ou d'une activité est indolore contrairement aux AsyncTasks parallèles
Avantages et inconvénients de Volley:
Alors qu'est-ce qui est bien avec Volley?
La partie mise en réseau n'est pas seulement pour les images. Volley est destiné à faire 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 à propos du nettoyage des demandes que Picasso, et plus conservateur dans ses modèles d'utilisation de GC. NetworkImageView s'appuie exclusivement sur des références de mémoire solides et nettoie toutes les données de demande dès qu'une nouvelle demande est faite pour une ImageView, ou dès que cette ImageView passe hors écran.
Performance. Ce message n'évaluera pas cette affirmation, mais ils ont clairement pris soin d'être judicieux dans leurs modèles d'utilisation de la mémoire. Volley fait également un effort pour regrouper les rappels au thread principal afin de réduire le changement de contexte.
Volley a apparemment aussi un avenir. Consultez RequestFuture si vous êtes intéressé.
Si vous avez affaire à des images compressées à haute résolution, Volley est la seule solution ici qui fonctionne bien.
Volley peut être utilisé avec Okhttp (la nouvelle version d'Okhttp prend en charge NIO pour de meilleures performances)
Volley joue bien avec le cycle de vie de l'activité.
Problèmes avec Volley:
Étant donné que Volley est nouveau, peu de choses ne sont pas encore prises en charge, mais elles sont corrigées.
Demandes en plusieurs parties (solution: https://github.com/vinaysshenoy/enhanced-volley )
le code d'état 201 est considéré comme une erreur, les codes d'état de 200 à 207 sont maintenant des réponses réussies. (Correction: https://github.com/Vinayrraj/CustomVolley )
Mise à jour: dans la dernière version de Google Volley, le bug des codes d'état 2XX est maintenant corrigé ! Merci à Ficus Kirkpatrick!
c'est moins documenté mais beaucoup de gens soutiennent la volley dans github, la documentation de type java peut être trouvée ici . Sur le site Web des développeurs Android, vous pouvez trouver un guide pour la transmission de données réseau à l'aide de Volley . Et le code source de volley peut être trouvé sur Google Git
Pour résoudre / modifier la politique de redirection du cadre Volley, utilisez Volley avec OkHTTP ( CommonsWare mentionné ci-dessus)
Vous pouvez également lire le chargement de l'image de Comparaison de Volley avec Picasso
Rénovation:
Il est publié par Square , cela offre des API REST très faciles à utiliser (Mise à jour: Voila! Avec support NIO)
Avantages de Retrofit:
Comparé à Volley, le code API REST de Retrofit est bref et fournit une excellente documentation API et a un bon support dans les communautés! Il est très facile de l'ajouter aux projets.
Nous pouvons l'utiliser avec n'importe quelle bibliothèque de sérialisation, avec gestion des erreurs.
Mise à jour:
- Il y a beaucoup de très bons changements dans Retrofit 2.0.0-beta2
- la version 1.6 de Retrofit avec OkHttp 2.0 est désormais dépendante d' Okio pour prendre en charge java.io et java.nio, ce qui facilite l'accès, le stockage et le traitement de vos données à l'aide de ByteString et Buffer pour faire des choses intelligentes pour économiser le CPU et la mémoire. (Pour info: cela me rappelle la bibliothèque OIN de Koush avec prise en charge NIO!)
Nous pouvons utiliser Retrofit avec RxJava pour combiner et chaîner les appels REST à l'aide de rxObservables pour éviter les chaînes de rappel laides (pour éviter l'enfer de rappel !!) .
Inconvénients de Retrofit pour la version 1.6:
La fonctionnalité de gestion des erreurs liée à 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 le support Okio avec Java NIO.
Une assistance minimale au filetage peut entraîner un rappel de l'enfer si nous l'utilisons de manière incorrecte.
(Tous les inconvénients ci-dessus ont été résolus dans la nouvelle version de Retrofit 2.0 beta)
================================================== ======================
Mise à jour:
Android Async vs Volley vs Retrofit benchmarks de performance (millisecondes, une valeur inférieure est meilleure):
(Pour info ci-dessus, les informations sur les repères de mise à niveau 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 à 25 fois), Volley était de 50% à 75% plus rapide. La mise à niveau s'est effectuée à une vitesse impressionnante de 50% à 90% plus rapide que les AsyncTasks, atteignant le même point de terminaison le même nombre de fois. Dans la suite de tests Dashboard, cela s'est traduit par un chargement / analyse des données plusieurs secondes plus rapide. C'est une énorme différence dans le monde réel. Afin de rendre les tests équitables, les temps pour AsyncTasks / Volley incluaient l'analyse JSON car Retrofit le faisait automatiquement pour vous.
RetroFit remporte le test de référence!
Finalement, nous avons décidé de choisir Retrofit pour notre application. Non seulement il est ridiculement rapide, mais il correspond assez bien à notre architecture existante. Nous avons pu créer une interface de rappel parent qui effectue automatiquement la gestion des erreurs, la mise en cache et la pagination avec peu ou pas d'effort pour nos API. Afin de fusionner dans Retrofit, nous avons dû renommer nos variables pour rendre nos modèles conformes à GSON, écrire quelques interfaces simples, supprimer des fonctions de l'ancienne API et modifier nos fragments pour ne pas utiliser AsyncTasks. Maintenant que nous avons converti quelques fragments, c'est assez indolore. Il y a eu des difficultés et des problèmes croissants que nous avons dû surmonter, mais dans l'ensemble, tout s'est bien passé. Au début, nous avons rencontré quelques problèmes techniques / bugs, mais Square a une fantastique communauté Google+ qui a pu nous aider à le résoudre.
Quand utiliser Volley?!
Nous pouvons utiliser Volley lorsque nous avons besoin de charger des images ainsi que de consommer des API REST !, le système de mise en file d'attente des appels réseau est nécessaire pour de nombreuses demandes n / w en même temps! Volley a également une meilleure gestion des erreurs liées à la mémoire que Retrofit!
OkHttp peut être utilisé avec Volley, Retrofit utilise OkHttp par défaut! Il a un support SPDY , un pool de connexions, une mise en cache disque, une compression transparente! Récemment, il a obtenu un certain support de java NIO avec Okio bibliothèque .
Source, crédit: volley-vs-retrofit par M. Josh Ruesch
Remarque: À propos du streaming, cela dépend du type de streaming que vous souhaitez, comme RTSP / RTCP.