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

Pregunta en dos partes de un desarrollador de iOS que está aprendiendo Android, trabajando en un proyecto de Android que hará una variedad de solicitudes de JSON a la imagen para la descarga de audio y video:

1. En iOS, he usado el proyecto AFNetworking ampliamente. ¿Hay una biblioteca equivalente para Android?

2. He leído sobre OkHTTP y Retrofit by Square, así como sobre Volley, pero todavía no tengo experiencia desarrollando con ellos. Espero que alguien pueda proporcionar algunos ejemplos concretos de los mejores casos de uso para cada uno. Por lo que he leído, parece que OkHTTP es el más robusto de los tres, y podría manejar los requisitos de este proyecto (mencionado anteriormente).

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. Use la biblioteca de pares Picasso si está descargando imágenes. Use 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 una biblioteca indocumentada, no admitida, "arroje el código sobre la pared y haga una presentación de I | O en él".

EDITAR - Volley ahora es oficialmente compatible con Google. 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

La actualización utiliza OkHTTP automáticamente si está disponible. Hay un Gist de Jake Wharton que conecta Volley a OkHTTP.

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

Probablemente no utilizará ninguno de ellos para la "descarga de transmisión de audio y video", según la definición convencional de "transmisión". 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 qué tan bien 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 su manejo de solicitudes HTTP tiene algunas peculiaridades, Volley probablemente tiene un enganche 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 defina sus solicitudes, usarlas desde 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 redes no es solo para imágenes. Volley está destinado a ser una parte integral de su back-end. Para un proyecto nuevo basado en un servicio REST simple, esto podría ser una gran victoria.

• NetworkImageView es más agresivo con respecto a la limpieza de solicitudes que Picasso, y más conservador en sus patrones de uso de GC. NetworkImageView se basa exclusivamente en fuertes referencias de memoria y limpia todos los datos de solicitud tan pronto como se realiza una nueva solicitud para un ImageView, o tan pronto como ImageView se mueve fuera de la pantalla.

• Actuación. Esta publicación no evaluará esta afirmación, pero claramente se han cuidado de ser juiciosos en sus patrones de uso de memoria. Volley también hace un esfuerzo para realizar devoluciones de llamadas por lotes al hilo principal para reducir el cambio de contexto.

• Al parecer, Volley también tiene futuros. Echa un vistazo a RequestFuture si estás 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 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:
dado que Volley es nuevo, todavía 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 Google Volley, el error de los 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, aquí se puede encontrar documentación similar a Java . En el sitio web para desarrolladores de Android, puede encontrar una guía para la transmisión de datos de red con Volley . Y el código fuente de voley se puede encontrar en Google Git

4. Para resolver / cambiar la Política de redireccionamiento de Volley Framework, use Volley con OkHTTP (CommonsWare mencionado anteriormente)

También puedes leer esta imagen que compara la carga de Volley con Picasso

Retrofit:

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 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 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 reequipamiento con OkHttp 2.0 depende ahora de Okio al apoyo java.io y java.nio que hace que sea mucho más fácil de acceder, almacenar y procesar los datos mediante ByteString y Buffer de hacer algunas cosas inteligentes para ahorrar la CPU y la memoria. (FYI: ¡Esto me recuerda a la biblioteca OIN de Koush con soporte NIO!) Podemos usar Retrofit 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 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 de subprocesos puede resultar en un infierno de devolución 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, menor valor es mejor):

(Para su información anterior, la información de los puntos de referencia de actualización 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 varias repeticiones (1 - 25 veces), Volley fue de 50% a 75% más rápido. La modernización registró un impresionante 50% a 90% más rápido que las AsyncTasks, alcanzando el mismo punto final la misma cantidad de veces. En el conjunto de pruebas del Tablero, 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 para AsyncTasks / Volley incluyeron el análisis JSON como Retrofit lo hace por usted automáticamente.

RetroFit gana en la prueba de referencia!

Al final, decidimos utilizar Retrofit para nuestra aplicación. No solo es ridículamente rápido, sino que combina 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 indoloro. Hubo algunos dolores de crecimiento y problemas que tuvimos que superar, pero en general todo salió bien. Al principio, nos encontramos con algunos problemas técnicos / errores, pero Square tiene una fantástica comunidad de Google+ que pudo ayudarnos a superarlo.

¿Cuándo usar Volley?

¡Podemos usar Volley cuando necesitemos cargar imágenes, así como consumir API REST! ¡también Volley tiene mejor manejo de errores relacionados con la memoria que Retrofit!

OkHttp se puede usar con Volley, Retrofit usa OkHttp de forma predeterminada. Tiene soporte SPDY , agrupación de conexiones, almacenamiento en caché de disco, compresión transparente. Recientemente, obtuvo cierto soporte 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) está basado en el servicio y es más respetuoso de la filosofía de Android que Volley. Volley está basado en subprocesos y esta no es la forma en que el procesamiento en segundo plano debería tener lugar en Android. En última instancia, puede desenterrar ambas bibliotecas y descubrir que son bastante similares, pero nuestra forma de procesar en segundo plano está más orientada a Android, nos permite, por ejemplo, decirles a los usuarios que RS está haciendo algo en segundo plano, lo que sería difícil para volea (en realidad no lo hace en absoluto).
• RoboSpice y volley ofrecen buenas características como priorización, políticas de reintento, solicitud de cancelación. Pero RS ofrece más: un almacenamiento en caché más avanzado y que es grande, con gestión de caché, agregación de solicitudes, más características como volver a conectar a una solicitud pendiente, lidiar con la caducidad de la caché sin depender de los encabezados del servidor, etc.
• RoboSpice hace más cosas fuera de UI Thread: volley deserializará tus POJOs en el hilo principal, lo cual es horrible para mí. Con RS su 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 aún no tenemos figura para poner aquí. En teoría, el voley debería ser un poco más rápido, pero RS ahora es masivamente paralelo ... ¿quién sabe?
• RoboSpice ofrece un amplio rango 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.
• Volley ofrece más azúcar UI que RS. Volley proporciona NetworkImageView, RS proporciona un adaptador de lista de spicel. 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 la producción. Volley es menos maduro, pero su base de usuarios debería estar creciendo rápidamente (efecto Google).
• RoboSpice está disponible en maven central. Volley es difícil de encontrar;)

AFNetworking para Android:

Rápida red de Android está aquí

Fast Android Networking Library admite todos los tipos de solicitud 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 carga multiparte)

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

Fast Android Networking Library admite la configuración de prioridad para cualquier solicitud (BAJA, MEDIA, ALTA, INMEDIATA)

Fast Android Networking Library es compatible con RxJava

Como utiliza OkHttp como capa de red, admite:

Fast Android Networking Library admite HTTP / 2, permite que todas las solicitudes al mismo host compartan un socket

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

GZIP transparente reduce los tamaños de descarga

Fast Android Networking Library admite el almacenamiento en caché de respuestas que evita la red por completo para las solicitudes repetidas

Gracias: la biblioteca fue creada por mí.

Cliente HTTP asíncrono loopj vs.Volley

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

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

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

Después de usarlo durante un tiempo, incluso sin pruebas, veo claramente que el tiempo de respuesta se ha reducido a 1.5x, 2x Volley.

¿Quizás Retrofit es mejor que un cliente HTTP asíncrono? Necesito probarlo. Pero estoy seguro de que Volley no es para 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 puede usar un OutputStreampara escribir el cuerpo de la solicitud en el socket subyacente, ni puede usar un InputStreampara leer el cuerpo de la respuesta, como lo HttpURLConnectionhace básico . Entonces, Volley es una mala elección para cargar o descargar archivos grandes. 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 solucionarlo 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 de lanzamiento oficiales ni artefactos de Maven o Gradle, y por lo tanto, manejarlo como una dependencia se vuelve más dolor de cabeza que, por ejemplo, cualquiera de las bibliotecas que Square ha lanzado . Simplemente clonas un repositorio, construyes un frasco y estás solo. Buscando una corrección de errores? Busca y espera que esté allí. También puede obtener otras cosas; No será documentado. En mi opinión, esto significa efectivamente que Volley es una biblioteca de terceros no compatible, aunque la base de código esté razonablemente activa. Advertencia emptor.

3. Como nit, tener el Tipo de contenido vinculado al tipo de clase / solicitud (JsonObjectRequest, ImageRequest, etc.) es algo 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 configurar Content-Type como un encabezado como cualquier otro (por cierto, no hagas esto con Volley; ¡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 características útiles. Ciertamente lo hace. Políticas de reintento fácilmente personalizables, almacenamiento en caché transparente, una API de cancelación y soporte para la programación de solicitudes y conexiones concurrentes son excelentes características. Solo sepa que no está destinado a todos los casos de uso de HTTP (consulte el elemento 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 encontré una lib llamada ion que aporta un poco más a la mesa.

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

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 LOG_TAG dijo ... para que Volley analice sus datos en un subproceso en segundo plano, debe subclasificar Request<YourClassName>como onResponsese llama al método en el subproceso principal y el análisis en el subproceso principal puede hacer que la interfaz de usuario se retrase si su 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 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 otra opción más: https://github.com/apptik/jus

• Es modular como Volley, pero más extendido y la documentación está mejorando, soportando diferentes pilas y convertidores HTTP listos para usar.
• Tiene un módulo para generar asignaciones de interfaz API del servidor como Retrofit
• También tiene soporte JavaRx

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