Solução de cache de imagem local para Android: Square Picasso, Universal Image Loader, Glide, Fresco?

Estou procurando uma biblioteca de carregamento e armazenamento em cache de imagens assíncronas no Android. Eu ia usar o Picasso, mas descobri que o Universal Image Loader é mais popular no GitHub. Alguém sabe sobre essas duas bibliotecas? Um resumo dos prós e contras seria ótimo.

(Todas as minhas imagens estão no disco localmente, então não preciso de rede, portanto, não acho que o Volley seja adequado)

Atualização de setembro de 2018: após vários anos, eu precisava quase a mesma coisa para uma solução de cache de imagem local. Desta vez, o UIL não está em desenvolvimento ativo. Eu comparei as bibliotecas populares e a conclusão é bastante óbvia: basta usar o Glide. É muito mais poderoso e configurável. Anos atrás, tive que fazer um fork e fazer alterações no UIL. O Glide suporta todos os meus casos de uso em termos de estratégia de cache e vários níveis de cache de resolução com chaves personalizadas. Basta usar o Glide!

A comparação de Koushik Dutta é principalmente para referência de velocidade. Sua postagem tocou apenas em coisas muito básicas, e não é específica para imagens locais. Gostaria de compartilhar minhas experiências com Picasso e UIL depois de fazer a pergunta. Tanto o Picasso quanto o UIL podem carregar imagens locais. Experimentei o Picasso primeiro e fiquei feliz, mas depois decidi mudar para o UIL para obter mais opções de personalização.

Picasso:

• A interface fluente de Picasso é boa. Mas pulando por aí com "with", "into", "load" você realmente não sabe o que está por trás da cena. É confuso o que é retornado.

• O Picasso permite que você especifique o tamanho exato do destino. É útil quando você tem pressão de memória ou problemas de desempenho, você pode trocar alguma qualidade de imagem por velocidade.

• As imagens são armazenadas em cache com o tamanho em sua chave, é útil quando você exibe imagens com tamanhos diferentes.

• Você pode personalizar o tamanho do cache de memória. Mas seu cache de disco é apenas para solicitações http. Para imagens locais, se você se preocupa com a velocidade de carregamento, é bom ter um cache de disco de miniaturas para que você não precise ler vários MBs para uma imagem todas as vezes. O Picasso não possui este mecanismo de redimensionamento e salvamento de miniaturas no disco.

• Picasso não expõe o acesso à sua instância de cache. (Você pode controlá-lo ao configurar o Picasso pela primeira vez e mantê-lo por perto ...).

• Às vezes, você deseja ler de forma assíncrona a imagem em um bitmap retornado por um ouvinte. Surpreendentemente, Picasso não tem isso. "fetch ()" não devolve nada. "get ()" é para leitura síncrona e "load ()" é para desenhar uma visualização de forma assíncrona.

• O Picasso tem apenas alguns exemplos simples na página inicial e você terá que ler o javadoc não ordenado para usos avançados.

UIL:

• O UIL usa construtores para personalização. Quase tudo pode ser configurado.

• O UIL não permite que você especifique o tamanho que deseja carregar em uma visualização. Ele usa algumas regras com base no tamanho da visualização. Não é tão flexível quanto Picasso. Não tenho como carregar uma imagem de resolução inferior para reduzir o consumo de memória. (Editar: este comportamento pode ser facilmente modificado ao adicionar um argumento ImageSize no código-fonte e ignorar a verificação do tamanho da visualização)

• O UIL fornece cache de disco personalizável, você pode usar isso para armazenar em cache as miniaturas com o tamanho especificado. Mas não é perfeito. Aqui estão os detalhes . (Editar: se você se preocupa com a velocidade e deseja vários níveis de cache de miniaturas, como meu caso, você pode modificar o código-fonte, deixar o cache de disco usar "memoryKey" e torná-lo sensível ao tamanho)

• Por padrão, o UIL armazena imagens de tamanhos diferentes na memória e pode ser desativado na configuração.

• O UIL expõe a memória auxiliar e o cache de disco que você pode acessar.

• O UIL fornece maneiras flexíveis de obter um bitmap ou carregar em uma visualização.

• UIL é melhor em documentação. O UIL fornece os usos detalhados na página do Github e há um tutorial vinculado.

Sugiro começar com o Picasso, se precisar de mais controle e personalização, vá para o UIL.

Se você ler este post no G + de Koush, obterá soluções claras para suas confusões, coloquei o resumo disso, em que o Android-Universal-Image-Loader é o vencedor para sua exigência!

• O Picasso tem a API de imagem mais legal se você estiver usando uma rede!

• UrlImageViewHelper + AndroidAsync é o mais rápido. Brincar com essas outras duas grandes bibliotecas realmente destacou que a API de imagem é bastante desatualizada.

• O vôlei é liso; Eu realmente gosto de seus transportes de back-end conectáveis
  e posso acabar deixando o AndroidAsync lá. A prioridade de solicitação
  e gerenciamento de cancelamento é ótimo (se você estiver usando rede)

• Android-Universal-Image-Loader é o mais popular que existe
  atualmente. Altamente personalizável.

Este projeto visa fornecer um instrumento reutilizável para carregamento, armazenamento em cache e exibição assíncrona de imagens. Ele é originalmente baseado no projeto de Fedor Vlasov e foi amplamente refeito e melhorado desde então.

Próximas mudanças na nova versão do UIL (1.9.2):

Possibilidade de chamar ImageLoader fora do thread de UINew Disk Cache API (mais flexível). Novo LruDiscCache baseado no DiskLruCache de Jake Wharton.

Considerando todas as suítes do Android-Universal-Image-Loader sua exigência (o carregamento das imagens está no disco localmente )!

Gostaria de compartilhar minha experiência com estas 3 bibliotecas: UIL, Picasso e Volley. Eu já usei o UIL, mas depois cheguei à conclusão de que não posso recomendá-lo e sugeriria usar o Volley ou o Picasso, ambos desenvolvidos por equipes altamente talentosas. O UIL não é ruim, mas carece da atenção aos detalhes das outras duas bibliotecas.

Achei o UIL menos agradável com o desempenho da IU; ele tende a travar o thread da IU mais do que o Volley ou o Picasso. Isso pode ser em parte devido ao fato de que o UIL não oferece suporte para o envio em lote das respostas de imagem, enquanto o Picasso e o Volley fazem isso por padrão.

Além disso, não gostei do sistema de cache de disco do UIL. Embora você possa escolher entre várias implementações, preciso ressaltar que, no momento, não há como limitar o cache de disco UIL tanto pelo tamanho total quanto pelo tempo de expiração da entidade. O Volley e o Picasso fazem isso e usam o tempo de expiração retornado pelo servidor por padrão, enquanto o UIL o ignora.

Finalmente, UIL permite que você defina uma configuração de carregador de imagem global que inclui o cache de disco selecionado e implementações e configurações de cache de memória e outros detalhes, mas essa configuração será aplicada em todos os lugares em seu aplicativo. Portanto, se você precisa de mais flexibilidade, como dois caches de disco separados, não vale a pena usar o UIL. O Volley, por outro lado, permite que você tenha quantos carregadores de imagens separados desejar, cada um com sua própria configuração. O Picasso usa uma instância global por padrão, mas também permite que você crie instâncias configuráveis ​​separadamente.

Resumindo: o Picasso tem a melhor API, mas usa o cache de disco HTTP global compartilhado entre todas as HttpURLConnectioninstâncias, o que pode ser muito restritivo em alguns casos. O Volley tem o melhor desempenho e modularidade, mas é menos amigável e exigirá que você escreva um ou dois módulos próprios para que funcione como você deseja. No geral, eu recomendaria ambos contra o UIL.

Editar (18 de dezembro de 2014): As coisas mudaram desde que escrevi esta resposta inicial e senti que era necessário melhorá-la:

O Picasso 2.4 é ainda mais configurável do que as versões anteriores e, quando usado com OkHttp (o que é altamente recomendado), também pode usar um cache de disco separado para cada instância, portanto, não há realmente nenhuma restrição no que você pode fazer. Mais importante, percebi que o desempenho do Picasso e do OkHttp melhorou muito e, na minha opinião, agora é a solução de carregamento de imagens mais rápida para Android, ponto final. Observe que em meu código eu sempre uso .fit()em combinação com .centerCrop()ou .centerInside()para diminuir o uso de memória e evito redimensionamentos de bitmap no thread de interface do usuário. O Picasso é desenvolvido e suportado ativamente e isso é certamente uma grande vantagem.

Volley não mudou muito, mas percebi dois problemas com ele nesse meio tempo:

• Às vezes, sob carga pesada, algumas imagens não são mais carregadas devido a alguma corrupção do cache de disco.
• As miniaturas exibidas em um NetworkImageView (com seu tipo de escala definido como centerCrop) são bastante borradas em comparação com o que você obtém com as outras bibliotecas.

Por esses motivos, decidi parar de usar o Volley.

O UIL ainda é lento (especialmente o cache de disco) e sua API tende a mudar com frequência.

Eu também testei esta nova biblioteca chamada Glide 3, que afirma ser mais otimizada do que o Picasso com uma API do tipo Picasso. De acordo com minha experiência pessoal, ele é realmente mais lento do que o Picasso e o Volley durante solicitações de rede sob carga pesada, mesmo quando usado em combinação com OkHttp. Pior ainda, isso causou alguns travamentos com meus aplicativos no Lollipop ao sair de uma atividade. Ele ainda tem 2 vantagens sobre seus concorrentes:

• Suporta decodificação de GIFs animados
• Ele coloca os bitmaps de escala reduzida finais no cache de disco, o que significa que a leitura do cache de disco é extremamente rápida.

Conclusão: agora recomendo usar o Picasso + OkHttp porque ele fornece a melhor flexibilidade, API, desempenho e estabilidade combinados. Se precisar de suporte GIF, você também pode considerar o Glide.

Implementei um aplicativo que deve obter e mostrar imagens da internet constantemente. Eu estava prestes a programar um mecanismo de cache de imagens, antes disso um amigo me recomendou o carregador universal de imagens.

O UIL é muito bom personalizável. É tão personalizável que um novato pode facilmente fazer algo errado. No entanto, o UIL estava lento em meu aplicativo e ficou um pouco mais lento. Meu caso de uso foi um ListView com imagens.

Ontem eu estava procurando uma alternativa ao UIL e descobri o Picasso. Picasso foi fácil de integrar e usar: Just Picasso.context(context).load(url).into(imageview)and the image pode ser mais rápido e integrado.

Para mim, o Picasso é definitivamente a API a ser usada. Minha experiência com o UIL não foi boa.

Acho que ImageLoader é mais personalizável e flexível em comparação com a biblioteca do Picasso.