Solution de cache d'image locale pour Android: Picasso carré, Chargeur D'Image universel, Glide, Fresco?
je suis à la recherche d'une bibliothèque asynchrone de chargement et de mise en cache D'images sur Android. J'allais utiliser Picasso, mais J'ai trouvé que Universal Image Loader est plus populaire sur GitHub. Personne ne sait à propos de ces deux bibliothèques? Un résumé des avantages et des inconvénients.
(toutes mes images sont sur disque localement, donc je n'ai pas besoin de réseau, donc je ne pense pas que Volley est une bonne chose)
5 réponses
mise à jour Septembre 2018: après plusieurs années, j'avais besoin de la même chose pour une solution de cache d'image locale. Cette fois-ci, 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. Il est beaucoup plus puissant et configurable. Il y a des années, J'ai dû changer 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. Utilisez juste Glide!
Koushik la comparaison de Dutta est principalement pour la vitesse de référence. Son billet 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 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 plus d'options de personnalisation.
Picasso:
-
L'interface fluide de Picasso est agréable. Mais en sautant avec "avec", "dans", "Charge" vous ne savez pas vraiment ce qu'il y a derrière la scène. C'est source de confusion ce qui est retourné.
-
Picasso vous permet de spécifier la taille cible exacte. Il est utile lorsque vous avez des problèmes de pression de mémoire ou de performance, vous pouvez échanger une certaine qualité d'image pour 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 n'est que 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 de vignettes de disque de sorte que vous n'avez pas à lire plusieurs MBs pour une image à chaque fois. Picasso n'a pas ce mécanisme de redimensionnement et de sauvegarde des vignettes sur le disque.
-
Picasso n'expose pas l'accès à son instance de cache. (Vous pouvez les attraper quand vous configurez tout d'abord Picasso et le garder...).
-
parfois vous voulez lire asynchrone l'image dans un bitmap retourné par un auditeur. Il est surprenant que Picasso n'ait pas ça. "fetch ()" dose ne rien transmettre. "get () "est pour la lecture synchrone, et" load () " est pour le dessin asynchrone d'une vue.
-
Picasso n'a que quelques exemples simples sur la page d'accueil, et vous aurez à lire à travers le javadoc Non classé pour les usages avancés.
UIL:
-
UIL utilise des constructeurs pour la personnalisation. Presque tout peut être configuré.
-
UIL ne vous permet pas de spécifier la taille que vous voulez 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'empreinte mémoire. (Edit: ce comportement peut être facilement modifié en ajoutant un argument ImageSize dans le code source et contourner 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 il n'est pas parfait. Voici le détails . (Modifier: si vous vous souciez de la vitesse et si vous voulez plusieurs niveaux de cache des vignettes, comme dans mon cas, vous pouvez modifier le code source, laisser le cache disque utiliser "memoryKey", et le rendre aussi sensible à la taille)
-
UIL cache par défaut des images de différentes tailles en mémoire, et il peut être désactivé en configuration.
-
UIL expose la mémoire de support et le cache de disque auquel vous pouvez accéder.
-
UIL fournit des façons flexibles d'obtenir une image bitmap ou de charger une vue.
-
UIL est mieux dans la documentation. UIL donne les usages détaillés sur la page Github, et il y a un tutoriel lié.
je vous suggère de commencer par Picasso, si vous avez besoin de plus de contrôle et de personnalisation, allez sur UIL.
si vous lisez ce post sur G+ par Koush vous obtiendrez des solutions claires pour vos confusions, j'ai mis le résumé de cela, dans que Android-Universal-Image-Loader est le gagnant pour votre besoin!
-
Picasso a la plus belle API d'image si vous utilisez le réseau!
-
UrlImageViewHelper + AndroidAsync est le plus rapide. En jouant avec ces deux autres grandes bibliothèques ont vraiment souligné que l'API d'image est assez daté, cependant.
-
Volley est lisse; j'aime vraiment leurs transports d'arrière-plan,
et peut finir par laisser tomber AndroidAsync. La demande de priorité
et la gestion d'annulation est grande (si vous utilisez le réseau) -
Android-Universel-Image-Loader est le plus populaire là-bas
actuellement. Hautement personnalisable.
ce projet vise à fournir un instrument réutilisable pour chargement, mise en cache et afficher. Il est à L'origine basé sur Fedor Vlassov projet et a été largement remaniée et améliorée depuis puis.
changements à Venir dans les nouveaux UIL version (1.9.2):
possibilité d'appeler ImageLoader à partir de L'API threadNew Disk Cache (plus flexible). Nouvelle LruDiscCache basée sur celle de Jake Wharton DiskLruCache.
considérant toutes ces suites Android-Universal-Image-Loader votre exigence ( chargement des images sont sur le disque local )!
je voudrais partager mon expérience avec ces 3 bibliothèques: UIL, Picasso et Volley. J'ai déjà utilisé UIL mais j'en suis arrivé à la conclusion que je ne peux pas vraiment le recommander et je suggérerais D'utiliser Volley ou Picasso à la place qui sont tous les deux développés par des équipes très talentueuses. UIL n'est pas mauvais du tout, mais il manque l'attention aux détails des deux autres bibliothèques.
J'ai trouvé UIL moins agréable avec la performance D'UI; il a tendance à verrouiller le fil D'UI plus que Volley ou Picasso. Cela peut être dû en partie au fait que UIL ne supporte pas les réponses d'image alors que Picasso et Volley le font par défaut.
aussi, je n'ai pas aimé le système de cache de disque D'UIL. Alors que vous pouvez choisir entre diverses implémentations, je dois souligner qu'à l'heure actuelle, il n'y a aucun moyen de limiter le cache disque UIL à la fois par taille totale et par temps d'expiration de l'entité. Volley et Picasso font ça, et ils utilisent le le temps d'expiration retourné par défaut par le serveur alors que UIL l'ignore.
enfin, UIL vous permet de définir une configuration de chargeur d'image globale qui inclut les implémentations et les paramètres de cache de disque et de mémoire sélectionnés, 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, C'est un non-UIL. D'un autre côté, Volley vous permet d'avoir autant de chargeurs d'image séparés que vous voulez, chacun avec sa propre configuration. Picasso utilise une instance globale par défaut mais vous permet également de construire séparément des instances configurables.
pour résumer: Picasso possède la meilleure API, mais il utilise le cache HTTP global partagé entre toutes les instances HttpURLConnection , qui peut être trop restrictif dans certains cas. Volley a la meilleure performance et la modularité, mais est moins convivial et vous aurez besoin de rédiger un module ou deux pour le faire fonctionner comme vous voulez. Globalement, je les recommande tous les deux contre UIL.
Edit (Dec 18 2014): les choses ont changé depuis que j'ai écrit cette réponse initiale et j'ai estimé 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 (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 fait important, j'ai remarqué que la performance de Picasso et OkHttp a beaucoup amélioré et à mon avis c'est maintenant la solution de chargeur d'image la plus rapide pour Android, période. 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 de bitmap sur le thread de L'interface utilisateur. Picasso est activement développé et soutenu et c'est certainement un grand plus.
Volley n'a pas changé que beaucoup, mais j'ai remarqué deux problèmes avec elle dans l'intervalle:
- parfois sous forte charge, certaines images ne sont plus chargées à cause d'une corruption de cache de disque. Les vignettes
- affichées dans une vue réseau (avec son type d'échelle réglé 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 encore lent (en particulier le cache disque) et son API a tendance à changer assez souvent.
j'ai aussi testé cette nouvelle bibliothèque appelée Glide 3 qui prétend être 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é en combinaison avec OkHttp. Pire, il a causé quelques accidents avec mes applications sous Lollipop quand laissant une activité. Elle dispose encore de 2 avantages par rapport à ses concurrents:
- Il prend en charge les Gif animés décodage
- il place le bitmaps final à échelle réduite dans le cache disque, ce qui signifie que la lecture de retour à partir du cache disque est extrêmement rapide.
Conclusion: je recommande maintenant D'utiliser Picasso + OkHttp parce qu'il offre la meilleure flexibilité, API, performance et stabilité combinés. Si vous avez besoin de GIF support, vous pouvez également envisager Glide.
j'ai mis en œuvre une application qui devrait constamment obtenir et montrer des images de l'internet. J'étais sur le point de programmer un mécanisme de cache d'image, avant qu'un ami me recommande le chargeur d'image universel.
L'UIL est très bon customizable. 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 I 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 en douceur être intégré.
pour moi, Picasso est définitivement L'API à utiliser. Mon expérience avec UIL n'était pas bonne.
je pense Qu'ImageLoader est plus personnalisable et flexible par rapport à la bibliothèque Picasso.