Comparación de las bibliotecas de redes de Android: OkHTTP, Retrofit y Volley

Espero que alguien pueda proporcionar algunos ejemplos concretos de los mejores casos de uso para cada uno.

Use Retrofit si se está comunicando con un servicio web. Utilice la biblioteca de pares Picasso si está descargando imágenes. Use OkHTTP si necesita hacer operaciones HTTP que se encuentran fuera de Retrofit / Picasso.

Volley casi compite con Retrofit + Picasso. En el lado positivo, es una biblioteca. En el lado negativo, se trata de una biblioteca no documentada, sin soporte, “arroje el código sobre la pared y haga una presentación I | O en ella”.

EDITAR – Volley ahora es oficialmente compatible con Google. Remítase a Google Developer Guide

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 una esencia de Jake Wharton que conecta Volley con OkHTTP.

y podría manejar los requisitos de este proyecto (mencionado anteriormente).

Probablemente no utilizará ninguno de ellos para “transmitir la descarga de audio y video”, según la definición convencional de “transmisión”. En cambio, el framework 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 debe manejar ese escenario; No recuerdo cuán bien manejaría Volley ese escenario. Ni Retrofit ni Picasso están diseñados para eso.

En cuanto a la perspectiva de Volley aquí hay algunas ventajas para su requerimiento:

Volley, por un lado, está totalmente enfocado en el manejo de pequeñas solicitudes HTTP individuales. Entonces, si su manejo de solicitudes HTTP tiene algunas peculiaridades, es probable que Volley tenga un gancho para usted. Si, por otro lado, tienes una peculiaridad en el manejo de tu imagen, el único gancho real que tienes es ImageCache . “No es nada, pero tampoco es mucho”. pero tiene más otras ventajas, como Una vez que defines tus solicitudes, usarlas desde dentro de un fragmento o actividad es indoloro a diferencia de las AsyncTasks paralelas

Pros y contras de Volley:

Entonces, ¿qué tiene de bueno Volley?

• La parte de la red no es solo para imágenes. Volley está destinado a ser una parte integral de su back-end. Para un nuevo proyecto basado en un simple servicio REST, esto podría ser una gran victoria.

• NetworkImageView es más agresivo en limpieza de solicitudes que Picasso y más conservador en sus patrones de uso de GC. NetworkImageView depende exclusivamente de fuertes referencias de memoria y limpia todos los datos de solicitud tan pronto como se hace una nueva solicitud para un ImageView, o tan pronto como ese ImageView se mueva fuera de pantalla.

• Actuación. Esta publicación no evaluará este reclamo, pero claramente han tenido cuidado de ser juiciosos en sus patrones de uso de memoria. Volley también hace un esfuerzo para devolver llamadas a la secuencia principal para reducir el cambio de contexto.

• Volley aparentemente 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 que funciona bien.

• Volley se puede usar con Okhttp (la nueva versión de Okhttp admite NIO para un mejor rendimiento)

• Volley juega bien con el ciclo de vida de la actividad.

Problemas con Volley:
Como Volley es nuevo, aún no se admiten algunas cosas, pero está solucionado.

1. Solicitudes de varias partes (Solución: https://github.com/vinaysshenoy/enhanced-volley )

2. el código de estado 201 se toma como un error, el código de estado de 200 a 207 son respuestas exitosas ahora. (Solucionado: https://github.com/Vinayrraj/CustomVolley )

   Actualización: en la última versión de la descarga de Google, el error de códigos de estado 2XX está solucionado ahora. ¡Gracias a Ficus Kirkpatrick!

3. está menos documentado pero muchas de las personas están apoyando la volea en github, la documentación de Java se puede encontrar aquí . En el sitio web para desarrolladores de Android, puede encontrar una guía para Transmitir datos de red usando Volley . Y el código fuente de Volley se puede encontrar en Google Git

4. Para resolver / cambiar la política de redirección de Volley Framework use Volley con OkHTTP (CommonsWare mencionado anteriormente)

También puedes leer esto Comparando la imagen de Volley cargando con Picasso

Retrofit:

Lanzado por Square , ofrece API REST muy fácil de usar (Actualización: Voila! Con soporte NIO)

Pros de la modificación:

• ¡Comparado con Volley, el código REST API de Retrofit es breve y proporciona una excelente documentación 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.

Actualización: – 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 para admitir java.io y java.nio, lo que hace que sea mucho más fácil acceder, almacenar y procesar sus datos usando ByteString y Buffer para hacer algunas cosas inteligentes para ahorrar CPU y memoria. (¡FYI: esto me recuerda la biblioteca OIN de Koush con soporte de NIO!) Podemos usar Retrofit junto con RxJava para combinar y encadenar llamadas REST usando rxObservables para evitar cadenas de callback feas (¡para evitar el infierno de callbacks!) .

Contras de Retrofit para la versión 1.6:

• La funcionalidad de manejo de errores relacionada con la memoria no es buena (en versiones anteriores de Retrofit / OkHttp) no estoy seguro si se ha mejorado con el soporte de Okio con Java NIO.

• La asistencia mínima para el enhebrado puede dar lugar a una llamada de auxilio si usamos esto de una manera incorrecta.

(Todos los inconvenientes anteriores se han resuelto en la nueva versión de Retrofit 2.0 beta)

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

Actualizar:

Los puntos de referencia de rendimiento de Android Async vs Volley vs Retrofit (milisegundos, menor valor es mejor):

(FYI arriba La información de Retrofit Benchmarks mejorará con el soporte de java NIO porque la nueva versión de OKhttp depende de la biblioteca NIO Okio)

En las tres pruebas con repeticiones variables (1 – 25 veces), Volley fue entre 50% y 75% más rápido. La actualización se incrementó entre un 50% y un 90% más rápido que las 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 gran diferencia en el mundo real. Para que las pruebas sean justas, los tiempos de AsyncTasks / Volley incluyeron el análisis JSON, ya que Retrofit lo hace automáticamente.

¡RetroFit gana en la prueba de referencia!

Al final, decidimos ir con Retrofit para nuestra aplicación. No solo es ridículamente rápido, sino que se adapta bastante bien a nuestra architecture existente. Pudimos hacer una interfaz de callback principal que automáticamente realiza 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 hacer que nuestros modelos sean compatibles con GSON, escribir algunas interfaces simples, eliminar funciones de la antigua API 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 se desarrolló sin problemas. Al principio, nos topamos con algunos problemas / errores técnicos, pero Square tiene una fantástica comunidad de Google+ que nos ayudó a superarlo.

¿Cuándo usar Volley?

¡Podemos usar Volley cuando necesitamos cargar imágenes y consumir API REST! ​​¡El sistema de cola de llamadas de red es necesario 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 usar con Volley, Retrofit usa OkHttp por defecto. ¡Tiene soporte SPDY , agrupación de conexiones, almacenamiento en caché de disco, compresión transparente! Recientemente, tiene algo de apoyo de java NIO con la biblioteca Okio .

Fuente, crédito: volley-vs-retrofit 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

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

• RoboSpice (RS) se basa en el servicio y es más respetuoso de la filosofía de Android que Volley. Volley está basado en subprocesos y este no es el proceso de fondo que debe tener lugar en Android. En última instancia, puedes desenterrar ambas bibliotecas y descubrir que son bastante similares, pero nuestra forma de procesar el fondo está más orientada a Android, nos permite, por ejemplo, decirles a los usuarios que RS está haciendo algo en segundo plano, que sería difícil para la volea (en realidad no lo hace en absoluto).
• RoboSpice y Volley ofrecen características agradables como priorización, políticas de rebash, cancelación de solicitud. Pero RS ofrece más: un almacenamiento en caché más avanzado y más grande, con administración de caché, agregación de solicitudes, más funciones como el replicing a una solicitud pendiente, lidiar con la caducidad de caché sin depender de los encabezados del servidor, etc.
• RoboSpice hace más fuera de UI Thread: voley deserializará tus POJOs en el hilo principal, lo cual es horrible para mi mente. Con RS tu aplicación será más receptiva.
• En términos de velocidad, definitivamente necesitamos métricas. RS se ha vuelto súper rápido ahora, pero todavía no tenemos la figura para poner aquí. Volley debería ser teóricamente un poco más rápido, pero RS ahora es masivamente paralelo … ¿quién sabe?
• RoboSpice ofrece un amplio rango de compatibilidad con extensiones. Puedes usarlo con okhttp, retrofit, omlite (beta), jackson, jackson2, gson, xml serializer, google http client, spring android … Mucho. Volley se puede usar con ok http y usa gson. Eso es.
• Volley ofrece más UI de azúcar que RS. Volley proporciona NetworkImageView, RS proporciona un adaptador de spicelist. En términos de características, no es 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 está menos maduro, pero su base de usuarios debería crecer rápidamente (efecto Google).
• RoboSpice está disponible en maven central. El voleo es difícil de encontrar;)

Async cliente HTTP loopj vs. Volley

Los detalles de mi proyecto son pequeñas solicitudes HTTP REST, cada 1-5 minutos.

Uso un cliente HTTP asincrónico (1.4.1) durante mucho tiempo. El rendimiento es mejor que usar el vanche Apache httpClient o una conexión URL HTTP. De todos modos, la nueva versión de la biblioteca no funciona para mí: biblioteca inter excepción cadena de corte de devoluciones de llamada.

Leer todas las respuestas me motivó a probar algo nuevo. He elegido la biblioteca Volley HTTP.

Después de usarlo por algún tiempo, incluso sin pruebas, veo claramente que el tiempo de respuesta ha bajado a 1.5x, 2x Volley.

Tal vez Retrofit es mejor que un cliente asincrónico HTTP? Necesito probarlo. Pero estoy seguro de que Volley no es para mí.

AFNetworking para Android:

La conexión rápida a Android está aquí

Fast Android Networking Library admite todos los tipos de solicitudes HTTP / HTTPS como GET, POST, DELETE, HEAD, PUT, PATCH

Fast Android Networking Library admite la descarga de cualquier tipo de archivo

Fast Android Networking Library admite la carga de cualquier tipo de archivo (admite la carga de varias partes)

Fast Android Networking Library admite la cancelación de una solicitud

Fast Android Networking Library admite establecer prioridad a cualquier solicitud (BAJO, MEDIANO, ALTO, INMEDIATO)

Fast Android Networking Library es compatible con RxJava

Como utiliza OkHttp como capa de red, admite:

Fast Android Networking Library es compatible con HTTP / 2 admite que todas las solicitudes al mismo host compartan un socket

Fast Android Networking Library utiliza la agrupación de conexiones que reduce la latencia de las solicitudes (si HTTP / 2 no está disponible)

El GZIP transparente reduce los tamaños de descarga

Fast Android Networking Library es compatible con el almacenamiento en caché de respuestas, lo que evita la red por completo para solicitudes repetidas

Gracias: la biblioteca es creada por mí

Solo para agregar un poco a la discusión de mi experiencia trabajando con Volley:

1. Volley no maneja las cargas o descargas de transmisión en ningún sentido. Es decir, todo el cuerpo de la solicitud debe estar en la memoria y no se puede usar un OutputStream para escribir el cuerpo de la solicitud en el socket subyacente, ni se puede usar un InputStream para leer el cuerpo de la respuesta, como HttpURLConnection hace HttpURLConnection básico. Entonces, Volley es una mala elección para cargar o descargar archivos de gran tamaño. Sus solicitudes y respuestas deben ser pequeñas. Esta es una de las mayores limitaciones de Volley que he encontrado personalmente. Por lo que vale, OkHttp tiene interfaces para trabajar con transmisiones.

2. La falta de documentación oficial es molesta, aunque he podido evitarlo leyendo el código fuente, que es bastante fácil de seguir. Lo que es más molesto es que, por lo que puedo decir, Volley no tiene versiones oficiales y ningún artefacto de Maven o Gradle, por lo que manejarlo como una dependencia se convierte en un dolor de cabeza más que, por ejemplo, cualquiera de las bibliotecas que Square ha lanzado. . Simplemente clona un repository, construye un contenedor y está solo. Buscando una solución de error? Trae y espera que esté allí. También puedes obtener otras cosas; no será documentado. En mi opinión, esto significa que Volley es una biblioteca de terceros sin soporte, a pesar de que la base de código es razonablemente activa. Caveat Emptor.

3. Como nit, tener el tipo de contenido vinculado al tipo de clase / solicitud (JsonObjectRequest, ImageRequest, etc.) es un poco incómodo y reduce un poco la flexibilidad del código de llamada, ya que está vinculado a la jerarquía de tipos de solicitud existente de Volley. Me gusta la sencillez de simplemente configurar Content-Type como un encabezado como cualquier otro (¡no hagas esto con Volley, por cierto, terminarás con dos encabezados Content-Type!). Sin embargo, esa es solo mi opinión personal, y se puede solucionar.

Eso no quiere decir que Volley no tenga algunas funciones útiles. Ciertamente lo hace Las políticas de rebash fácilmente personalizables, el almacenamiento en caché transparente, una API de cancelación y la compatibilidad con la progtwigción de solicitudes y las conexiones simultáneas son excelentes características. Solo tenga en cuenta que no está destinado a todos los casos de uso de HTTP (consulte el artículo 1 anterior), y que hay algunos dolores de cabeza involucrados en poner Volley en uso de producción en su aplicación (elemento 2).

Recientemente he encontrado una lib llamada ion que aporta un poco más a la mesa.

ion tiene soporte integrado para la descarga de imágenes integrado con ImageView, JSON (con la ayuda de GSON), archivos y un soporte de subprocesos UI muy útil.

Lo estoy usando en un nuevo proyecto y hasta ahora los resultados han sido buenos. Su uso es mucho más simple que Volley o Retrofit.

Agregando a la respuesta aceptada y lo que dijo LOG_TAG … para que Volley analice sus datos en un hilo de fondo debe subclase Request cuando se onResponse método onResponse en el hilo principal y el análisis en el hilo principal puede causar la IU retrasarse si tu respuesta es grande. Lea aquí sobre cómo hacer eso.

Retrofit 1.9.0 vs. RoboSpice

Estoy usando ambos en mi aplicación.

Robospice funciona más rápido que Retrofit cada vez que analizo la clase JSON anidada. Porque Spice Manger hará todo por ti. En Retrofit necesitas crear GsonConverter y deserializarlo.

Creé dos fragmentos en la misma actividad y llamé al mismo tiempo con dos mismos tipos de 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 

Y aún otra opción: https://github.com/apptik/jus

• Es modular como Volley, pero está mejorando la documentación y la extensión, ya que admite diferentes stacks y convertidores HTTP de forma inmediata.
• Tiene un módulo para generar asignaciones de interfaz API de servidor como Retrofit
• También tiene soporte para JavaRx

Y muchas otras funciones útiles como marcadores, transformadores, etc.