Lokale caching-oplossing voor afbeeldingen voor Android: Square Picasso, Universal Image Loader, Glide, Fresco?

Ik ben op zoek naar een asynchrone bibliotheek voor het laden en cachen van afbeeldingen in Android. Ik ging Picasso gebruiken, maar ik ontdekte dat Universal Image Loader populairder is op GitHub. Kent iemand deze twee bibliotheken? Een samenvatting van de voor- en nadelen zou fijn zijn.

(Al mijn afbeeldingen staan ​​lokaal op schijf, dus ik heb geen netwerk nodig, daarom denk ik niet dat Volley geschikt is)

Antwoord 1, autoriteit 100%

Update sep 2018: na enkele jaren had ik bijna hetzelfde nodig voor een lokale oplossing voor het cachen van afbeeldingen. Deze keer is UIL niet actief in ontwikkeling geweest. Ik heb de populaire bibliotheken vergeleken en de conclusie is vrij logisch: gebruik gewoon Glide. Het is veel krachtiger en configureerbaar. Jaren geleden moest ik een splitsing maken en wijzigingen aanbrengen in UIL. Glide ondersteunt al mijn gebruiksscenario’s op het gebied van cachingstrategie en meerdere niveaus van resolutiecaching met aangepaste sleutels. Gebruik gewoon Glide!

Koushik Dutta’s vergelijking is voornamelijk voor snelheidsbenchmark. Zijn post raakte alleen heel basale dingen en is niet specifiek voor lokale afbeeldingen. Ik wil graag mijn ervaringen met Picasso en UIL delen nadat ik de vraag had gesteld. Zowel Picasso als UIL kunnen lokale afbeeldingen laden. Ik probeerde Picasso voor het eerst en was tevreden, maar later besloot ik over te schakelen naar UIL voor meer aanpassingsopties.

Picasso:

• Picasso’s vloeiende interface is prettig. Maar rondspringend met “met”, “in”, “laden” weet je eigenlijk niet wat er zich achter de schermen afspeelt. Het is verwarrend wat er wordt geretourneerd.

• Picasso stelt u in staat om de exacte doelgrootte op te geven. Het is handig als je geheugendruk of prestatieproblemen hebt, je kunt wat beeldkwaliteit inruilen voor snelheid.

• Afbeeldingen worden in de cache opgeslagen met de grootte in de sleutel, dit is handig wanneer u afbeeldingen met verschillende formaten weergeeft.

• U kunt de grootte van de geheugencache aanpassen. Maar de schijfcache is alleen voor http-verzoeken. Voor lokale afbeeldingen, als u de laadsnelheid belangrijk vindt, is het goed om een ​​miniatuurschijfcache te hebben, zodat u niet elke keer meerdere MB’s voor een afbeelding hoeft te lezen. Picasso heeft dit mechanisme niet om het formaat van miniaturen op schijf te wijzigen en op te slaan.

• Picasso geeft de toegang tot zijn cache-instantie niet vrij. (Je kunt het te pakken krijgen wanneer je Picasso voor het eerst configureert en bijhoudt…).

• Soms wil je een afbeelding asynchroon inlezen in een bitmap die wordt geretourneerd door een luisteraar. Verrassend genoeg heeft Picasso dat niet. “fetch()”-dosis geeft niets terug. “get()” is voor synchroon lezen en “load()” is voor asynchroon tekenen van een weergave.

• Picasso heeft slechts een paar eenvoudige voorbeelden op de startpagina en u zult de ongeordende javadoc moeten doorlezen voor geavanceerd gebruik.

UIL:

• UIL gebruikt builders voor maatwerk. Bijna alles kan worden geconfigureerd.

• UIL staat niet toe dat u de grootte specificeert die u in een weergave wilt laden. Het gebruikt enkele regels op basis van de grootte van de weergave. Het is niet zo flexibel als Picasso. Ik heb geen manier om een ​​afbeelding met een lagere resolutie te laden om de geheugenvoetafdruk te verkleinen. (Bewerken: dit gedrag kan eenvoudig worden gewijzigd door een ImageSize-argument in de broncode toe te voegen en de controle op de weergavegrootte te omzeilen)

• UIL biedt aanpasbare schijfcache, u kunt dit gebruiken om de miniaturen met een opgegeven grootte in de cache te plaatsen. Maar het is niet perfect. Hier zijn de details. (Bewerken: als u snelheid belangrijk vindt en meerdere niveaus van thumbnail-caching wilt, zoals mijn geval, kunt u de broncode wijzigen, de schijfcache “memoryKey” laten gebruiken en deze ook groottegevoelig maken)

• UIL slaat standaard afbeeldingen van verschillende groottes in het geheugen op en kan worden uitgeschakeld in de configuratie.

• UIL onthult het backing-geheugen en de schijfcache waartoe u toegang hebt.

• UIL biedt flexibele manieren om een ​​bitmap te krijgen of naar een weergave te laden.

• UIL is beter in documentatie. UIL geeft het gedetailleerde gebruik op de Github-pagina en er is een gekoppelde tutorial.

Ik raad aan om met Picasso te beginnen, als je meer controle en maatwerk nodig hebt, ga dan voor UIL.

Antwoord 2, autoriteit 89%

Als je ditbericht op Google+ door Koush leest, krijg je duidelijke oplossingen voor je verwarringen, ik heb de samenvatting daarvan geplaatst, in die zin dat Android-Universal-Image-Loader de winnaar is voor uw vereiste!

• Picassoheeft de mooiste afbeelding-API als je netwerk!

• UrlImageViewHelper+ AndroidAsyncis de snelste. Met deze spelen
  andere twee geweldige bibliotheken hebben echt benadrukt dat de afbeeldings-API
  is echter behoorlijk gedateerd.

• Volleyis glad; Ik geniet echt van hun pluggable backend-transporten,
  en kan uiteindelijk AndroidAsync daar laten vallen. De verzoekprioriteit
  en annuleringsbeheer is geweldig (als u een netwerk gebruikt)

• Android-Universal-Image-Loaderis de meest populaire die er is
  momenteel. Zeer aanpasbaar.

Dit project heeft tot doel een herbruikbaar instrument te bieden voor asynchroon
afbeelding laden, cachen en weergeven. Het is oorspronkelijk gebaseerd op Fedor
Vlasov’s project en is sindsdien enorm herzien en verbeterd
dan.

Aanstaande wijzigingen in nieuwe UIL-versie (1.9.2):

Mogelijkheid om ImageLoader aan te roepen vanuit UI-thread Nieuwe schijfcache-API
(flexibeler). Nieuwe LruDiscCache gebaseerd op Jake Wharton’s
DiskLruCache.

Rekening houdend met al deze Android-Universal-Image-Loader voldoet aan uw vereisten (De afbeeldingen worden lokaal op schijf geladen)!

Antwoord 3, autoriteit 56%

Ik wil graag mijn ervaring delen met deze 3 bibliotheken: UIL, Picasso en Volley. Ik gebruikte eerder UIL, maar toen kwam ik tot de conclusie dat ik het niet echt kan aanbevelen en ik zou willen voorstellen om in plaats daarvan Volley of Picasso te gebruiken, die beide zijn ontwikkeld door zeer getalenteerde teams. UIL is helemaal niet slecht, maar het mist de aandacht voor detail van de andere twee bibliotheken.

Ik vond UIL minder mooi met de UI-prestaties; het heeft de neiging om de UI-thread meer op te sluiten dan Volley of Picasso. Dit kan gedeeltelijk te wijten zijn aan het feit dat UIL het batchen van de afbeeldingsreacties niet ondersteunt, terwijl Picasso en Volley dat standaard doen.

Ook hield ik niet van het schijfcachesysteem van UIL. Hoewel je kunt kiezen tussen verschillende implementaties, moet ik je erop wijzen dat er op dit moment geen manier is om de UIL-schijfcache zowelte beperken op totale grootte als op vervaltijd van de entiteit. Volley en Picasso doen dat en ze gebruiken de vervaltijd die standaard door de server wordt geretourneerd, terwijl UIL deze negeert.

Ten slotte kunt u met UIL een algemene configuratie voor het laden van afbeeldingen instellen die de geselecteerde schijfcache en geheugencache-implementaties en instellingen en andere details bevat, maar deze configuratie wordt overal in uw app toegepast. Dus als u meer flexibiliteit nodig hebt, zoals twee afzonderlijke schijfcaches, is UIL niet geschikt. Met Volley daarentegen kun je zoveel afzonderlijke afbeeldingsladers hebben als je wilt, elk met zijn eigen configuratie. Picasso gebruikt standaard een globale instantie, maar u kunt ook afzonderlijk configureerbare instanties bouwen.

Om het samen te vatten: Picasso heeft de beste API, maar het gebruikt de globale HTTP-schijfcache die wordt gedeeld tussen alle HttpURLConnection-instanties, wat in sommige gevallen te beperkend kan zijn. Volley heeft de beste prestaties en modulariteit, maar is minder gebruiksvriendelijk en vereist dat u zelf een of twee modules schrijft om het te laten werken zoals u wilt. Over het algemeen zou ik ze beide aanbevelen tegen UIL.

Bewerken (18 december 2014):Er zijn dingen veranderd sinds ik dit eerste antwoord schreef en ik vond dat het nodig was om het te verbeteren:

Picasso 2.4 is zelfs meer configureerbaar dan oudere releases, en bij gebruik met OkHttp (wat ten zeerste wordt aanbevolen) kan het ook een aparte schijfcache gebruiken voor elke instantie, dus er is geen beperking in wat je kunt doen.
Wat nog belangrijker is, ik heb gemerkt dat de prestaties van Picasso en OkHttp veel zijn verbeterden naar mijn mening is het nu de snelste oplossing voor het laden van afbeeldingen voor Android, punt uit. Houd er rekening mee dat ik in mijn code altijd .fit()gebruik in combinatie met .centerCrop()of .centerInside()om het geheugengebruik te verlagen en vermijd het formaat van bitmaps op de UI-thread. Picasso wordt actief ontwikkeld en ondersteund en dat is zeker een groot pluspunt.

Volley is niet zo veel veranderd, maar ik merkte in de tussentijd twee problemen op:

• Soms onder zware belasting worden sommige afbeeldingen niet meer geladen vanwege een beschadiging van de schijfcache.
• Miniaturen die worden weergegeven in een NetworkImageView (met het schaaltype ingesteld op centerCrop) zijn nogal wazig in vergelijking met wat je krijgt bij de andere bibliotheken.

Om deze redenen heb ik besloten om te stoppen met het gebruik van Volley.

UIL is nog steeds traag (vooral de schijfcache) en de API heeft de neiging nogal vaak te veranderen.

Ik heb ook deze nieuwe bibliotheek getest, genaamd Glide 3, die beweert geoptimaliseerd te zijn dan Picasso met een Picasso -achtige API. Volgens mijn persoonlijke ervaring is het eigenlijk langzamer dan Picasso en Volley tijdens netwerkverzoeken onder zware belasting, zelfs in combinatie met OkHttp. Erger nog, het veroorzaakte een paar crashes met mijn apps onder Lollipop bij het verlaten van een activiteit. Het heeft nog steeds 2 voordelen ten opzichte van zijn concurrenten:

• Het ondersteunt decodering van geanimeerde GIF’s
• Het plaatst de laatste verkleinde bitmaps in de schijfcache, wat betekent dat het teruglezen van de schijfcache extreem snel gaat.

Conclusie:ik raad nu aan om Picasso + OkHttp te gebruiken omdat het de beste flexibiliteit, API, prestaties en stabiliteit biedt. Als je GIF-ondersteuning nodig hebt, kun je ook Glide overwegen.

Antwoord 4, autoriteit 9%

Ik heb een app geïmplementeerd die constant afbeeldingen van internet moet ophalen en weergeven. Ik stond op het punt een afbeeldingscachemechanisme te programmeren, daarvoor raadde een vriend me de universele afbeeldingslader aan.

De UIL is zeer goed aanpasbaar. Het is zo aanpasbaar dat een nieuweling gemakkelijk iets verkeerd kan maken. De UIL was echter traag in mijn toepassing en werd een beetje langzamer. Mijn use case was een ListView met afbeeldingen.

Gisteren was ik op zoek naar een alternatief voor de UIL en ontdekte ik Picasso. Picasso was gemakkelijk te integreren en te gebruiken: gewoon Picasso.context(context).load(url).into(imageview)en de afbeelding kon sneller en soepeler worden geïntegreerd.

Voor mij is Picasso absoluut de API om te gebruiken. Mijn ervaring met UIL was niet goed.

Antwoord 5

Ik denk dat ImageLoader beter aanpasbaar en flexibeler is dan de Picasso-bibliotheek.