volley español android networking retrofit android-networking

android - español - retrofit vs volley



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

Pregunta de dos partes de un desarrollador de iOS que está aprendiendo Android, trabajando en un proyecto de Android que realizará una variedad de solicitudes de JSON a imagen para transmitir en streaming 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 Volley pero aún no tengo experiencia en el desarrollo 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. 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 un indocumentado, un no compatible, "lanzar el código sobre la pared y hacer una presentación de I | O en él".

EDITAR - Volley ahora es oficialmente compatible con Google. Consulte la Guía del desarrollador de Google

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

El reequipamiento 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 usará ninguno de ellos para la "transmisión de audio y video", según la definición convencional de "transmisión". En su lugar, el marco de medios de Android manejará esas solicitudes HTTP por ti.

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 manejaría Volley ese escenario. Ni Retrofit ni Picasso están diseñados para 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 necesita 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

AFNetworking para Android:

Fast Android Networking está aquí

La biblioteca de redes de Android rápida admite todo tipo de solicitudes HTTP / HTTPS como GET, POST, DELETE, HEAD, PUT, PATCH

La biblioteca de redes de Android rápida admite la descarga de cualquier tipo de archivo

La biblioteca rápida de redes de Android admite la carga de cualquier tipo de archivo (admite la carga de varias partes)

La biblioteca rápida de redes de Android admite la cancelación de una solicitud

La biblioteca de redes de Android rápida admite la configuración de prioridad a cualquier solicitud (BAJA, MEDIA, ALTA, INMEDIATA)

La biblioteca de redes de Android rápida admite RxJava

Como utiliza OkHttp como una capa de red, admite:

La biblioteca rápida de redes Android admite el soporte HTTP / 2 y permite que todas las solicitudes al mismo host compartan un socket.

La biblioteca de redes de Android rápida utiliza la agrupación de conexiones, lo que reduce la latencia de la solicitud (si HTTP / 2 no está disponible)

GZIP transparente reduce los tamaños de descarga

La biblioteca de redes de Android rápida admite el almacenamiento en caché de respuestas que evita la red por completo para solicitudes repetidas

Gracias: La biblioteca es creada por mí.

Agregando a la respuesta aceptada y lo que LOG_TAG dijo ... para que Volley analice sus datos en un hilo de fondo, debe subclase Request<YourClassName> ya que se llama al método onResponse en el hilo principal y el análisis en el hilo principal puede causar la interfaz de usuario retrasarse si tu respuesta es grande Lea here sobre cómo hacer eso.

Mirando la perspectiva de Volley aquí hay algunas ventajas para su requerimiento:

Volley, por un lado, está totalmente centrado en el manejo de solicitudes HTTP individuales y pequeñas. Entonces, si el manejo de su solicitud HTTP tiene algunas peculiaridades, Volley probablemente tenga un gancho para usted. Si, por otro lado, tiene un capricho 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 ventajas como una vez que define sus solicitudes, usarlas desde un fragmento o actividad es indoloro, a diferencia de las tareas asíncronas paralelas.

Pros y contras del volley:

Entonces, ¿qué tiene de bueno Volley?

  • La parte de red no es sólo 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 preocupado por ser juiciosos en sus patrones de uso de memoria. Volley también hace un esfuerzo por devolver las llamadas al hilo principal para reducir el cambio de contexto.

  • Volley aparentemente tiene futuros, también. Echa un vistazo a RequestFuture si estás interesado.

  • Si está tratando con imágenes comprimidas de alta resolución, Volley es la única solución que funciona bien aquí.

  • 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 la volea:
Como Volley es nuevo, pocas cosas aún no están soportadas, pero están arregladas.

  1. Solicitudes multiparte (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. (Corregido: https://github.com/Vinayrraj/CustomVolley )

    Actualización: en el último lanzamiento de Google volley, el error de los códigos de estado 2XX se fixed ahora. ¡Gracias a Ficus Kirkpatrick!

  3. está menos documentado pero muchas de las personas están apoyando el voleo en github, la documentación tipo java se puede encontrar here . 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 volea 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 de Comparing Volley cargando con Picasso

Retrofit:

Se lanzó por Retrofit , Esto ofrece API REST muy fáciles de usar (Actualización: ¡Voila! Con soporte NIO)

Pros de Retrofit:

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

  • Podemos usarlo con cualquier librería 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 with OkHttp 2.0 ahora depende de Okio para admitir java.io y java.nio, lo que facilita el acceso, el almacenamiento y el procesamiento de sus datos utilizando ByteString y Buffer para hacer algunas cosas inteligentes para ahorrar CPU y memoria. (Para su información: ¡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 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:

  • 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 la compatibilidad de Okio con Java NIO.

  • La asistencia mínima de subprocesos puede hacer que devuelva la llamada al infierno si usamos esto de manera incorrecta.

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

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

Actualizar:

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

(La información FYI que figura más arriba sobre los puntos de referencia de las modificaciones se mejorará con el soporte de NIO de Java porque la nueva versión de OKhttp depende de la biblioteca Okio de NIO)

En las tres pruebas con repeticiones variables (1 - 25 veces), Volley fue entre 50% y 75% más rápido. El reacondicionamiento registró un impresionante 50% a 90% más rápido que las Tareas Asíncronas, llegando al 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 diferencia masiva del mundo real. Para hacer 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 prueba de referencia!

Al final, decidimos utilizar Retrofit para nuestra aplicación. No solo es ridículamente rápido, sino que se adapta bastante bien a 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 sean compatibles con GSON, escribir algunas interfaces simples, eliminar funciones de la API antigua y modificar nuestros fragmentos para que no utilicen AsyncTasks. Ahora que tenemos algunos fragmentos completamente convertidos, es bastante indoloro. Hubo algunos problemas 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 resolverlo.

¿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 de n / w al mismo tiempo! También Volley tiene mejor manejo de errores relacionados con la memoria que Retrofit

OkHttp puede usarse con Volley, Retrofit usa OkHttp de forma predeterminada. ¡Tiene soporte SPDY , agrupación de conexiones, almacenamiento en caché de disco, compresión transparente! Recientemente, ha recibido algún soporte de java NIO con la biblioteca Okio .

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

Nota: La transmisión depende de qué tipo de transmisión desea, como RTSP / RTCP.

Recientemente he encontrado una biblioteca llamada ion que trae 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 de subprocesos de interfaz de usuario 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.

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 OutputStream para escribir el cuerpo de la solicitud en el socket subyacente, ni tampoco puede usar un InputStream para leer el cuerpo de la respuesta, como HttpURLConnection hace el HttpURLConnection básico. Por lo tanto, Volley es una mala elecció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. Para lo que vale, OkHttp tiene interfaces para trabajar con flujos.

  2. La falta de documentación oficial es molesta, aunque he podido solucionar 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 de lanzamiento oficiales ni artefactos de Maven o Gradle, y por lo tanto gestionarlo como una dependencia se convierte en un dolor de cabeza más que, digamos, que cualquiera de las bibliotecas ha publicado Square. . Solo tienes que clonar un repositorio, construir un frasco y estás por tu cuenta. Buscando una corrección de errores? Fetch y espero que esté ahí. Puede que también consigas otras cosas; no será documentado En mi opinión, esto significa efectivamente que Volley es una biblioteca de terceros no admitida, aunque la base de código esté razonablemente activa. Cavtor 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 (por cierto, no hagas esto con Volley; terminarás con dos encabezados de Content-Type). Esa es solo mi opinión personal, sin embargo, y puede ser resuelta.

Eso no quiere decir que Volley no tenga algunas características útiles. Ciertamente lo hace. Las políticas de reintento fácilmente personalizables, el almacenamiento en caché transparente, una API de cancelación y el soporte para la programación de solicitudes y las conexiones simultáneas son excelentes características. Solo sepa que no está diseñado para todos los casos de uso de HTTP (vea el artículo 1 más arriba), y que hay algunos dolores de cabeza involucrados en poner Volley en uso de producción en su aplicación (artículo 2).

Y otra opción más: https://github.com/apptik/jus

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

Y muchas otras características útiles como marcadores, transformadores, etc.

Async HTTP client loopj vs. Volley

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

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

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

Después de usarlo por un tiempo, incluso sin pruebas, veo claramente que el tiempo de respuesta es de 1.5x, 2x Volley.

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

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 con 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 debe tener lugar en Android. En última instancia, puede desenterrar ambas bibliotecas y encontrar que son bastante similares, pero nuestra manera de hacer el procesamiento en segundo plano está más orientada a Android, nos permite, por ejemplo, decirle a los usuarios que RS realmente está haciendo algo en segundo plano, lo que sería Difícil para volear (en realidad no lo es en absoluto).
  • RoboSpice y volley ofrecen buenas características 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 ese es uno grande, con administración de caché, agregación de solicitudes, más funciones, como responder a una solicitud pendiente, lidiar con la caducidad del caché sin depender de los encabezados del servidor, etc.
  • RoboSpice hace más cosas fuera del tema de la interfaz de usuario: volley deserializará tus POJOs en el tema 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 aún no tenemos una cifra 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, readaptación, omlite (beta), jackson, jackson2, gson, serializador xml, 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 datos. En cuanto a las características no está tan lejos, pero creo que Volley está más avanzado en este tema.
  • Más de 200 errores han sido resueltos 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 estar creciendo rápidamente (efecto Google).
  • RoboSpice está disponible en maven central. Volley es difícil de encontrar;)