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 HttpURLConnection
instâ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.