Solusi cache gambar lokal untuk Android: Square Picasso, Universal Image Loader, Glide, Fresco?


89

Saya mencari pemuatan gambar dan pustaka caching asinkron di Android. Saya akan menggunakan Picasso, tetapi saya menemukan Universal Image Loader lebih populer di GitHub. Adakah yang tahu tentang dua perpustakaan ini? Ringkasan pro dan kontra akan sangat bagus.

(Semua gambar saya ada di disk secara lokal, jadi saya tidak perlu jaringan, oleh karena itu menurut saya Volley tidak cocok)

Jawaban:


80

Perbarui Sep 2018: Setelah beberapa tahun, saya membutuhkan hal yang hampir sama untuk solusi cache gambar lokal. Saat ini UIL belum aktif dalam pengembangan. Saya membandingkan perpustakaan populer, dan kesimpulannya cukup mudah: cukup gunakan Glide. Ini jauh lebih kuat dan dapat dikonfigurasi. Bertahun-tahun yang lalu saya harus bercabang dan membuat perubahan pada UIL. Glide mendukung semua kasus penggunaan saya dalam hal strategi cache dan berbagai level cache resolusi dengan kunci kustom. Cukup gunakan Glide!

Perbandingan Koushik Dutta sebagian besar untuk patokan kecepatan. Postingannya hanya menyentuh hal-hal yang sangat mendasar, dan tidak spesifik untuk gambar lokal. Saya ingin berbagi pengalaman saya dengan Picasso dan UIL setelah saya mengajukan pertanyaan. Picasso dan UIL dapat memuat gambar lokal. Saya pertama kali mencoba Picasso dan senang, tetapi kemudian saya memutuskan untuk beralih ke UIL untuk lebih banyak opsi penyesuaian.

Picasso:

  • Antarmuka Picasso yang fasih bagus. Tapi melompat-lompat dengan "dengan", "ke", "memuat" Anda sebenarnya tidak tahu apa yang ada di balik layar. Membingungkan apa yang dikembalikan.

  • Picasso memungkinkan Anda menentukan ukuran target yang tepat. Ini berguna ketika Anda memiliki masalah tekanan memori atau kinerja, Anda dapat menukar beberapa kualitas gambar dengan kecepatan.

  • Gambar di-cache dengan ukuran pada kuncinya, ini berguna saat Anda menampilkan gambar dengan ukuran berbeda.

  • Anda dapat menyesuaikan ukuran cache memori. Tetapi cache disknya hanya untuk permintaan http. Untuk gambar lokal, jika Anda peduli dengan kecepatan memuat, ada baiknya memiliki cache disk thumbnail sehingga Anda tidak perlu membaca beberapa MB untuk sebuah gambar setiap saat. Picasso tidak memiliki mekanisme ini untuk mengubah ukuran dan menyimpan thumbnail pada disk.

  • Picasso tidak memperlihatkan akses ke contoh cache-nya. (Anda bisa mendapatkannya saat pertama kali mengkonfigurasi Picasso dan menyimpannya di sekitar ...).

  • Terkadang Anda ingin membaca gambar secara asinkron menjadi bitmap yang dikembalikan oleh pendengar. Anehnya Picasso tidak memilikinya. "fetch ()" tidak mengembalikan apapun. "get ()" untuk pembacaan sinkron, dan "load ()" untuk menggambar tampilan secara asinkron.

  • Picasso hanya memiliki beberapa contoh sederhana di beranda, dan Anda harus membaca javadoc tak berurutan untuk penggunaan lanjutan.

UIL:

  • UIL menggunakan pembangun untuk kustomisasi. Hampir semuanya bisa dikonfigurasi.

  • UIL tidak mengizinkan Anda menentukan ukuran yang ingin Anda muat ke dalam tampilan. Ini menggunakan beberapa aturan berdasarkan ukuran tampilan. Ini tidak sefleksibel Picasso. Saya tidak punya cara untuk memuat gambar beresolusi lebih rendah untuk mengurangi jejak memori. (Sunting: perilaku ini dapat dengan mudah dimodifikasi dengan menambahkan argumen ImageSize di dalam kode sumber dan melewati pemeriksaan ukuran tampilan)

  • UIL menyediakan cache disk yang dapat disesuaikan, Anda dapat menggunakannya untuk menyimpan thumbnail dengan ukuran tertentu. Tapi itu tidak sempurna. Berikut detailnya . (Sunting: jika Anda peduli dengan kecepatan dan menginginkan beberapa tingkat cache thumbnail, seperti kasus saya, Anda dapat memodifikasi kode sumber, biarkan cache disk menggunakan "memoryKey", dan membuatnya juga sensitif terhadap ukuran)

  • UIL secara default menyimpan gambar dengan ukuran berbeda dalam memori, dan dapat dimatikan dalam konfigurasi.

  • UIL memperlihatkan memori cadangan dan cache disk yang dapat Anda akses.

  • UIL menyediakan cara fleksibel untuk mendapatkan bitmap atau memuat ke tampilan.

  • UIL lebih baik dalam dokumentasi. UIL memberikan penggunaan rinci di halaman Github, dan ada tutorial yang ditautkan.

Saya sarankan memulai dengan Picasso, jika Anda membutuhkan lebih banyak kontrol dan penyesuaian, gunakan UIL.


Saya benar-benar terjebak di antara mereka berdua ... Pada dasarnya saya akan mengembalikan gambar dari server saya yang disimpan di direktori di sana ... jadi melalui panggilan http dan kemudian menyimpannya untuk caching (thumbnail dan ukuran biasa, saya mungkin akan menyimpan kedua ukuran di direktori saya) ... apakah picasso cara untuk pergi?
Lion789

@ Lion789 Picasso hanya melakukan cache memori lokal untuk file lokal, dan menggunakan HttpResponseCache untuk cache disk jaringan, Anda harus memeriksanya. UIL memiliki cache disk yang dapat dikonfigurasi, Anda dapat membuat beberapa perubahan kecil agar dapat menerima ukuran gambar / thumbnail yang berbeda. Mungkin coba Picasso dulu, jika Anda merasa terlalu terbatas, gunakan UIL dan sesuaikan
XY

Jadi Picasso dapat memuat gambar yang lebih kecil! Maka saya tidak perlu memuat yang 8 megapiksel! Terima kasih, Anda membantu saya!
Aron Lorincz

Bisakah Anda menjawab pertanyaan ini? stackoverflow.com/questions/35433895/…
Usman Rana

UIL does not allow you to specify the size you want to load into a viewtidak 100% benar .. dengan UIL Anda dapat menggunakanpublic void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options, ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener)
Martin Mlostek

72

Jika Anda membaca posting ini di G + oleh Koush, Anda akan mendapatkan solusi yang jelas untuk kebingungan Anda, saya telah merangkumnya, karena Android-Universal-Image-Loader adalah pemenang untuk kebutuhan Anda!

  • Picasso memiliki API gambar terbaik jika Anda menggunakan jaringan!

  • UrlImageViewHelper + AndroidAsync adalah yang tercepat. Bermain dengan dua pustaka hebat lainnya ini benar-benar menyoroti bahwa API gambar cukup kuno.

  • Bola voli licin; Saya sangat menikmati transportasi backend yang dapat dicolokkan,
    dan mungkin akhirnya menjatuhkan AndroidAsync di sana. Prioritas permintaan
    dan manajemen pembatalan bagus (jika Anda menggunakan jaringan)

  • Android-Universal-Image-Loader adalah yang paling populer
    saat ini. Sangat dapat disesuaikan.

Proyek ini bertujuan untuk menyediakan instrumen yang dapat digunakan kembali untuk memuat, menyimpan, dan menampilkan gambar secara asinkron. Ini awalnya didasarkan pada proyek Fedor Vlasov dan telah banyak difaktor ulang dan ditingkatkan sejak saat itu.

Perubahan mendatang dalam versi UIL baru (1.9.2):

Kemungkinan untuk memanggil ImageLoader dari UI threadNew Disk Cache API (lebih fleksibel). LruDiscCache baru berdasarkan DiskLruCache milik Jake Wharton.

Mempertimbangkan semua Android-Universal-Image-Loader ini memenuhi kebutuhan Anda ( Memuat gambar ada di disk secara lokal )!


Saya mulai dengan Picasso dan akhirnya beralih ke Universal, meskipun semuanya telah diterapkan sepenuhnya. Picasso memiliki antarmuka api yang lebih baik tetapi juga memiliki banyak masalah. Yang ini adalah paku terakhir di peti mati.
Lisandro

45

Saya ingin berbagi pengalaman saya dengan 3 perpustakaan ini: UIL, Picasso, dan Volley. Saya sebelumnya menggunakan UIL tetapi kemudian saya sampai pada kesimpulan bahwa saya tidak dapat merekomendasikannya dan saya akan menyarankan untuk menggunakan Volley atau Picasso sebagai gantinya yang keduanya dikembangkan oleh tim yang sangat berbakat. UIL sama sekali tidak buruk tetapi kurang memperhatikan detail dari dua perpustakaan lainnya.

Saya menemukan UIL kurang bagus dengan kinerja UI; itu cenderung mengunci utas UI lebih dari Volley atau Picasso. Ini mungkin sebagian karena UIL tidak mendukung pengelompokan tanggapan gambar sementara Picasso dan Volley melakukannya secara default.

Selain itu, saya tidak menyukai sistem cache disk UIL. Meskipun Anda dapat memilih di antara berbagai penerapan, saya perlu menunjukkan bahwa saat ini tidak ada cara untuk membatasi cache disk UIL keduanya berdasarkan ukuran total maupun waktu kedaluwarsa entitas. Volley dan Picasso melakukan itu, dan mereka menggunakan waktu kedaluwarsa yang dikembalikan oleh server secara default sementara UIL mengabaikannya.

Terakhir, UIL memungkinkan Anda menyetel konfigurasi pemuat gambar global yang menyertakan cache disk yang dipilih dan implementasi serta setelan cache memori dan detail lainnya, tetapi konfigurasi ini akan diterapkan di mana saja di aplikasi Anda. Jadi jika Anda membutuhkan lebih banyak fleksibilitas seperti dua cache disk yang terpisah, UIL tidak boleh digunakan. Volley di sisi lain memungkinkan Anda memiliki pemuat gambar terpisah sebanyak yang Anda inginkan, masing-masing dengan konfigurasinya sendiri. Picasso menggunakan contoh global secara default tetapi juga memungkinkan Anda membuat contoh yang dapat dikonfigurasi secara terpisah.

Singkatnya: Picasso memiliki API terbaik tetapi menggunakan cache disk HTTP global yang digunakan bersama di antara semua HttpURLConnectioncontoh, yang dapat menjadi terlalu terbatas dalam beberapa kasus. Volley memiliki kinerja dan modularitas terbaik tetapi kurang ramah pengguna dan akan mengharuskan Anda menulis satu atau dua modul sendiri untuk membuatnya berfungsi seperti yang Anda inginkan. Secara keseluruhan saya akan merekomendasikan mereka berdua terhadap UIL.

Sunting (18 Des 2014): Banyak hal telah berubah sejak saya menulis jawaban awal ini dan saya merasa perlu untuk memperbaikinya:

Picasso 2.4 bahkan lebih dapat dikonfigurasi daripada rilis sebelumnya, dan bila digunakan dengan OkHttp (yang sangat disarankan), Picasso juga dapat menggunakan cache disk yang terpisah untuk setiap kejadian sehingga tidak ada batasan dalam apa yang dapat Anda lakukan. Lebih penting lagi, saya perhatikan bahwa kinerja Picasso dan OkHttp telah meningkat pesat dan menurut saya sekarang ini adalah solusi pemuat gambar tercepat untuk Android, titik. Harap dicatat bahwa dalam kode saya, saya selalu menggunakan .fit()kombinasi dengan .centerCrop()atau .centerInside()untuk menurunkan penggunaan memori dan menghindari perubahan ukuran bitmap pada thread UI. Picasso secara aktif dikembangkan dan didukung dan itu tentu saja merupakan nilai tambah yang besar.

Volley tidak banyak berubah tetapi saya melihat dua masalah dengannya sementara itu:

  • Terkadang di bawah beban berat, beberapa gambar tidak dimuat lagi karena beberapa kerusakan cache disk.
  • Thumbnail yang ditampilkan di NetworkImageView (dengan tipe skalanya disetel ke centerCrop) cukup kabur dibandingkan dengan apa yang Anda dapatkan dengan pustaka lain.

Untuk alasan ini saya memutuskan untuk berhenti menggunakan Volley.

UIL masih lambat (terutama cache disk) dan API-nya cenderung sering berubah.

Saya juga menguji perpustakaan baru ini yang disebut Glide 3 yang mengklaim lebih dioptimalkan daripada Picasso dengan API mirip Picasso. Menurut pengalaman pribadi saya, ini sebenarnya lebih lambat daripada Picasso dan Volley selama permintaan jaringan di bawah beban berat, bahkan ketika digunakan dalam kombinasi dengan OkHttp. Lebih buruk lagi, itu menyebabkan beberapa crash dengan aplikasi saya di bawah Lollipop saat meninggalkan suatu aktivitas. Ini masih memiliki 2 keunggulan dibandingkan pesaingnya:

  • Ini mendukung decoding GIF animasi
  • Ini menempatkan bitmap downscaled terakhir di cache disk, yang berarti membaca kembali dari cache disk sangat cepat.

Kesimpulan: Sekarang saya merekomendasikan untuk menggunakan Picasso + OkHttp karena memberikan fleksibilitas terbaik, API, kinerja dan stabilitas gabungan. Jika Anda membutuhkan dukungan GIF, Anda juga dapat mempertimbangkan Glide.


1
Untuk membahas poin terakhir Anda di UIL, Anda dapat membuat ImageLoaderkelas dan konfigurasi yang berbeda sebanyak yang Anda inginkan. Anda hanya perlu membuat subclass ImageLoaderkelas. Lihat di sini: github.com/nostra13/Android-Universal-Image-Loader/issues/…
TalkLittle

Sepertinya retasan, tetapi terima kasih atas tipnya, senang mengetahuinya.
BladeCoder

3
Tidak dapat mengatakan saya setuju dengan sentimen, kami menggunakan Picasso di sini, saya memiliki album dengan 500+ gambar resolusi tinggi, dan saya mengalami masalah kinerja dan memori, mencoba UIL dan semuanya langsung terselesaikan. Ini adalah sampel minimal yang mengisolasi masalah yang kami lihat.
HaMMeReD

Jika Anda menampilkan gambar yang memiliki resolusi jauh lebih tinggi daripada layar atau banyak gambar kecil dari gambar beresolusi tinggi, Anda harus menurunkan sampelnya. Saya pikir UIL melakukan ini secara otomatis dan Picasso tidak melakukannya jika Anda tidak menentukan opsi yang tepat, karenanya masalah memori. Saya pribadi lebih suka menggunakan NetworkImageView di Volley, ini adalah widget yang menurunkan sampel gambar yang dimuat ke ukurannya sendiri.
BladeCoder

Di UIL, kelas DisplayImageOptions dapat digunakan jika kita tidak ingin mengubah atau menerapkan beberapa pemrosesan lain pada gambar tertentu.
Rahul Rastogi

7

Saya telah mengimplementasikan aplikasi yang seharusnya mendapatkan dan menampilkan gambar secara konstan dari internet. Saya akan memprogram mekanisme cache gambar, sebelumnya seorang teman merekomendasikan saya pemuat gambar universal.

UIL dapat disesuaikan dengan sangat baik. Ini sangat dapat disesuaikan sehingga seorang pemula dapat dengan mudah melakukan kesalahan. Namun, UIL dalam aplikasi saya lambat dan menjadi sedikit lebih lambat. Kasus penggunaan saya adalah ListView dengan gambar.

Kemarin saya mencari alternatif untuk UIL, dan saya menemukan Picasso. Picasso mudah diintegrasikan dan digunakan: Tepat Picasso.context(context).load(url).into(imageview)dan gambar dapat diintegrasikan dengan lebih cepat dan lancar.

Bagi saya, Picasso jelas merupakan API yang akan digunakan. Pengalaman saya dengan UIL tidak bagus.


Untuk pembaca masa depan: Lebih baik dari picasso adalah Glide. Lihat
prashant

0

Saya pikir ImageLoader lebih dapat disesuaikan dan fleksibel dibandingkan dengan perpustakaan Picasso.


8
Bagaimana? sedikit penjelasan akan membantu.
Darpan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.