Android 용 로컬 이미지 캐싱 솔루션 : Square Picasso, Universal Image Loader, Glide, Fresco?

Android 용 로컬 이미지 캐싱 솔루션 : Square Picasso, Universal Image Loader, Glide, Fresco?

---

Android에서 비동기 이미지로드 및 캐싱 라이브러리를 찾고 있습니다. Picasso를 사용하려고했지만 Universal Image Loader가 GitHub에서 더 인기가 있다는 것을 알았습니다. 이 두 라이브러리에 대해 아는 사람이 있습니까? 장단점 요약이 좋을 것입니다.

(내 모든 이미지는 로컬 디스크에 있으므로 네트워킹이 필요하지 않으므로 Volley가 적합하지 않다고 생각합니다.)

---

2018 년 9 월 업데이트 : 몇 년 후 로컬 이미지 캐싱 솔루션에 거의 동일한 것이 필요했습니다. 이번에는 UIL이 활발하게 개발되지 않았습니다. 인기있는 라이브러리를 비교 한 결과 결론은 당연합니다. Glide를 사용하면됩니다. 훨씬 더 강력하고 구성 가능합니다. 몇 년 전에 UIL을 포크하고 변경해야했습니다. Glide는 캐싱 전략 및 사용자 지정 키를 사용한 여러 수준의 해상도 캐싱 측면에서 모든 사용 사례를 지원합니다. Glide를 사용하십시오!

Koushik Dutta의 비교는 대부분 속도 벤치 마크를위한 것입니다. 그의 게시물은 매우 기본적인 사항만을 다루었으며 지역 이미지에만 국한되지 않았습니다. 질문을 한 후 Picasso 및 UIL과의 경험을 공유하고 싶습니다. Picasso와 UIL 모두 로컬 이미지를로드 할 수 있습니다. 처음에는 Picasso를 사용해 보았고 기뻤지 만 나중에 더 많은 사용자 정의 옵션을 위해 UIL로 전환하기로 결정했습니다.

피카소 :

• Picasso의 유창한 인터페이스가 좋습니다. 그러나 "with", "into", "load"로 뛰어 다니면 실제로 장면 뒤에 무엇이 있는지 알 수 없습니다. 반환되는 내용이 혼란 스럽습니다.

• Picasso를 사용하면 정확한 대상 크기를 지정할 수 있습니다. 메모리 부족이나 성능 문제가있을 때 유용하며 속도를 위해 일부 이미지 품질을 절충 할 수 있습니다.

• 이미지는 키의 크기와 함께 캐시되며 크기가 다른 이미지를 표시 할 때 유용합니다.

• 메모리 캐시 크기를 사용자 지정할 수 있습니다. 그러나 디스크 캐시는 http 요청 전용입니다. 로컬 이미지의 경우로드 속도에 관심이 있다면 썸네일 디스크 캐시를 사용하는 것이 좋습니다. 따라서 매번 이미지에 대해 몇 MB를 읽을 필요가 없습니다. Picasso에는 디스크에 축소판 크기를 조정하고 저장하는이 메커니즘이 없습니다.

• Picasso는 캐시 인스턴스에 대한 액세스를 노출하지 않습니다. (처음 피카소를 구성하고 보관할 때이를 파악할 수 있습니다 ...).

• 때때로 리스너가 반환 한 비트 맵으로 이미지를 비동기 적으로 읽어야합니다. 놀랍게도 피카소에게는 그런 것이 없습니다. "fetch ()"는 아무것도 전달하지 않습니다. "get ()"은 동기 읽기 용이고 "load ()"는 비동기식 뷰 그리기 용입니다.

• Picasso에는 홈페이지에 몇 가지 간단한 예제 만 있으며 고급 사용을 위해 정렬되지 않은 javadoc을 읽어야합니다.

UIL :

• UIL은 사용자 정의를 위해 빌더를 사용합니다. 거의 모든 것을 구성 할 수 있습니다.

• UIL에서는 뷰에로드 할 크기를 지정할 수 없습니다. 보기의 크기에 따라 몇 가지 규칙을 사용합니다. 피카소만큼 유연하지 않습니다. 메모리 사용량을 줄이기 위해 저해상도 이미지를로드 할 방법이 없습니다. (편집 :이 동작은 소스 코드에 ImageSize 인수를 추가하고보기 크기 검사를 우회하여 쉽게 수정할 수 있습니다.)

• UIL은 사용자 정의 가능한 디스크 캐시를 제공하며이를 사용하여 지정된 크기로 축소판을 캐시 할 수 있습니다. 그러나 그것은 완벽하지 않습니다. 세부 사항 은 다음과 같습니다 . (편집 : 속도에 관심이 있고 저의 경우처럼 여러 수준의 썸네일 캐싱을 원하는 경우 소스 코드를 수정하고 디스크 캐시가 "memoryKey"를 사용하도록하고 크기도 민감하게 만들 수 있습니다.)

• UIL은 기본적으로 메모리에 크기가 다른 이미지를 캐시하며 구성에서 끌 수 있습니다.

• UIL은 액세스 할 수있는 백업 메모리와 디스크 캐시를 노출합니다.

• UIL은 비트 맵을 가져 오거나 뷰에로드 할 수있는 유연한 방법을 제공합니다.

• UIL은 문서에서 더 좋습니다. UIL은 Github 페이지에서 자세한 사용법을 제공하며 링크 된 튜토리얼이 있습니다.

더 많은 제어와 사용자 정의가 필요하면 피카소로 시작하는 것이 좋습니다. UIL을 선택하십시오.

---

Koush의 G + 에서이 게시물 을 읽으면 혼란에 대한 명확한 해결책을 얻을 수 있습니다. 이에 대한 요약은 Android-Universal-Image-Loader가 귀하의 요구 사항에 대한 승자라는 점입니다!

• Picasso 는 네트워크를 사용하는 경우 가장 멋진 이미지 API를 가지고 있습니다!

• UrlImageViewHelper + AndroidAsync 가 가장 빠릅니다. 이 다른 두 개의 훌륭한 라이브러리를 가지고 놀면서 이미지 API가 상당히 오래되었음을 강조했습니다.

• 발리 는 매끄럽다. 나는 그들의 플러그 가능한 백엔드 전송을 정말 좋아하고
  거기에 AndroidAsync를 떨어 뜨릴 수 있습니다. 요청 우선 순위
  및 취소 관리가 좋습니다 (네트워크를 사용하는 경우)

• Android-Universal-Image-Loader 는
  현재가장 인기있는 것입니다. 고도로 사용자 정의 가능.

이 프로젝트는 비동기 이미지로드, 캐싱 및 표시를위한 재사용 가능한 도구를 제공하는 것을 목표로합니다. 원래 Fedor Vlasov의 프로젝트를 기반으로하며 그 이후로 대폭 리팩토링되고 개선되었습니다.

새 UIL 버전 (1.9.2)의 예정된 변경 사항 :

UI 스레드에서 ImageLoader 호출 가능 새 디스크 캐시 API (더 유연함). Jake Wharton의 DiskLruCache를 기반으로 한 새로운 LruDiscCache.

이 모든 Android-Universal-Image-Loader 제품군을 요구 사항으로 고려하십시오 ( 이미지로드는 로컬로 디스크에 있음 )!

---

UIL, Picasso 및 Volley의 세 라이브러리에 대한 경험을 공유하고 싶습니다. 이전에는 UIL을 사용했지만 실제로 권장 할 수 없다는 결론에 도달했으며 대신 뛰어난 재능을 가진 팀이 개발 한 Volley 또는 Picasso를 사용하는 것이 좋습니다. UIL은 전혀 나쁘지 않지만 다른 두 라이브러리의 세부 사항에 대한 관심이 부족합니다.

UIL이 UI 성능에 좋지 않다는 것을 알았습니다. Volley 나 Picasso보다 UI 스레드를 잠그는 경향이 있습니다. 이는 부분적으로 UIL이 이미지 응답을 일괄 처리하는 것을 지원하지 않는 반면 Picasso와 Volley는 기본적으로 그렇게하기 때문일 수 있습니다.

또한 UIL의 디스크 캐시 시스템이 마음에 들지 않았습니다. 다양한 구현을 선택할 수 있지만, 나는 순간에 UIL 디스크 캐시를 제한 할 수있는 방법이 없다는 것을 지적 할 필요가 모두 전체 크기와 엔티티 만료 시간. Volley와 Picasso는이를 수행하며 기본적으로 서버에서 반환 한 만료 시간을 사용하지만 UIL은이를 무시합니다.

Finally, UIL allows you to set a global image loader configuration which includes the selected disk cache and memory cache implementations and settings and other details, but this configuration will be applied everywhere in your app. So if you need more flexibility like two separate disk caches, it's a no go for UIL. Volley on the other hand allows you to have as many separate image loaders as you want, each with its own configuration. Picasso uses a global instance by default but also allows you to build separately configurable instances.

To sum it up: Picasso has the best API but it uses the global HTTP disk cache shared between all HttpURLConnection instances, which can be too restrictive in some cases. Volley has the best performance and modularity but is less user friendly and will require that you write a module or two of your own to make it work like you want. Overall I would recommend them both against UIL.

Edit (Dec 18 2014): Things have changed since I wrote this initial answer and I felt it was necessary to improve it:

Picasso 2.4 is even more configurable than older releases, and when used with OkHttp (which is highly recommended) it is also able to use a separate disk cache for each instance so there is really no restriction in what you can do. More importantly, I noticed that the performance of Picasso and OkHttp has improved a lot and in my opinion it's now the fastest image loader solution for Android, period. Please note that in my code I always use .fit() in combination with .centerCrop() or .centerInside() to lower memory usage and avoid bitmap resizes on the UI thread. Picasso is actively developed and supported and that's certainly a big plus.

Volley hasn't changed that much but I noticed two issues with it in the meantime:

• Sometimes under heavy load, some images are not loaded any more because of some disk cache corruption.
• Thumbnails displayed in a NetworkImageView (with its scale type set to centerCrop) are quite blurry compared to what you get with the other libraries.

For these reasons I decided to stop using Volley.

UIL is still slow (especially the disk cache) and its API has a tendency to change quite often.

I also tested this new library called Glide 3 which claims to be more optimized than Picasso with a Picasso-like API. According to my personal experience it's actually slower than Picasso and Volley during network requests under heavy load, even when used in combination with OkHttp. Worse, it caused a few crashes with my apps under Lollipop when leaving an activity. It still has 2 advantages over its competitors:

• It supports animated GIFs decoding
• It puts the final downscaled bitmaps in the disk cache, which means reading back from the disk cache is extremely fast.

Conclusion: I now recommend to use Picasso + OkHttp because it provides the best flexibility, API, performance and stability combined. If you need GIF support you can also consider Glide.

---

I have implemented an app that should constantly get and show images from the internet. I was about to program an image cache mechanism, before that a friend recommended me the universal image loader.

The UIL is very good customizable. It's so customizable that a newbie can easily make something wrong. However, the UIL was slow in my application and it became a bit slower. My use case was a ListView with images.

Yesterday I was looking for an alternative to the UIL, and I discovered Picasso. Picasso was easy to integrate and to use: Just Picasso.context(context).load(url).into(imageview) and the image could be faster and smoothly be integrated.

For me, Picasso is definitely the API to use. My experience with UIL wasn't good.

---

I think ImageLoader is more customizable and flexible comparing to Picasso library.

참고URL : https://stackoverflow.com/questions/19995007/local-image-caching-solution-for-android-square-picasso-universal-image-loader