Solution de mise en cache d’images locale pour Android: Square Picasso, Chargeur d’image universel, Glide, Fresco?
Je recherche une bibliothèque asynchrone de chargement et de mise en cache des images sous Android. J'allais utiliser Picasso, mais j'ai découvert qu'Universal Loader était plus populaire sur GitHub. Est-ce que quelqu'un sait à propos de ces deux bibliothèques? Un résumé des avantages et des inconvénients serait formidable.
(Toutes mes images sont localisées sur le disque, je n'ai donc pas besoin de réseau, donc je ne pense pas que Volley convienne)
Mise à jour septembre 2018: après plusieurs années, j'avais 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: il suffit d'utiliser Glide. C'est beaucoup plus puissant et configurable. Il y a des années, j'ai dû modifier et modifier UIL. Glide prend en charge tous mes cas d'utilisation en termes de stratégie de mise en cache et de plusieurs niveaux de mise en cache de résolution avec des clés personnalisées. Il suffit d'utiliser Glide!
La comparaison de Koushik Dutta porte principalement sur la vitesse de référence. Son message ne touchait que des choses très basiques et n'était 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 heureux, mais plus tard, j'ai décidé de passer à UIL pour davantage d'options de personnalisation.
Picasso:
L'interface fluide de Picasso est Nice. Mais en sautant avec "avec", "dans", "charge", vous ne savez pas ce qui se passe 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 mémoire ou de performances, vous pouvez échanger une qualité d'image de la vitesse.
Les images sont mises en cache avec la taille dans sa clé, il est utile lorsque vous affichez des images de différentes tailles.
Vous pouvez personnaliser la taille du cache mémoire. Mais son cache disque ne concerne que les requêtes http. Pour les images locales, si vous vous souciez de la vitesse de chargement, il est bon de disposer d'un cache de disque miniature afin de ne pas avoir à lire plusieurs Mo pour une image à chaque fois. Picasso ne dispose pas de ce mécanisme pour redimensionner et enregistrer des vignettes sur le disque.
Picasso n'expose pas l'accès à son instance de cache. (Vous pouvez le récupérer lorsque vous configurez Picasso pour la première fois et que vous le conservez ...).
Parfois, vous souhaitez lire une image de manière asynchrone dans une image bitmap renvoyée par un écouteur. Étonnamment, Picasso n’a pas cela. "fetch ()" ne renvoie rien. "get ()" est utilisé pour une lecture synchrone et "load ()" est utilisé 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 fichier javadoc non ordonné pour les 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 des 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'encombrement de la mémoire. (Edit: 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 que vous pouvez utiliser pour mettre en cache les vignettes avec la taille spécifiée. Mais ce n'est pas parfait. Voici les détails . (Edit: si vous vous souciez de la vitesse et que vous voulez plusieurs niveaux de mise en cache des vignettes, comme dans 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 mémoire cache des images de différentes tailles et peut être désactivé lors de la configuration.
UIL expose la mémoire de sauvegarde et le cache de disque auxquels vous pouvez accéder.
UIL fournit des moyens flexibles d'obtenir un bitmap ou de charger une vue.
UIL est meilleur en 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 this post sur G + de Koush, vous obtiendrez des solutions claires à vos confusions. Je vous en ai résumé le résultat, car Android-Universal-Image-Loader est le gagnant pour votre exigence!
Picasso possède la plus belle API d'image si vous utilisez le réseau!
rlImageViewHelper + AndroidAsync est le plus rapide. Jouer avec ces deux autres grandes bibliothèques a vraiment mis en évidence le fait que l’API de l’image est datée.
Volley est lisse; J'apprécie vraiment leurs transports dorsaux enfichables,
et peut finir par y déposer AndroidAsync. La priorité de la demande
et la gestion des annulations est excellente (si vous utilisez un 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é largement remanié et amélioré depuis.
Changements à venir dans la nouvelle version d'UIL (1.9.2):
Possibilité d'appeler ImageLoader en dehors de l'interface utilisateur de l'API threadNew Disk Cache (plus flexible). Nouveau LruDiscCache basé sur DiskLruCache de Jake Wharton.
Tenez compte de toutes vos suites Android-Universal-Image-Loader ( Chargement des images sur disque localement)!
J'aimerais partager mon expérience avec ces 3 bibliothèques: UIL, Picasso et Volley. J’avais précédemment utilisé UIL, mais j’en suis venu à 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 mauvais du tout mais il manque l’attention portée aux détails des deux autres bibliothèques.
J'ai trouvé que UIL était moins gentil avec la performance de l'interface utilisateur; il tend à verrouiller le fil de l'interface utilisateur plus que Volley ou Picasso. Cela peut être dû en partie 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’ai pas aimé le système de cache disque de UIL. Bien que vous puissiez choisir entre différentes implémentations, je dois souligner qu’il n’existe pour l’instant aucun moyen de limiter le cache disque UIL à la fois par taille totale et par entité date d'expiration. Volley et Picasso le font et utilisent le délai d’expiration renvoyé 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 les paramètres de cache de disque et de mémoire sélectionnés, ainsi que 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 distincts, vous ne pouvez pas utiliser UIL. En revanche, Volley vous permet d’avoir autant de chargeurs d’images 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 dispose de la meilleure API, mais utilise le cache de disque HTTP global partagé entre toutes les instances HttpURLConnection, ce qui peut être trop restrictif dans certains cas. Volley offre les meilleures performances et la meilleure modularité, mais est moins convivial et vous obligera à écrire un ou deux modules vous-même pour que tout fonctionne comme vous le souhaitez. Globalement, je les recommanderais tous les deux à l’UIL.
Edit (18 décembre 2014): Les choses ont changé depuis que j'ai écrit cette réponse initiale et j'estimais qu'il était nécessaire de l'améliorer:
Picasso 2.4 est encore plus configurable que les versions précédentes, et lorsqu'il est utilisé avec OkHttp (ce qui est fortement recommandé), il est également capable d'utiliser un cache de disque distinct pour chaque instance, de sorte qu'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, il s'agit désormais de la solution de chargeur d'images la plus rapide pour Android, tout simplement. 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 des images bitmap sur le thread d'interface utilisateur. Picasso est activement développé et soutenu, ce qui est certainement un avantage considérable.
Volley n’a pas beaucoup changé, mais j’ai remarqué deux problèmes entre-temps:
- Parfois sous forte charge, certaines images ne sont plus chargées à cause 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é de cesser d'utiliser Volley.
UIL est toujours lent (en particulier le cache disque) et son API a tendance à changer assez souvent.
J'ai également testé cette nouvelle bibliothèque appelée Glide , qui se veut plus optimisée que Picasso avec une API de type Picasso. Selon mon expérience personnelle, il est en fait plus lent que Picasso et Volley lors de requêtes réseau sous forte charge, même lorsqu'il est utilisé avec OkHttp. Pire encore, cela provoquait quelques plantages de mes applications sous Lollipop lorsque je quittais une activité. Il a toujours 2 avantages sur ses concurrents:
- Il prend en charge le décodage de fichiers GIF animés
- Il place les bitmaps finaux réduits dans le cache de disque, ce qui signifie que la lecture à partir du cache de 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 mis en place une application qui devrait constamment afficher et afficher des images provenant d'Internet. J'étais sur le point de programmer un mécanisme de cache d'image, avant qu'un ami ne m'ait recommandé le chargeur d'images universel.
L'UIL est très bien personnalisable. C'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 pourrait être plus rapide et plus facilement intégrée.
Pour moi, Picasso est définitivement l’API à utiliser. Mon expérience avec UIL n'était pas bonne.
Je pense que ImageLoader est plus personnalisable et flexible que la bibliothèque Picasso.