Picasso vs. Imageloader vs. Fresco vs Glide [fechado]

Constatações:

1. Diferença entre o Picasso v / s ImageLoader aqui ...
2. Informações sobre a biblioteca GLIDE aqui ...
3. Agora, recentemente, o Facebook lançou uma nova biblioteca de imagens chamada Fresco

Questões:

1. Qual é a diferença entre o Picasso v / s Imageloader v / s Fresco
2. Quando podemos usar o Glide
3. Qual é a melhor biblioteca para usar.
4. Se cada biblioteca tem seu próprio significado, quais são elas?

Eu sou um dos engenheiros do projeto Fresco. Então, obviamente, sou tendenciosa.

Mas você não precisa aceitar minha palavra. Lançamos um aplicativo de exemplo que permite comparar o desempenho de cinco bibliotecas - Fresco, Picasso, UIL, Glide e Volley Image Loader - lado a lado. Você pode obtê-lo em nosso repositório do GitHub .

Devo também salientar que o Fresco está disponível no Maven Central, como com.facebook.fresco:fresco.

O Fresco oferece recursos que Picasso, UIL e Glide ainda não possuem:

1. As imagens não são armazenadas no heap Java, mas no heap ashmem. Buffers de bytes intermediários também são armazenados no heap nativo. Isso deixa muito mais memória disponível para os aplicativos usarem. Reduz o risco de OutOfMemoryErrors. Também reduz a quantidade de aplicativos de coleta de lixo, o que resulta em melhor desempenho.
2. Imagens JPEG progressivas podem ser transmitidas, como em um navegador da web.
3. As imagens podem ser cortadas em qualquer ponto, não apenas no centro.
4. As imagens JPEG podem ser redimensionadas nativamente. Isso evita o problema de OOM ao tentar reduzir o tamanho de uma imagem.

Existem muitos outros ( consulte nossa documentação ), mas estes são os mais importantes.

Lembre-se de que esta é uma pergunta altamente baseada em opiniões, então parei de fazer fiordes e fiz uma mesa rápida

Agora, a comparação de bibliotecas é difícil porque, em muitos parâmetros, os quatro praticamente fazem a mesma coisa, exceto possivelmente o Fresco, porque há um monte de novas otimizações de nível de memória nele. veja uma comparação para com base na minha experiência.

Tendo usado o Fresco o mínimo, a resposta pode evoluir à medida que continuo a usá-la e compreendê-la para as explorações atuais. O used personallyestá usando a biblioteca pelo menos uma vez em um aplicativo concluído.

* Nota - o Fresco agora suporta GIF, bem como animações WebP

Fontes de afresco | fora do site
(-)
- Tamanho enorme da biblioteca
- Sem retorno de
chamada com os parâmetros de bitmap - O SimpleDraweeView não suporta wrap_content
- Tamanho enorme do cache
(+)
- Carregador de imagens bastante rápido (para imagens pequenas e médias)
- Muita funcionalidade (streaming, ferramentas de desenho, gerenciamento de memória, etc.)
- Possibilidade de configurar diretamente em xml (por exemplo, cantos arredondados)
- Suporte GIF
- Suporte WebP e Animated Webp

Fontes de Picasso | fora do local
(-)
- Carregamento lento de imagens grandes da Internet no ListView
(+)
- Tamanho
minúsculo da biblioteca - Tamanho pequeno do cache
- Uso simples
- A interface do usuário não é congelada
- Suporte à WebP

Glide sources

(-)
- Tamanho grande da biblioteca
(+)
- Tamanho minúsculo do cache
- Simples de usar
- Suporte GIF
- Suporte WebP
- Carregamento rápido de imagens grandes da Internet no ListView
- A interface do usuário não é congelada
- BitmapPool para reutilizar a memória e portanto, eventos menores de GC

Universal imagem Carregador fontes de

(-)
- funcionalidade limitada (processamento de imagem limitada)
- O apoio do projeto parou desde 2015/11/27
(+)
- tamanho Tinny da biblioteca
- Simples em uso

Testado por mim no SGS2 (Android 4.1) (WiFi 8.43 Mbps)
Versões oficiais para Java, não para Xamarin!
19 de outubro de 2015

Eu prefiro usar Glide.
Leia mais aqui .
Como gravar cache no armazenamento externo (cartão SD) com o Glide.

Essas respostas são totalmente minha opinião

Respostas

1. O Picasso é um carregador de imagens fácil de usar, o mesmo vale para o Imageloader. O Fresco usa uma abordagem diferente para o carregamento de imagens, ainda não o usei, mas também me parece mais uma solução para obter imagens da rede e armazená-las em cache, mostrando as imagens. então, o contrário, como Picasso / Imageloader / Glide, que para mim são mais mostrando imagem na tela que também obtém imagens da rede e as armazena em cache.

2. O Glide tenta ser um pouco intercambiável com o Picasso. Acho que, quando eles foram criados, a mentalidade de Picasso era seguir as especificações HTTP e permitir que o servidor decidisse as políticas de cache, o cache de tamanho completo e o redimensionamento sob demanda. O glide é o mesmo em seguir a especificação HTTP, mas tenta ter uma área de memória menor, fazendo algumas suposições diferentes, como armazenar em cache as imagens redimensionadas em vez das imagens em tamanho normal e mostrar imagens com RGB_565 em vez de RGB_8888. Ambas as bibliotecas oferecem personalização completa das configurações padrão.

3. Quanto a qual biblioteca é a melhor para usar, é realmente difícil dizer. Picasso, Glide e Imageloader são bibliotecas bem respeitadas e testadas, fáceis de usar com as configurações padrão. Picasso e Glide exigem apenas 1 linha de código para carregar uma imagem e ter um espaço reservado e uma imagem de erro. Personalizar o comportamento também não exige muito trabalho. O mesmo vale para o Imageloader, que também é uma biblioteca mais antiga do que Picasso e Glide, no entanto, eu não o usei, então não posso dizer muito sobre desempenho / uso de memória / personalizações, mas olhar para o leia-me no github me dá a impressão de que também é. relativamente fácil de usar e configurar. Portanto, ao escolher qualquer uma dessas 3 bibliotecas, você não pode tomar a decisão errada, é mais uma questão de gosto pessoal.Como o SDK do facebook ainda não foi lançado oficialmente no mavenCentral , não uso o facebook sdk desde setembro de 2014 e parece que eles colocaram a primeira versão online no mavenCentral em outubro de 2014. Portanto, levará algum tempo até que possamos obter boa opinião sobre isso.

4. entre as três grandes bibliotecas de nomes, acho que não há diferenças significativas. O único que se destaca é o afresco, mas é porque tem uma abordagem diferente e é novo e não é testado em batalha.

Nem Glide nem Picasso são perfeitos. A maneira como o Glide carrega uma imagem na memória e faz o cache é melhor que o Picasso, que permite que uma imagem seja carregada muito mais rapidamente. Além disso, também ajuda a impedir que um aplicativo saia do popular OutOfMemoryError. O carregamento da animação GIF é um recurso matador fornecido pelo Glide. De qualquer forma, Picasso decodifica uma imagem com melhor qualidade que o Glide.

Qual eu prefiro? Embora eu use o Picasso por muito tempo, devo admitir que agora prefiro o Glide. Mas eu recomendo que você altere o Formato Bitmap para ARGB_8888 e permita que o Glide armazene em cache a imagem em tamanho normal e a redimensione primeiro. O resto seria ótimo para o seu trabalho!

• A contagem de métodos de Picasso e Glide está em 840 e 2678, respectivamente.
• O tamanho de Picasso (v2.5.1) é de cerca de 118 KB, enquanto o Glide (v3.5.2) é de cerca de 430 KB.
• O Glide cria imagens armazenadas em cache por tamanho, enquanto o Picasso salva a imagem completa e a processa. Assim, no carregamento, ela é exibida mais rapidamente com o Glide, mas usa mais memória.
• O Glide usa menos memória por padrão com RGB_565.

+1 Para o Assistente de paleta do Picasso .

Há um post que fala muito sobre o post de Picasso vs Glide

Quero compartilhar com você uma referência que fiz entre Picasso, Universal Image Loader e Glide : https://bit.ly/1kQs3QN

Fresco estava fora da referência porque, para o projeto que eu estava executando o teste, não queríamos refatorar nossos layouts (por causa da visualização Drawee).

O que eu recomendo é o Universal Image Loader devido à sua personalização, consumo de memória e equilíbrio entre tamanho e métodos.

Se você tem um projeto pequeno, eu optaria pelo Glide (ou experimentaria o Fresco).