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

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

Utilice Retrofit si se está comunicando con un servicio Web. Utilice la biblioteca peer Picasso si está descargando imágenes. Utilice OkHTTP si necesita realizar operaciones HTTP que se encuentren fuera de Retrofit / Picasso.

Volley compite con Rustfit + Picasso. En el lado positivo, es una biblioteca. En el lado negativo, es uno indocumentado, un sin soporte, "lanzar el código sobre la pared y hacer una presentación I | O en ella" de la biblioteca.

EDIT – Volley ahora es oficialmente apoyado por Google. Por favor, consulte Google Developer Guide

De lo que he leído, parece que OkHTTP es el más robusto de los 3

Retrofit usa 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 arriba).

Probablemente no usará ninguno de ellos para "streaming de descarga de audio y video", por la definición convencional de "streaming". En su lugar, la infraestructura de medios de Android se encargará de las solicitudes HTTP para usted.

Dicho esto, si va a intentar hacer su propia transmisión basada en HTTP, OkHTTP debe 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í es una ventaja para su requisito:

Volley, por otro lado, está totalmente centrado en el manejo de pequeñas peticiones HTTP individuales. Así que si su solicitud HTTP tiene algunas peculiaridades, Volley probablemente tiene un gancho para usted. Si, por otro lado, tiene un capricho en su manejo de imágenes, el único gancho real que tiene es ImageCache . "No es nada, pero no es mucho!". Pero tiene más otras ventajas como Una vez que usted define sus peticiones, usarlas desde dentro de un fragmento o actividad es indolora a diferencia de AsyncTasks paralelo

Pros y contras de Volley:

Entonces, ¿qué hay de bueno en Volley?

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

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

• Actuación. Este post no evaluará esta afirmación, pero claramente han tomado cierto cuidado para ser juiciosos en sus patrones de uso de la memoria. Volley también hace un esfuerzo para batch callbacks al hilo principal para reducir el cambio de contexto.

• Volley aparentemente tiene futuros, también. 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 utilizar con Okhttp (Nuevo ver de Okhttp soporta NIO para un mejor rendimiento)

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

Problemas con Volley:
Ya que Volley es nuevo, algunas cosas no son compatibles todavía, pero está arreglado.

1. Solicitud de varias partes ( 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 correctas ahora. (Corregido: https://github.com/Vinayrraj/CustomVolley )

   Actualización: en la última versión Google volley el bug de códigos de estado 2XX se arregla ahora! Gracias a Ficus Kirkpatrick!

3. Es menos documentado, pero muchas de las personas que apoyan esta volea en github, java como la documentación se puede encontrar aquí . En el sitio web para desarrolladores de Android, puede encontrar guía para Transmitir datos de red utilizando Volley . Y el código fuente de volley 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 esto Comparando Volley's loading de imágenes con Picasso

Retrofit:

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

Pros de Retrofit:

• En comparación con Volley en este API de REST, el código es breve y proporciona una excelente documentación API y tiene un buen soporte en las comunidades. Muy fácil de agregar en los proyectos.

• Podemos utilizar con cualquier biblioteca de serialización, con el manejo de errores.

Actualización: – Hay un montón de cambios muy buenos en Retrofit 2.0.0-beta2

• La versión 1.6 de Retrofit con OkHttp 2.0 depende ahora de Okio para soportar java.io y java.nio para 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. Podemos usar Retrofit junto con RxJava para combinar y encadenar las llamadas REST usando rxObservables para evitar las 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:

• El manejo de errores de memoria no es bueno (en versiones anteriores de Retrofit / OkHttp) no está seguro de que haya mejorado con el soporte de Okio con Java NIO.

• La asistencia mínima de roscado puede resultar devolviendo el infierno si usamos esto de una manera incorrecta.

(Todos los anteriores Cons resueltos en la nueva versión de Retrofit 2.0 beta)

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

Actualizar:

Android Async vs Volley vs Retrofit benchmarks de rendimiento (milisegundos, valor más bajo es mejor):

(FYI por encima de Retrofit Benchmarks info se mejorará con el soporte NIO de Java porque ahora el nuevo OKhttp depende de la biblioteca NIO Okio)

En las tres pruebas con repeticiones variables (1 – 25 veces), Volley fue en cualquier lugar de 50% a 75% más rápido. La retroactivación registró un impresionante 50% a 90% más rápido que el AsyncTasks, golpeando el mismo punto final el mismo número de veces. En la suite de pruebas 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 hacer las pruebas justas, los tiempos para AsyncTasks / Volley incluyeron el análisis de JSON como Retrofit lo hace automáticamente.

RetroFit gana en la prueba de referencia!

Al final, decidimos ir con Retrofit para nuestra aplicación. No sólo es ridículamente rápido, sino que se ajusta muy bien con nuestra arquitectura existente. Hemos sido capaces de hacer una interfaz de devolución de llamada que maneja automáticamente la función de error, almacenamiento en caché y paginación con poco o ningún esfuerzo para nuestras API. Para fusionar en Retrofit, tenemos que cambiar el nombre de nuestras variables para que nuestros modelos GSON cumplan, escribir unas cuantas interfaces simples, eliminar funciones de la API antigua y modificar nuestros fragmentos para no usar AsyncTasks. Ahora que tenemos algunos fragmentos completamente convertidos, es bastante indoloro. Había algunos dolores de crecimiento y problemas que tuvimos que superar, pero en general se desarrolló sin problemas. Al principio, nos topamos con algunos problemas técnicos / errores, pero Square tiene una fantástica comunidad de Google+ que nos ayudó a través de ella.

¿Cuándo usar Volley ?!

Podemos usar Volley cuando necesitamos tanto la carga de la imagen y la API REST es necesario !, sistema de colas de llamadas de red es necesario para muchos n / w solicitud al mismo tiempo! También Volley tienen mejor manejo de error de memoria que Retrofit!

OkHttp se puede utilizar con Volley, en Retrofit se utiliza OkHttp por defecto! Tiene soporte SPDY , agrupación de conexiones, caché de disco, compresión transparente! Recientemente, tiene cierto apoyo de java NIO con la biblioteca de Okio .

Fuente, crédito: volley-vs-retrofit por el Sr. Josh Ruesch

Nota: El streaming depende del tipo de streaming que desees como RTSP / RTCP.

RoboSpice vs. Voleo

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

• RoboSpice (RS) es un servicio basado y más respetuoso de la filosofía de Android que Volley. Volley está basado en hilos y este no es el modo en que el procesamiento de fondo debería tener lugar en Android. En última instancia, puede buscar ambas libs y encontrar que son bastante similares, pero nuestra forma de procesar en segundo plano es más orientada a Android, que nos permite, por ejemplo, decir a los usuarios que RS está haciendo algo en segundo plano, lo que sería Difícil de volley (en realidad no es en absoluto).
• RoboSpice y volley ofrecen características agradables como priorización, políticas de reintento, cancelación de solicitudes. Pero RS ofrece más: un caché más avanzado, que es muy grande, con administración de caché, agregación de solicitudes, más funciones como la replugación de una solicitud pendiente, el manejo de la caducidad del caché sin depender de los encabezados del servidor, etc.
• RoboSpice hace más fuera de UI Tema: volea deserializará sus POJOs en el hilo principal, lo cual es horrible para mi mente. Con RS su aplicación será más sensible.
• En términos de velocidad, definitivamente necesitamos métricas. RS ha llegado muy rápido ahora, pero todavía no tenemos cifra para poner aquí. Volley teóricamente debería ser un poco más rápido, pero RS es ahora masivamente paralelo … ¿quién sabe?
• RoboSpice ofrece un amplio rango de compatibilidad con extensiones. Usted puede utilizarlo con okhttp, retrofit, ormlite (beta), jackson, jackson2, gson, serializador xml, google cliente http, primavera android … Mucho. Volley se puede utilizar con ok http y utiliza gson. Eso es.
• Volley ofrece más azúcar de la interfaz de usuario que RS. Volley proporciona NetworkImageView, RS proporciona un adaptador de spicelist. En términos de característica no es hasta ahora, pero creo que Volley es más avanzado en este tema.
• Más de 200 errores han sido resueltos en RoboSpice desde su lanzamiento inicial. Es bastante robusto y muy utilizado en la producción. Volley es menos maduro, pero su base de usuarios debe estar creciendo rápidamente (efecto de Google).
• RoboSpice está disponible en maven central. Volley es difícil de encontrar;)

Async cliente HTTP loopj vs Volley

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

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

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

Después de usarlo durante algún tiempo, incluso sin pruebas, veo claramente que el tiempo de respuesta es de 1,5x, 2x Volley.

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

AFNetworking para Android:

Rápido Android Networking 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 es compatible con la descarga de cualquier tipo de archivo

Fast Android Networking Library admite la carga de cualquier tipo de archivo (admite la carga múltiple)

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

Fast Android Networking Library admite la prioridad de establecer cualquier solicitud (LOW, MEDIUM, HIGH, IMMEDIATE)

Fast Android Networking Library es compatible con RxJava

Como utiliza OkHttp como una capa de red, soporta:

Fast Android Networking Library soporta soporte HTTP / 2 permite que todas las peticiones al mismo host para compartir un socket

Fast Android Networking Library utiliza 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 completamente para las solicitudes de repetición

Gracias: La biblioteca es creada por mí

Sólo para añadir un poco a la discusión de mi experiencia de trabajo con Volley:

1. Volley no maneja la transmisión de subidas o descargas en ningún sentido. Es decir, el cuerpo entero de la petición tiene que estar en memoria y usted no puede utilizar un OutputStream para escribir el cuerpo de la petición al socket subyacente, ni puede utilizar un InputStream para leer el cuerpo de la respuesta, como HttpURLConnection básico. Por lo tanto, Volley es una mala opción para cargar o descargar archivos grandes. Sus peticiones y respuestas deben ser pequeñas. Esta es una de las mayores limitaciones de Volley que he encontrado personalmente. Por lo que vale la pena, OkHttp tiene interfaces para trabajar con corrientes.

2. La falta de documentación oficial es molesta, aunque he podido trabajar en torno a eso 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 de lanzamiento y ningún artefacto de Maven o Gradle, y por lo tanto, manejarlo como una dependencia se convierte en más de un dolor de cabeza que, digamos, cualquiera de las bibliotecas Square ha lanzado . Usted acaba de clonar un repo, construir un frasco, y usted está en su propio. ¿Está buscando una corrección de errores? Busca y espera que esté ahí. Usted podría obtener algunas otras cosas, también; No se documentará. En mi opinión, esto significa efectivamente que Volley es una biblioteca de terceros sin soporte, aunque la base de código es razonablemente activa. Caveat emptor.

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

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 simultáneas son excelentes características. Sólo sepa que no está pensado para todos los casos de uso de HTTP (véase el punto 1 anterior), y que hay algunos dolores de cabeza involucrados en poner Volley en uso de producción en su aplicación (ítem 2).

Recientemente he encontrado un lib llamado ion que trae un poco más a la mesa.

Ion tiene soporte incorporado para la descarga de imágenes integrado con ImageView, JSON (con la ayuda de GSON), archivos y un soporte de subprocesamiento de interfaz de usuario muy práctico.

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.

Añadiendo a la respuesta aceptada y lo que LOG_TAG dijo …. para Volley para analizar sus datos en un subproceso de fondo que debe subclase Request<YourClassName> como el método onResponse se llama en el hilo principal y analizar en el hilo principal puede causar la interfaz de usuario A retrasar si su respuesta es grande. Lea aquí 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 cuando analizo la clase JSON anidada. Porque Spice Manger hará todo por ti. En Retrofit necesitas crear GsonConverter y deserializarlo.

He creado dos fragmentos en la misma actividad y se llama 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: 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 fuera de la caja
• Cuenta con un módulo para generar mapeos de interfaz API de servidor como Retrofit
• También tiene soporte para JavaRx

Y muchas otras características prácticas como marcadores, transformadores, etc.