Solución:
Espero que alguien pueda proporcionar algunos ejemplos concretos de los mejores casos de uso para cada uno.
Utilice Retrofit si se está comunicando con un servicio web. Utilice la biblioteca de pares Picasso si está descargando imágenes. Utilice OkHTTP si necesita realizar operaciones HTTP que se encuentran fuera de Retrofit / Picasso.
Volley compite aproximadamente con Retrofit + Picasso. En el lado positivo, es una biblioteca. En el lado negativo, es uno indocumentado, una biblioteca sin soporte, “arroje el código por encima de la pared y haga una presentación de E | S en él”.
EDITAR: Volley ahora es oficialmente compatible con Google. Por favor, consulte la Guía para desarrolladores de Google.
Por lo que he leído, parece que OkHTTP es el más robusto de los 3
Retrofit utiliza OkHTTP automáticamente si está disponible. Hay un Gist de Jake Wharton que conecta a Volley con OkHTTP.
y podría manejar los requisitos de este proyecto (mencionado anteriormente).
Probablemente no utilizará ninguno de ellos para la “descarga continua de audio y video”, según la definición convencional de “transmisión continua”. En cambio, el marco de medios de Android manejará esas solicitudes HTTP por usted.
Dicho esto, si va a intentar hacer su propia transmisión basada en HTTP, OkHTTP debería manejar ese escenario; No recuerdo lo bien que Volley manejaría ese escenario. Ni Retrofit ni Picasso están diseñados para eso.
Mirando la perspectiva de Volley, aquí hay algunas ventajas para su requerimiento:
Volley, por un lado, está totalmente enfocado en manejar pequeñas solicitudes HTTP individuales. Entonces, si el manejo de su solicitud HTTP tiene algunas peculiaridades, Volley probablemente tenga un gancho para usted. Si, por otro lado, tiene una peculiaridad en el manejo de su imagen, el único gancho real que tiene es ImageCache. “¡No es nada, pero tampoco es mucho!”. pero tiene más otras ventajas, como una vez que define sus solicitudes, usarlas desde dentro de un fragmento o actividad es indoloro a diferencia de AsyncTasks paralelas
Pros y contras de Volley:
Entonces, ¿qué tiene de bueno Volley?
-
La parte de la red no es solo para imágenes. La volea está destinada a ser una parte integral de tu back-end. Para un proyecto nuevo basado en un simple servicio REST, esto podría ser una gran victoria.
-
NetworkImageView es más agresivo con la limpieza de solicitudes que Picasso y más conservador en sus patrones de uso de GC. NetworkImageView se basa exclusivamente en referencias de memoria sólidas y limpia todos los datos de la solicitud tan pronto como se realiza una nueva solicitud para un ImageView, o tan pronto como ese ImageView se mueve fuera de la pantalla.
-
Rendimiento. Esta publicación no evaluará esta afirmación, pero claramente se han cuidado de ser juiciosos en sus patrones de uso de la memoria. Volley también hace un esfuerzo por agrupar las devoluciones de llamada al hilo principal para reducir el cambio de contexto.
-
Al parecer, Volley también tiene futuro. Consulte RequestFuture si está interesado.
-
Si se trata de imágenes comprimidas de alta resolución, Volley es la única solución aquí que funciona bien.
-
Volley se puede utilizar con Okhttp (la nueva versión de Okhttp es compatible con NIO para un mejor rendimiento)
-
Volley juega bien con el ciclo de vida de la actividad.
Problemas con la volea:
Dado que Volley es nuevo, pocas cosas aún no son compatibles, pero está arreglado.
-
Solicitudes de varias partes (Solución: https://github.com/vinaysshenoy/enhanced-volley)
-
El código de estado 201 se toma como un error, el código de estado de 200 a 207 ahora son respuestas exitosas (solucionado: https://github.com/Vinayrraj/CustomVolley)
Actualizar: en la última versión de Google Volley, el error de códigos de estado 2XX es reparado ahora ¡Gracias a Ficus Kirkpatrick!
-
está menos documentado, pero muchas de las personas están apoyando volley en github, se puede encontrar documentación similar a java aquí. En el sitio web para desarrolladores de Android, puede encontrar una guía para la transmisión de datos de red mediante Volley. Y el código fuente de volley se puede encontrar en Google Git
-
Para resolver / cambiar la Política de redireccionamiento de Volley Framework, use Volley con OkHTTP (CommonsWare mencionado anteriormente)
También puedes leer esto Comparando la carga de imágenes de Volley con Picasso
Modernización:
Es lanzado por Square, esto ofrece API REST muy fáciles de usar (Actualización: ¡Voila! Con soporte NIO)
Ventajas de la modificación:
-
En comparación con Volley, el código de la API REST de Retrofit es breve, proporciona una excelente documentación de la API y tiene un buen soporte en las comunidades. Es muy fácil de agregar a los proyectos.
-
Podemos usarlo con cualquier biblioteca de serialización, con manejo de errores.
Actualizar:
– Hay muchos cambios muy buenos en Retrofit 2.0.0-beta2
- la versión 1.6 de Retrofit con OkHttp 2.0 ahora depende de Okio apoyar java.io y java.nio lo que hace que sea mucho más fácil acceder, almacenar y procesar sus datos utilizando ByteString y Buffer hacer algunas cosas inteligentes para ahorrar CPU y memoria. (FYI: ¡Esto me recuerda a la biblioteca OIN de Koush con soporte NIO!)
Nosotros podemos usar Reequipamiento junto con RxJava para combinar y encadenar llamadas REST usando rxObservables para evitar cadenas de devolución de llamada feas (¡para evitar el infierno de devolución de llamada!).
Contras de Retrofit para la versión 1.6:
-
La funcionalidad de manejo de errores relacionados con la memoria no es buena (en versiones anteriores de Retrofit / OkHttp), no estoy seguro de si se ha mejorado con el soporte Okio con Java NIO.
-
La asistencia mínima para subprocesos puede resultar en un infierno de llamadas si lo usamos de manera incorrecta.
(Todos los inconvenientes anteriores se han resuelto en la nueva versión de Retrofit 2.0 beta)
================================================ ======================
Actualizar:
Pruebas de rendimiento de Android Async vs Volley vs Retrofit (milisegundos, un valor más bajo es mejor):
(Para su información, la información anterior de Retrofit Benchmarks mejorará con la compatibilidad con java NIO porque la nueva versión de OKhttp depende de la biblioteca NIO Okio)
En las tres pruebas con diferentes repeticiones (1 – 25 veces), Volley fue entre un 50% y un 75% más rápido. La actualización se registró de un 50% a un 90% más rápido que AsyncTasks, alcanzando el mismo punto final la misma cantidad de veces. En el conjunto de pruebas de Dashboard, esto se tradujo en cargar / analizar los datos varios segundos más rápido. Esa es una enorme diferencia en el mundo real. Para que las pruebas sean justas, los tiempos para AsyncTasks / Volley incluyeron el análisis JSON, ya que Retrofit lo hace automáticamente.
¡RetroFit gana en la prueba de referencia!
Al final, decidimos optar por Retrofit para nuestra aplicación. No solo es ridículamente rápido, sino que encaja bastante bien con nuestra arquitectura existente. Pudimos crear una interfaz de devolución de llamada principal que realiza automáticamente el manejo de errores, el almacenamiento en caché y la paginación con poco o ningún esfuerzo para nuestras API. Para fusionarnos en Retrofit, tuvimos que cambiar el nombre de nuestras variables para que nuestros modelos fueran compatibles con GSON, escribir algunas interfaces simples, eliminar funciones de la API anterior y modificar nuestros fragmentos para no usar AsyncTasks. Ahora que tenemos algunos fragmentos completamente convertidos, es bastante sencillo. Hubo algunos dolores de crecimiento y problemas que tuvimos que superar, pero en general todo salió bien. Al principio, nos encontramos con algunos problemas / errores técnicos, pero Square tiene una fantástica comunidad de Google+ que pudo ayudarnos a superarlo.
¡¿Cuándo usar Volley ?!
¡Podemos usar Volley cuando necesitamos cargar imágenes y consumir API REST! ¡Se necesita un sistema de cola de llamadas de red para muchas solicitudes n / w al mismo tiempo! ¡También Volley tiene un mejor manejo de errores relacionados con la memoria que Retrofit!
OkHttp se puede utilizar con Volley, usos de retrofit OkHttp ¡por defecto! Tiene SPDY soporte, agrupación de conexiones, almacenamiento en caché de disco, compresión transparente. Recientemente, tiene algo de soporte de java NIO con Okio Biblioteca.
Fuente, crédito: voleibol vs retroadaptación por el Sr. Josh Ruesch
Nota: Acerca de la transmisión depende del tipo de transmisión que desee, como RTSP / RTCP.
RoboSpice vs. Voleo
De https://groups.google.com/forum/#!topic/robospice/QwVCfY_glOQ
- RoboSpice (RS) se basa en servicios y es más respetuoso con la filosofía de Android que Volley. Volley se basa en subprocesos y esta no es la forma en que debe realizarse el procesamiento en segundo plano en Android. En última instancia, puede investigar ambas bibliotecas y descubrir que son bastante similares, pero nuestra forma de hacer el procesamiento en segundo plano está más orientada a Android, nos permite, por ejemplo, decirles a los usuarios que RS en realidad está haciendo algo en segundo plano, lo que sería difícil para la volea (en realidad no lo es en absoluto).
- RoboSpice y volley ofrecen características interesantes como priorización, políticas de reintento y cancelación de solicitudes. Pero RS ofrece más: un almacenamiento en caché más avanzado y eso es grande, con administración de caché, agregación de solicitudes, más funciones como volver a conectarse a una solicitud pendiente, lidiar con la caducidad de la caché sin depender de los encabezados del servidor, etc.
- RoboSpice hace más fuera del subproceso de la interfaz de usuario: volley deserializará tus POJO en el subproceso principal, lo cual es horrible en mi opinión. Con RS, su aplicación responderá mejor.
- En términos de velocidad, definitivamente necesitamos métricas. RS se ha vuelto súper rápido ahora, pero todavía no tenemos una cifra que poner aquí. Teóricamente, la volea debería ser un poco más rápida, pero RS ahora es enormemente paralelo … ¿quién sabe?
- RoboSpice ofrece una amplia gama de compatibilidad con extensiones. Puede usarlo con okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android … Bastante. Volley se puede usar con ok http y usa gson. eso es todo.
- Volley ofrece más azúcar UI que RS. Volley proporciona NetworkImageView, RS proporciona un adaptador de lista de deseos. En términos de características, no está tan lejos, pero creo que Volley está más avanzado en este tema.
- Se han resuelto más de 200 errores en RoboSpice desde su lanzamiento inicial. Es bastante robusto y se usa mucho en producción. Volley es menos maduro, pero su base de usuarios debería crecer rápidamente (efecto Google).
- RoboSpice está disponible en maven central. Volley es difícil de encontrar;)