Ich suche nach einer asynchronen Bibliothek zum Laden und Zwischenspeichern von Bildern in Android. Ich wollte Picasso verwenden, fand aber, dass Universal Image Loader auf GitHub beliebter ist. Kennt jemand diese beiden Bibliotheken? Eine Zusammenfassung der Vor- und Nachteile wäre großartig.
(Alle meine Bilder befinden sich lokal auf der Festplatte, daher brauche ich kein Netzwerk, daher denke ich nicht, dass Volley passt.)
Antworten:
Update Sep 2018: Nach einigen Jahren brauchte ich fast dasselbe für eine lokale Image-Caching-Lösung. Diesmal war UIL nicht in der aktiven Entwicklung. Ich habe die populären Bibliotheken verglichen und die Schlussfolgerung ist ziemlich einfach: Verwenden Sie einfach Glide. Es ist viel leistungsfähiger und konfigurierbar. Vor Jahren musste ich die UIL ändern. Glide unterstützt alle meine Anwendungsfälle in Bezug auf die Caching-Strategie und das Caching mehrerer Auflösungsstufen mit benutzerdefinierten Schlüsseln. Benutze einfach Glide!
Der Vergleich von Koushik Dutta dient hauptsächlich dem Geschwindigkeits-Benchmark. Sein Beitrag berührte nur sehr grundlegende Dinge und ist nicht spezifisch für lokale Bilder. Ich möchte meine Erfahrungen mit Picasso und UIL teilen, nachdem ich die Frage gestellt habe. Sowohl Picasso als auch UIL können lokale Bilder laden. Ich habe zuerst Picasso ausprobiert und war glücklich, aber später habe ich beschlossen, für weitere Anpassungsoptionen zu UIL zu wechseln.
Picasso:
Picassos fließende Benutzeroberfläche ist nett. Aber wenn Sie mit "mit", "in", "laden" herumspringen, wissen Sie eigentlich nicht, was sich hinter den Kulissen befindet. Es ist verwirrend, was zurückgegeben wird.
Mit Picasso können Sie die genaue Zielgröße angeben. Es ist nützlich, wenn Sie Speicherdruck oder Leistungsprobleme haben. Sie können die Bildqualität gegen die Geschwindigkeit austauschen.
Bilder werden mit der Größe im Schlüssel zwischengespeichert. Dies ist nützlich, wenn Sie Bilder mit unterschiedlichen Größen anzeigen.
Sie können die Größe des Speichercaches anpassen. Der Disc-Cache ist jedoch nur für http-Anforderungen vorgesehen. Wenn Sie bei lokalen Bildern Wert auf die Ladegeschwindigkeit legen, sollten Sie über einen Miniatur-Festplatten-Cache verfügen, damit Sie nicht jedes Mal mehrere MB für ein Bild lesen müssen. Picasso verfügt nicht über diesen Mechanismus zum Ändern der Größe und Speichern von Miniaturansichten auf der Festplatte.
Picasso macht den Zugriff auf seine Cache-Instanz nicht verfügbar. (Sie können es erhalten, wenn Sie Picasso zum ersten Mal konfigurieren und behalten ...).
Manchmal möchten Sie das Bild asynchron in eine von einem Listener zurückgegebene Bitmap lesen. Überraschenderweise hat Picasso das nicht. "fetch ()" gibt nichts zurück. "get ()" dient zum synchronen Lesen und "load ()" zum asynchronen Zeichnen einer Ansicht.
Picasso hat nur einige einfache Beispiele auf der Homepage, und Sie müssen das ungeordnete Javadoc für fortgeschrittene Verwendungen durchlesen.
UIL:
UIL verwendet Builder zur Anpassung. Fast alles kann konfiguriert werden.
Mit UIL können Sie nicht die Größe angeben, die Sie in eine Ansicht laden möchten. Es werden einige Regeln verwendet, die auf der Größe der Ansicht basieren. Es ist nicht so flexibel wie Picasso. Ich habe keine Möglichkeit, ein Bild mit niedrigerer Auflösung zu laden, um den Speicherbedarf zu verringern. (Bearbeiten: Dieses Verhalten kann leicht geändert werden, indem ein ImageSize-Argument in den Quellcode eingefügt und die Überprüfung der Ansichtsgröße umgangen wird.)
UIL bietet einen anpassbaren Disc-Cache. Mit diesem können Sie die Miniaturansichten mit der angegebenen Größe zwischenspeichern. Aber es ist nicht perfekt. Hier sind die Details . (Bearbeiten: Wenn Sie Wert auf Geschwindigkeit legen und mehrere Ebenen für das Zwischenspeichern von Miniaturansichten wünschen, wie in meinem Fall, können Sie den Quellcode ändern, den Festplatten-Cache "memoryKey" verwenden lassen und ihn auch größenabhängig machen.)
UIL speichert standardmäßig Bilder unterschiedlicher Größe im Speicher zwischen und kann in der Konfiguration deaktiviert werden.
UIL macht den Sicherungsspeicher und den Festplatten-Cache verfügbar, auf die Sie zugreifen können.
UIL bietet flexible Möglichkeiten, wie Sie eine Bitmap abrufen oder in eine Ansicht laden können.
UIL ist besser in der Dokumentation. UIL gibt die detaillierten Verwendungen auf der Github-Seite an, und es gibt ein verknüpftes Tutorial.
Ich schlage vor, mit Picasso zu beginnen. Wenn Sie mehr Kontrolle und Anpassung benötigen, wählen Sie UIL.
UIL does not allow you to specify the size you want to load into a viewist nicht 100% richtig .. mit UIL können Sie verwendenpublic void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options, ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener)
Wenn Sie diesen Beitrag auf G + von Koush lesen, erhalten Sie klare Lösungen für Ihre Verwirrungen. Ich habe die Zusammenfassung dazu zusammengestellt, dass Android-Universal-Image-Loader der Gewinner für Ihre Anforderung ist!
Picasso hat die schönste Bild-API, wenn Sie ein Netzwerk verwenden!
UrlImageViewHelper + AndroidAsync ist das schnellste. Das Spielen mit diesen beiden anderen großartigen Bibliotheken hat wirklich gezeigt, dass die Bild-API jedoch ziemlich veraltet ist.
Volley ist glatt; Ich
magdie steckbaren Backend-Transporte sehrund werde möglicherweise AndroidAsync dort ablegen. Das Anforderungsprioritäts-
und Stornierungsmanagement ist großartig (wenn Sie das Netzwerk verwenden).
Android-Universal-Image-Loader ist derzeit der beliebteste
. Sehr anpassbar.
Dieses Projekt zielt darauf ab, ein wiederverwendbares Instrument zum asynchronen Laden, Zwischenspeichern und Anzeigen von Bildern bereitzustellen. Es basiert ursprünglich auf Fedor Vlasovs Projekt und wurde seitdem umfassend überarbeitet und verbessert.
Bevorstehende Änderungen in der neuen UIL-Version (1.9.2):
Möglichkeit, ImageLoader über die UI-ThreadNew Disk Cache-API aufzurufen (flexibler). Neuer LruDiscCache basierend auf Jake Whartons DiskLruCache.
In Anbetracht all dieser Android-Universal-Image-Loader entspricht dies Ihren Anforderungen (das Laden der Bilder erfolgt lokal auf der Festplatte )!
Ich möchte meine Erfahrungen mit diesen 3 Bibliotheken teilen: UIL, Picasso und Volley. Ich habe früher UIL verwendet, bin dann aber zu dem Schluss gekommen, dass ich es nicht wirklich empfehlen kann, und ich würde vorschlagen, stattdessen Volley oder Picasso zu verwenden, die beide von hochtalentierten Teams entwickelt wurden. UIL ist überhaupt nicht schlecht, aber es fehlt die Liebe zum Detail der beiden anderen Bibliotheken.
Ich fand UIL weniger gut mit der UI-Leistung; Es neigt dazu, den UI-Thread mehr als Volley oder Picasso zu blockieren. Dies kann teilweise auf die Tatsache zurückzuführen sein, dass UIL das Stapeln der Bildantworten nicht unterstützt, während Picasso und Volley dies standardmäßig tun.
Außerdem hat mir das Disk-Cache-System von UIL nicht gefallen. Obwohl Sie zwischen verschiedenen Implementierungen wählen können, muss ich darauf hinweisen, dass es derzeit keine Möglichkeit gibt, den UIL-Festplatten-Cache sowohl nach Gesamtgröße als auch nach Ablaufzeit der Entität zu begrenzen . Volley und Picasso tun dies und verwenden standardmäßig die vom Server zurückgegebene Ablaufzeit, während UIL sie ignoriert.
Schließlich können Sie mit UIL eine globale Image Loader-Konfiguration festlegen, die die ausgewählten Implementierungen und Einstellungen für den Festplatten-Cache und den Speicher-Cache sowie weitere Details enthält. Diese Konfiguration wird jedoch überall in Ihrer App angewendet. Wenn Sie also mehr Flexibilität wie zwei separate Festplatten-Caches benötigen, ist UIL kein Problem. Mit Volley hingegen können Sie so viele separate Bildlader verwenden, wie Sie möchten, jeder mit seiner eigenen Konfiguration. Picasso verwendet standardmäßig eine globale Instanz, ermöglicht Ihnen jedoch auch das Erstellen separat konfigurierbarer Instanzen.
Um es zusammenzufassen: Picasso hat die beste API, verwendet jedoch den globalen HTTP-Festplatten-Cache, der von allen HttpURLConnectionInstanzen gemeinsam genutzt wird, was in einigen Fällen zu restriktiv sein kann. Volley bietet die beste Leistung und Modularität, ist jedoch weniger benutzerfreundlich und erfordert, dass Sie ein oder zwei eigene Module schreiben, damit es wie gewünscht funktioniert. Insgesamt würde ich beide gegen UIL empfehlen.
Bearbeiten (18. Dezember 2014): Die Dinge haben sich geändert, seit ich diese erste Antwort geschrieben habe und ich dachte, dass es notwendig ist, sie zu verbessern:
Picasso 2.4 ist noch konfigurierbarer als ältere Versionen. Wenn es mit OkHttp verwendet wird (was sehr zu empfehlen ist), kann es auch einen separaten Festplatten-Cache für jede Instanz verwenden, sodass Sie wirklich keine Einschränkungen haben. Noch wichtiger ist, dass ich festgestellt habe, dass sich die Leistung von Picasso und OkHttp stark verbessert hat und meiner Meinung nach jetzt die schnellste Image Loader-Lösung für Android ist. Bitte beachten Sie, dass ich in meinem Code immer .fit()in Kombination mit .centerCrop()oder .centerInside()zur Verringerung der Speichernutzung verwende und Bitmap-Größenänderungen im UI-Thread vermeide. Picasso wird aktiv entwickelt und unterstützt und das ist sicherlich ein großes Plus.
Volley hat sich nicht so sehr verändert, aber ich habe in der Zwischenzeit zwei Probleme damit bemerkt:
Aus diesen Gründen habe ich beschlossen, Volley nicht mehr zu verwenden.
UIL ist immer noch langsam (insbesondere der Festplatten-Cache) und seine API ändert sich häufig.
Ich habe auch diese neue Bibliothek namens Glide 3 getestet, die behauptet, mit einer Picasso-ähnlichen API optimierter zu sein als Picasso. Nach meiner persönlichen Erfahrung ist es bei Netzwerkanforderungen unter hoher Last tatsächlich langsamer als Picasso und Volley, selbst wenn es in Kombination mit OkHttp verwendet wird. Schlimmer noch, es hat einige Abstürze mit meinen Apps unter Lollipop verursacht, als ich eine Aktivität verlassen habe. Es hat noch 2 Vorteile gegenüber seinen Konkurrenten:
Fazit: Ich empfehle jetzt die Verwendung von Picasso + OkHttp, da es die beste Flexibilität, API, Leistung und Stabilität in Kombination bietet. Wenn Sie GIF-Unterstützung benötigen, können Sie auch Glide in Betracht ziehen.
ImageLoaderKlassen und Konfigurationen , wie Sie möchten. Sie müssen nur die ImageLoaderKlasse unterordnen . Siehe hier: github.com/nostra13/Android-Universal-Image-Loader/issues/…
Ich habe eine App implementiert, die ständig Bilder aus dem Internet abrufen und anzeigen soll. Ich wollte gerade einen Bild-Cache-Mechanismus programmieren, bevor mir ein Freund den universellen Bildlader empfahl.
Die UIL ist sehr gut anpassbar. Es ist so anpassbar, dass ein Neuling leicht etwas falsch machen kann. Die UIL war jedoch in meiner Anwendung langsam und wurde etwas langsamer. Mein Anwendungsfall war eine ListView mit Bildern.
Gestern habe ich nach einer Alternative zur UIL gesucht und Picasso entdeckt. Picasso war einfach zu integrieren und zu verwenden: Nur Picasso.context(context).load(url).into(imageview)und das Bild konnte schneller und reibungsloser integriert werden.
Für mich ist Picasso definitiv die API. Meine Erfahrung mit UIL war nicht gut.