Solution de cache d'image locale pour Android: Square Picasso, Universal Image Loader, Glide, Fresco?

Je recherche une bibliothèque de chargement et de mise en cache d'image asynchrone sous Android. J'allais utiliser Picasso, mais j'ai trouvé que Universal Image Loader est plus populaire sur GitHub. Quelqu'un connaît-il ces deux bibliothèques? Un résumé des avantages et des inconvénients serait formidable.

(Toutes mes images sont sur disque localement, donc je n'ai pas besoin de réseau, donc je ne pense pas que Volley convienne)

Mise à jour de septembre 2018: après plusieurs années, j'avais presque besoin de la même chose pour une solution de mise en cache d'image locale. Cette fois-ci, l'UIL n'a pas été en développement actif. J'ai comparé les bibliothèques populaires, et la conclusion est assez simple: utilisez simplement Glide. C'est beaucoup plus puissant et configurable. Il y a des années, j'ai dû bifurquer et apporter des modifications à l'UIL. Glide prend en charge tous mes cas d'utilisation en termes de stratégie de mise en cache et de multiples niveaux de mise en cache de résolution avec des clés personnalisées. Utilisez simplement Glide!

La comparaison de Koushik Dutta concerne principalement la vitesse de référence. Son message n'a touché que des choses très basiques et n'est pas spécifique aux images locales. J'aimerais partager mes expériences avec Picasso et l'UIL après avoir posé la question. Picasso et UIL peuvent charger des images locales. J'ai d'abord essayé Picasso et j'étais content, mais plus tard, j'ai décidé de passer à UIL pour plus d'options de personnalisation.

Picasso:

• L'interface fluide de Picasso est agréable. Mais sauter avec «avec», «dans», «charger», vous ne savez pas vraiment ce qui se cache derrière la scène. C'est déroutant ce qui est retourné.

• Picasso vous permet de spécifier la taille exacte de la cible. C'est utile lorsque vous avez des problèmes de pression de la mémoire ou de performances, vous pouvez échanger une qualité d'image contre la vitesse.

• Les images sont mises en cache avec la taille dans sa clé, c'est utile lorsque vous affichez des images de différentes tailles.

• Vous pouvez personnaliser la taille du cache mémoire. Mais son cache disque est uniquement pour les requêtes http. Pour les images locales, si vous vous souciez de la vitesse de chargement, il est bon d'avoir un cache disque de vignettes pour ne pas avoir à lire plusieurs Mo pour une image à chaque fois. Picasso ne dispose pas de ce mécanisme de redimensionnement et d'enregistrement des vignettes sur le disque.

• Picasso n'expose pas l'accès à son instance de cache. (Vous pouvez vous en procurer lors de la configuration initiale de Picasso et le conserver ...).

• Parfois, vous souhaitez lire une image de manière asynchrone dans un bitmap renvoyé par un écouteur. Étonnamment, Picasso n'a pas cela. "fetch ()" dose ne renvoie rien. "get ()" est pour une lecture synchrone, et "load ()" est pour dessiner une vue de manière asynchrone.

• Picasso n'a que quelques exemples simples sur la page d'accueil, et vous devrez lire le javadoc non ordonné pour des utilisations avancées.

UIL:

• UIL utilise des générateurs pour la personnalisation. Presque tout peut être configuré.

• UIL ne vous permet pas de spécifier la taille que vous souhaitez charger dans une vue. Il utilise certaines règles basées sur la taille de la vue. Ce n'est pas aussi flexible que Picasso. Je n'ai aucun moyen de charger une image de résolution inférieure pour réduire l'empreinte mémoire. (Modifier: ce comportement peut être facilement modifié en ajoutant un argument ImageSize dans le code source et en contournant la vérification de la taille de la vue)

• UIL fournit un cache de disque personnalisable, vous pouvez l'utiliser pour mettre en cache les vignettes avec la taille spécifiée. Mais ce n'est pas parfait. Voici les détails . (Modifier: si vous vous souciez de la vitesse et que vous souhaitez plusieurs niveaux de mise en cache des vignettes, comme mon cas, vous pouvez modifier le code source, laisser le cache disque utiliser "memoryKey" et le rendre également sensible à la taille)

• UIL par défaut met en cache des images de différentes tailles dans la mémoire, et il peut être désactivé dans la configuration.

• UIL expose la mémoire de sauvegarde et le cache disque auxquels vous pouvez accéder.

• UIL fournit des moyens flexibles pour obtenir une image bitmap ou charger dans une vue.

• UIL est meilleur dans la documentation. UIL donne les utilisations détaillées sur la page Github, et il y a un tutoriel lié.

Je suggère de commencer par Picasso, si vous avez besoin de plus de contrôle et de personnalisation, optez pour UIL.

Si vous lisez cet article sur G + by Koush, vous obtiendrez des solutions claires pour vos confusions, j'en ai mis le résumé, en ce qu'Android-Universal-Image-Loader est le gagnant pour votre exigence!

• Picasso a la plus belle API d'image si vous utilisez le réseau!

• UrlImageViewHelper + AndroidAsync est le plus rapide. Jouer avec ces deux autres grandes bibliothèques a vraiment mis en évidence que l'API d'image est assez datée, cependant.

• Volley est lisse; J'apprécie vraiment leurs transports backend enfichables,
  et peut finir par y laisser AndroidAsync. La
  gestion de lapriorité des demandeset des annulations est excellente (si vous utilisez le réseau)

• Android-Universal-Image-Loader est le plus populaire
  actuellement. Hautement personnalisable.

Ce projet vise à fournir un instrument réutilisable pour le chargement, la mise en cache et l'affichage d'images asynchrones. Il est à l'origine basé sur le projet de Fedor Vlasov et a été considérablement remanié et amélioré depuis lors.

Modifications à venir dans la nouvelle version d'UIL (1.9.2):

Possibilité d'appeler ImageLoader en dehors du thread de l'interface utilisateur Nouvelle API de cache de disque (plus flexible). Nouveau LruDiscCache basé sur DiskLruCache de Jake Wharton.

Compte tenu de tout cela, Android-Universal-Image-Loader répond à vos besoins (le chargement des images se fait localement sur le disque )!

Je souhaite partager mon expérience avec ces 3 bibliothèques: UIL, Picasso et Volley. J'utilisais auparavant UIL, mais je suis arrivé à la conclusion que je ne peux pas vraiment le recommander et je suggérerais plutôt d'utiliser Volley ou Picasso, tous deux développés par des équipes très talentueuses. UIL n'est pas mal du tout mais il manque l'attention aux détails des deux autres bibliothèques.

J'ai trouvé UIL moins agréable avec les performances de l'interface utilisateur; il a tendance à verrouiller le thread de l'interface utilisateur plus que Volley ou Picasso. Cela peut être en partie dû au fait que UIL ne prend pas en charge le traitement par lots des réponses d'image alors que Picasso et Volley le font par défaut.

De plus, je n'aimais pas le système de cache disque d'UIL. Bien que vous puissiez choisir entre différentes implémentations, je dois souligner que pour le moment, il n'y a aucun moyen de limiter le cache disque UIL à la fois par la taille totale et par le délai d'expiration de l'entité. Volley et Picasso font cela, et ils utilisent l'heure d'expiration renvoyée par le serveur par défaut alors que UIL l'ignore.

Enfin, UIL vous permet de définir une configuration globale du chargeur d'images qui inclut les implémentations et paramètres de cache disque et de cache mémoire sélectionnés et d'autres détails, mais cette configuration sera appliquée partout dans votre application. Donc, si vous avez besoin de plus de flexibilité comme deux caches de disque séparés, ce n'est pas le cas pour UIL. Volley, quant à lui, vous permet d'avoir autant de chargeurs d'images séparés que vous le souhaitez, chacun avec sa propre configuration. Picasso utilise une instance globale par défaut, mais vous permet également de créer des instances configurables séparément.

Pour résumer: Picasso a la meilleure API mais il utilise le cache disque HTTP global partagé entre toutes les HttpURLConnectioninstances, ce qui peut être trop restrictif dans certains cas. Volley offre les meilleures performances et la meilleure modularité, mais il est moins convivial et vous obligera à écrire un ou deux modules de votre choix pour le faire fonctionner comme vous le souhaitez. Dans l'ensemble, je les recommanderais tous les deux contre l'UIL.

Edit (18 décembre 2014): Les choses ont changé depuis que j'ai écrit cette première réponse et j'ai senti qu'il était nécessaire de l'améliorer:

Picasso 2.4 est encore plus configurable que les versions plus anciennes, et lorsqu'il est utilisé avec OkHttp (ce qui est fortement recommandé), il est également capable d'utiliser un cache disque séparé pour chaque instance, donc il n'y a vraiment aucune restriction dans ce que vous pouvez faire. Plus important encore, j'ai remarqué que les performances de Picasso et d'OkHttp se sont beaucoup améliorées et à mon avis, c'est maintenant la solution de chargeur d'image la plus rapide pour Android, point final . Veuillez noter que dans mon code, j'utilise toujours .fit()en combinaison avec .centerCrop()ou .centerInside()pour réduire l'utilisation de la mémoire et éviter les redimensionnements bitmap sur le thread de l'interface utilisateur. Picasso est activement développé et soutenu et c'est certainement un gros plus.

Volley n'a pas beaucoup changé mais j'ai remarqué deux problèmes avec lui entre-temps:

• Parfois sous forte charge, certaines images ne sont plus chargées en raison d'une corruption du cache disque.
• Les miniatures affichées dans un NetworkImageView (avec son type d'échelle défini sur centerCrop) sont assez floues par rapport à ce que vous obtenez avec les autres bibliothèques.

Pour ces raisons, j'ai décidé d'arrêter d'utiliser Volley.

UIL est encore lent (notamment le cache disque) et son API a tendance à changer assez souvent.

J'ai également testé cette nouvelle bibliothèque appelée Glide 3 qui prétend être plus optimisée que Picasso avec une API de type Picasso. D'après mon expérience personnelle, il est en fait plus lent que Picasso et Volley lors des requêtes réseau sous forte charge, même lorsqu'il est utilisé en combinaison avec OkHttp. Pire encore, cela a provoqué quelques plantages avec mes applications sous Lollipop en quittant une activité. Il a toujours 2 avantages par rapport à ses concurrents:

• Il prend en charge le décodage des GIF animés
• Il place les bitmaps finaux mis à l'échelle dans le cache disque, ce qui signifie que la lecture à partir du cache disque est extrêmement rapide.

Conclusion: je recommande maintenant d'utiliser Picasso + OkHttp car il offre la meilleure flexibilité, API, performances et stabilité combinées. Si vous avez besoin du support GIF, vous pouvez également envisager Glide.

J'ai implémenté une application qui devrait constamment obtenir et afficher des images d'Internet. J'étais sur le point de programmer un mécanisme de cache d'image, avant cela, un ami m'a recommandé le chargeur d'image universel.

L'UIL est très bien personnalisable. Il est tellement personnalisable qu'un débutant peut facilement faire quelque chose de mal. Cependant, l'UIL était lent dans mon application et il est devenu un peu plus lent. Mon cas d'utilisation était un ListView avec des images.

Hier je cherchais une alternative à l'UIL, et j'ai découvert Picasso. Picasso était facile à intégrer et à utiliser: juste Picasso.context(context).load(url).into(imageview)et l'image pouvait être intégrée plus rapidement et en douceur.

Pour moi, Picasso est définitivement l'API à utiliser. Mon expérience avec l'UIL n'a pas été bonne.

Je pense qu'ImageLoader est plus personnalisable et flexible que la bibliothèque Picasso.