android - library - Picasso v/s Imageloader v/s Fresco vs Glide

libreria glide android (6)

Recomendaciones:

Diferencia entre Picasso v / s ImageLoader aquí ...
Información sobre la biblioteca GLIDE aquí ...
Ahora, recientemente, Facebook lanzó una nueva biblioteca de imágenes llamada Fresco

Preguntas:

¿Cuál es la diferencia entre Picasso v / s Imageloader v / s Fresco?
¿Cuándo podemos usar Glide?
Cuál es la mejor biblioteca para usar.
Si cada biblioteca tiene su propio significado, ¿cuáles son?

Estas respuestas son totalmente mi opinión

Respuestas

Picasso es un cargador de imágenes fácil de usar, lo mismo ocurre con Imageloader. Fresco utiliza un enfoque diferente para la carga de imágenes, aún no lo he usado, pero me parece más una solución para obtener imágenes de la red y almacenarlas en caché y luego mostrarlas. luego al revés, como Picasso / Imageloader / Glide, que para mí son más Mostrar imagen en pantalla que también obtiene imágenes de la red y las almacena en caché.
Glide intenta ser algo intercambiable con Picasso. Creo que cuando se crearon, la mentalidad de Picasso era seguir las especificaciones HTTP y dejar que el servidor decidiera las políticas de almacenamiento en caché y la memoria caché de tamaño completo y redimensionar según demanda. Glide es lo mismo con seguir la especificación HTTP, pero trata de tener una huella de memoria más pequeña haciendo algunas suposiciones diferentes, como almacenar en caché las imágenes redimensionadas en lugar de las imágenes de tamaño completo, y mostrar imágenes con RGB_565 en lugar de RGB_8888. Ambas bibliotecas ofrecen una personalización completa de la configuración predeterminada.
Es difícil decir qué biblioteca es la mejor para usar. Picasso, Glide e Imageloader son bibliotecas bien respetadas y probadas, todas fáciles de usar con la configuración predeterminada. Tanto Picasso como Glide requieren solo 1 línea de código para cargar una imagen y tienen un marcador de posición y una imagen de error. Personalizar el comportamiento tampoco requiere tanto trabajo. Lo mismo ocurre con Imageloader, que también es una biblioteca más antigua que Picasso y Glide, sin embargo, no lo he usado, así que no puedo decir mucho sobre el rendimiento / uso de memoria / personalizaciones, pero mirar el archivo Léame en github me da la impresión de que también es relativamente fácil de usar y configurar. Entonces, al elegir cualquiera de estas 3 bibliotecas, no puede tomar una decisión incorrecta, es más una cuestión de gusto personal. Para los frescos, mi opinión es que es otra biblioteca de Facebook, así que tenemos que ver cómo les va a funcionar, hasta ahora el historial no es tan bueno. ~~Al igual que el SDK de Facebook todavía no se lanzó oficialmente en mavenCentral,~~ no he usado Facebook SDK desde septiembre de 2014 y parece que pusieron la primera versión en línea en mavenCentral en octubre de 2014. Por lo tanto, tomará algún tiempo antes de que podamos obtener cualquier Buena opinión al respecto.
entre las 3 bibliotecas de grandes nombres, creo que no hay diferencias significativas. El único que se destaca es el fresco, pero eso se debe a que tiene un enfoque diferente y es nuevo y no está probado en batalla.

Ni Glide ni Picasso son perfectos. La forma en que Glide carga una imagen en la memoria y realiza el almacenamiento en caché es mejor que Picasso, que permite que una imagen se cargue mucho más rápido. Además, también ayuda a evitar que una aplicación sea popular OutOfMemoryError. La carga de animación GIF es una característica de asesinato proporcionada por Glide. De todos modos, Picasso decodifica una imagen con mejor calidad que Glide.

¿Cuál prefiero? Aunque uso Picasso durante tanto tiempo, debo admitir que ahora prefiero Glide. Pero le recomendaría que cambie el formato de mapa de bits a ARGB_8888 y deje que Glide almacene en caché la imagen a tamaño completo y cambie el tamaño de una primero. ¡El resto haría tu trabajo genial!

El recuento de métodos de Picasso y Glide está en 840 y 2678 respectivamente.
El tamaño de Picasso (v2.5.1) es de alrededor de 118 KB, mientras que el de Glide (v3.5.2) es de alrededor de 430 KB.
Glide crea imágenes en caché por tamaño, mientras que Picasso guarda la imagen completa y la procesa, por lo que al cargarla se muestra más rápido con Glide pero usa más memoria.
Glide usa menos memoria por defecto con RGB_565 .

+1 para Picasso Palette Helper .

Hay una publicación que habla mucho sobre Picasso vs Glide

Quiero compartir con ustedes un punto de referencia que he hecho entre Picasso, Universal Image Loader y Glide : https://bit.ly/1kQs3QN

Fresco estaba fuera del punto de referencia porque para el proyecto en el que estaba ejecutando la prueba, no queríamos refactorizar nuestros diseños (debido a la vista Drawee).

Lo que recomiendo es Universal Image Loader debido a su personalización, consumo de memoria y equilibrio entre tamaño y métodos.

Si tienes un proyecto pequeño, iría por Glide (o probaría Fresco).

Soy uno de los ingenieros del proyecto Fresco. Así que obviamente soy parcial.

Pero no tienes que creer mi palabra. Hemos lanzado una aplicación de muestra que le permite comparar el rendimiento de cinco bibliotecas: Fresco, Picasso, UIL, Glide y Volley Image Loader, una al lado de la otra. Puede obtenerlo en nuestro repositorio de GitHub .

También debo señalar que Fresco está disponible en Maven Central, como com.facebook.fresco:fresco .

Fresco ofrece características que Picasso, UIL y Glide aún no tienen:

Las imágenes no se almacenan en el montón de Java, sino en el montón de ashmem. Los almacenamientos intermedios de bytes también se almacenan en el montón nativo. Esto deja mucha más memoria disponible para que las aplicaciones lo usen. Reduce el riesgo de OutOfMemoryErrors. También reduce la cantidad de aplicaciones de recolección de basura que tienen que hacer, lo que lleva a un mejor rendimiento.
Las imágenes JPEG progresivas se pueden transmitir, al igual que en un navegador web.
Las imágenes se pueden recortar en cualquier punto, no solo en el centro.
Las imágenes JPEG se pueden cambiar de tamaño de forma nativa. Esto evita el problema de OOM al intentar reducir el tamaño de una imagen.

Hay muchos otros ( consulte nuestra documentación ), pero estos son los más importantes.

Tenga en cuenta que esta es una pregunta altamente basada en opiniones, así que dejé de hacer fiordos e hice una tabla rápida

Ahora, la comparación de la biblioteca es difícil porque en muchos parámetros, los cuatro hacen lo mismo, excepto posiblemente para Fresco porque hay un montón de nuevas optimizaciones de nivel de memoria, así que avíseme si ciertos parámetros le gustaría ver una comparación basada en mi experiencia.

Habiendo usado menos Fresco, la respuesta podría evolucionar a medida que continúo usándola y la entiendo para las hazañas actuales. Lo used personally es haber usado la biblioteca al menos una vez en una aplicación completa.

* Nota: Fresco ahora admite animaciones GIF y WebP

Fresco fresco | Fuera del sitio
(-)
- Tamaño enorme de biblioteca
- Sin devolución de llamada con vista, parámetros de mapa de bits
- SimpleDraweeView no es compatible con wrap_content
- Tamaño enorme de caché
(+)
- Cargador de imágenes bastante rápido (para imágenes pequeñas y medianas)
- Mucha funcionalidad (transmisión, herramientas de dibujo, gestión de memoria, etc.)
- Posibilidad de configurar directamente en xml (por ejemplo, esquinas redondeadas)
- Soporte GIF
- Soporte webp y webp animado

sources Picasso | Fuera del sitio
(-)
- Carga lenta de imágenes grandes de internet en ListView
(+)
- Tamaño metálico de la biblioteca
- Pequeño tamaño de caché
- Simple de usar
- La interfaz de usuario no está congelada
- Soporte WebP

Fuentes de planeo

(-)
- Gran tamaño de biblioteca
(+)
- Tamaño metálico de caché
- Simple de usar
- Soporte GIF
- Soporte WebP
- Carga rápida de imágenes grandes de internet en ListView
- La interfaz de usuario no está congelada
- BitmapPool para reutilizar la memoria y, por lo tanto, eventos GC menores

sources Universal Image Loader

(-)
- Funcionalidad limitada (procesamiento de imagen limitado)
- El apoyo al proyecto se ha detenido desde el 27.11.2015
(+)
- Tamaño metálico de la biblioteca
- Simple de usar

Probado por mí en SGS2 (Android 4.1) (WiFi 8.43 Mbps)
¡Versiones oficiales para Java, no para Xamarin!
19 de octubre de 2015

Prefiero usar Glide.
Lee más here .
Cómo escribir caché en almacenamiento externo (tarjeta SD) con Glide.