Android에서 비동기 이미지로드 및 캐싱 라이브러리를 찾고 있습니다. Picasso를 사용하려고했지만 Universal Image Loader가 GitHub에서 더 인기가 있다는 것을 알았습니다. 이 두 라이브러리에 대해 아는 사람이 있습니까? 장단점 요약이 좋을 것입니다.
(내 모든 이미지는 로컬 디스크에 있으므로 네트워킹이 필요하지 않으므로 Volley가 적합하지 않다고 생각합니다.)
답변:
2018 년 9 월 업데이트 : 몇 년 후 로컬 이미지 캐싱 솔루션에 거의 동일한 것이 필요했습니다. 이번에는 UIL이 활발히 개발되지 않았습니다. 인기있는 라이브러리를 비교 한 결과, 결론은 당연합니다. Glide를 사용하면됩니다. 훨씬 더 강력하고 구성 가능합니다. 몇 년 전에 UIL을 포크하고 변경해야했습니다. Glide는 캐싱 전략 및 사용자 지정 키를 사용한 여러 수준의 해상도 캐싱 측면에서 모든 사용 사례를 지원합니다. Glide를 사용하십시오!
Koushik Dutta의 비교는 대부분 속도 벤치 마크를위한 것입니다. 그의 게시물은 매우 기본적인 사항만을 다루었으며 지역 이미지에 한정되지 않았습니다. 질문을 한 후 피카소와 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을 선택하십시오.
UIL does not allow you to specify the size you want to load into a view당신이 사용할 수있는 UIL과 함께 .. 100 % 옳지 않다public void displayImage(String uri, ImageAware imageAware, DisplayImageOptions options, ImageSize targetSize, ImageLoadingListener listener, ImageLoadingProgressListener progressListener)
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은이를 무시합니다.
마지막으로 UIL을 사용하면 선택한 디스크 캐시와 메모리 캐시 구현 및 설정 및 기타 세부 정보를 포함하는 전역 이미지 로더 구성을 설정할 수 있지만이 구성은 앱의 모든 곳에 적용됩니다. 따라서 두 개의 개별 디스크 캐시와 같은 더 많은 유연성이 필요한 경우 UIL에 적합하지 않습니다. 반면 Volley를 사용하면 각각 고유 한 구성을 가진 개별 이미지 로더를 원하는만큼 가질 수 있습니다. Picasso는 기본적으로 전역 인스턴스를 사용하지만 별도로 구성 가능한 인스턴스를 빌드 할 수도 있습니다.
요약하자면 Picasso는 최고의 API를 가지고 있지만 모든 HttpURLConnection인스턴스 간에 공유되는 전역 HTTP 디스크 캐시를 사용하므로 경우에 따라 너무 제한적일 수 있습니다. Volley는 최고의 성능과 모듈성을 제공하지만 사용자 친화적이지 않으며 원하는대로 작동하도록 모듈을 직접 작성해야합니다. 전반적으로 UIL에 대해 둘 다 권장합니다.
편집 (2014 년 12 월 18 일) : 이 초기 답변을 작성한 이후 상황이 바뀌었고 개선해야한다고 느꼈습니다.
Picasso 2.4는 이전 릴리스보다 훨씬 더 구성 가능하며 OkHttp (적극 권장)와 함께 사용할 때 각 인스턴스에 대해 별도의 디스크 캐시를 사용할 수 있으므로 수행 할 수있는 작업에 실제로 제한이 없습니다. 더 중요한 것은 Picasso와 OkHttp의 성능이 많이 향상 되었고 제 생각에는 Android를위한 가장 빠른 이미지 로더 솔루션 이라는 것을 알게 되었습니다 . 내 코드에서 항상 사용하는 것이 유의하시기 바랍니다 .fit()와 함께 .centerCrop()또는 .centerInside()UI 스레드의 메모리 사용량과 피할 비트 맵의 크기를 조절을 낮출 수 있습니다. Picasso는 적극적으로 개발되고 지원되며 이는 확실히 큰 장점입니다.
Volley는 그다지 변하지 않았지만 그 동안 두 가지 문제를 발견했습니다.
이러한 이유로 저는 Volley 사용을 중단하기로 결정했습니다.
UIL은 여전히 느리고 (특히 디스크 캐시) API는 자주 변경되는 경향이 있습니다.
또한 Picasso와 유사한 API로 Picasso보다 더 최적화되었다고 주장하는 Glide 3 라는이 새로운 라이브러리를 테스트했습니다 . 내 개인적인 경험에 따르면 OkHttp와 함께 사용하더라도 과부하 상태에서 네트워크 요청 중에 실제로 Picasso 및 Volley보다 느립니다. 더 나쁜 것은 활동을 떠날 때 Lollipop에서 내 앱에 몇 가지 충돌이 발생했습니다. 경쟁사에 비해 여전히 두 가지 장점이 있습니다.
결론 : 최고의 유연성, API, 성능 및 안정성이 결합 된 Picasso + OkHttp를 사용하는 것이 좋습니다. GIF 지원이 필요한 경우 Glide를 고려할 수도 있습니다.
ImageLoader. ImageLoader클래스 를 하위 클래스로 만들기 만하면 됩니다. 여기를 참조하십시오 : github.com/nostra13/Android-Universal-Image-Loader/issues/...
인터넷에서 지속적으로 이미지를 가져와 표시해야하는 앱을 구현했습니다. 친구가 범용 이미지 로더를 추천하기 전에 이미지 캐시 메커니즘을 프로그래밍하려고했습니다.
UIL은 사용자 정의가 매우 좋습니다. 너무 커스터마이징이 가능하여 초보자가 쉽게 무언가를 잘못 만들 수 있습니다. 그러나 UIL은 내 응용 프로그램에서 느리고 약간 느려졌습니다. 내 사용 사례는 이미지가있는 ListView였습니다.
어제 UIL의 대안을 찾고 있었는데 피카소를 발견했습니다. Picasso는 통합과 사용이 쉬웠습니다. 그냥 Picasso.context(context).load(url).into(imageview)이미지가 더 빠르고 원활하게 통합 될 수있었습니다.
저에게 Picasso는 확실히 사용할 API입니다. UIL에 대한 나의 경험은 좋지 않았습니다.