谷歌推荐的Android图片加载库(Glide)介绍

2024-06-16 13:08

本文主要是介绍谷歌推荐的Android图片加载库(Glide)介绍,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

本文出自:http://blog.csdn.net/u011733020

原      文:https://inthecheesefactory.com/blog/get-to-know-glide-recommended-by-google/en

在过去的谷歌开发者峰会,谷歌给我们介绍了一个图片加载库,bumptech开发的一个名字叫Glide 的Android图像加载库。它已被用于许多谷歌开源项目,到现在为止,包括谷歌I / O 2014官方应用。它成功地使我感兴趣。我花了一整晚的时间和它玩,并决定分享我的经验,在这个博客。作为一个开始,我必须说,它看起来类似于Picasso90%。更准确的说,我认为这有点像Picasso克隆。

导入Project

Picasso 和Glide 都托管在jcenter。你可以轻松地导入到你的工程通过以下方式:

Picasso

dependencies {compile 'com.squareup.picasso:picasso:2.5.1'
}

Glide

dependencies {compile 'com.github.bumptech.glide:glide:3.5.2'compile 'com.android.support:support-v4:22.0.0'
}

Glide也需要Android Support Library v4,请不要忘记导入support-v4到你的项目中。

首先

就像我说的,跟Picasso非常类似。Glide加载一个图像到ImageView的方式跟Picasso相当一致。

Picasso

Picasso.with(context).load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg").into(ivImg);

Glide

Glide.with(context).load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg").into(ivImg);

虽然它看起来很相同,但在细节上Glide设计得更好,因为with()不仅仅接受只有上下文,也可以接收Activity和Fragment。Context 会从你传递进的参数中自动提取出来

with

并且受益于通过传递Activity/Fragment 给Glide ,那么图片的加载将整合到Activity/Fragment的生命周期,例如,在Stop时停止加载和在Resume时自动恢复状态。所以推荐通过Activity/Fragment而不仅仅只通过Context。

默认加载的Bitmap格式是RGB_565

这是通过Picasso加载Image的结果 (1920x1080 像素的 image 加载到 768x432像素的 ImageView上)

firstload

你可以看到通过Glide加载的Image 比通过Picasso加载的Image质量差一些,这是因为Glide默认的Bitmap格式是 RGB_565 因此相比 ARGB_8888格式节约了50%的内存。

下面是Picasso在ARGB8888 和 Glide 在 RGB565下占用内存的图片(根据app)

Here is the memory consumption graphs between Picasso at ARGB8888 and Glide at RGB565. (当前应用其它大概消耗8MB)

ram1_1

如果你对Image的质量感到满意,你可以不作任何事情,如果你认为当前图片质量对你来说感到不满意,你可以通过  GlideModule 来切换Bitmap格式ARGB_8888 如下所示:

public class GlideConfiguration implements GlideModule {@Overridepublic void applyOptions(Context context, GlideBuilder builder) {// Apply options to the builder here.builder.setDecodeFormat(DecodeFormat.PREFER_ARGB_8888);}@Overridepublic void registerComponents(Context context, Glide glide) {// register ModelLoaders here.}
}

然后在 AndroidManifest.xml  声明 meta-data 

<meta-data android:name="com.inthecheesefactory.lab.glidepicasso.GlideConfiguration"android:value="GlideModule"/>

这看起来相当不错!

quality2

我们在看一下内存使用图表。显而易见 虽然改变Bitmap ARGB_888后Glide消耗内存加倍,但是相比Picasso消耗的内存仍然小很多。 

ram2_1

原因是Picasso加载全分辨率的Image(1920x1080 pixels)到内存,并且让GPU在drawn的过程中做真是的重新计算大小,而此时Glide加载的是当前ImageView的size(768x432 pixels)到内存,这是最佳的方式,尽管,你也可以改变Picasso做同样的事情,通过with resize() 方法:

Picasso.with(this).load("http://nuuneoi.com/uploads/source/playstore/cover.jpg").resize(768, 432).into(ivImgPicasso);

但是这样以来你需要自己计算ImageView的size。或者你的ImageView有一个固定的Size(not wrap_content),你也可以通过如下方式:

Picasso.with(this).load("http://nuuneoi.com/uploads/source/playstore/cover.jpg").fit().centerCrop().into(ivImgPicasso);

此时两种方式占用内存看起来几乎一样了 !

memory3

尽管内存使用接近一致,但是必须要说Glide相比Picasso在这一方面胜出,因为Glide可以自动计算ImageView的大小。

图片质量的细节

这是我湿着缩放ImageView的实际大小.

quality3

值得注意的是,图片加载通过Glide并不象Picasso加载一样光滑。直到现在,我仍然找不到改变的图像缩放算法的正确方式。

但是你问我这很差?,但是你可以通过改变Bitmap格式为ARGB_8888,来解决,这就够了。

磁盘缓存 

默认磁盘缓存 策略 Picasso和Glide是有很大区别的。通过实验,加载全分辨率的Image到ImageView上,然后查看本地缓存文件,会发现Picasso缓存的是全分辨率(1920x1080 pixels)而Glide缓存了与ImageView大小一致的Image(768x432 pixels)和全分辨率的Image(1920x1080 pixels)

cache

同时,前面描述的生硬像素仍然存在,因为,如果Image加载的时候是RGB565方式,那么缓存的Image 也将是RGB565。

当我试着改变ImageView的size,结果是Picasso 仍然是缓存全分辨率的Image,Glide变得不一样,缓存了每一个ImageView size大小的Image。尽管一个Image已经被加载过,但是如果你需要加载另一个size的相同Image,Glide 需要从新下载,然后从新计算大小到正确的size,然后缓存到Cache中。

说的再清楚一些,如果在第一个页面有一个大小为 200x200 pixels dimension 的ImageView,在第二个页面有一个大小为100x100 pixels的ImageView,这两个ImageView加载同一张Image,Glide需要下载两次。

然而你可以通过改变磁盘缓存的策略(让Glide缓存全分辨率和计算后的size)来调整。

        Glide.with(this).load("http://nuuneoi.com/uploads/source/playstore/cover.jpg").diskCacheStrategy(DiskCacheStrategy.ALL).into(ivImgGlide);

下一次Image如果被请求展示在其他ImageView上,全分辨率的Image会从磁盘中加载,然后重新计算,再缓存计算后的size。

Glide设计的这种加载Image的一个优点是,Image可以被加载展示的很快,相比较Picasso的方式,在加载更加耗时,因为在加载到ImageView以前,首先需要resize,尽管你设置以下命令来让它立即展示:

//Picasso
.noFade();

loading3

对于Picasso和Glide在磁盘上的缓存策略,你可以根据你app需要来选择哪一个更适合。

对于我来说,我选择Glide优先于Picasso,尽管Glide占用更多空间来缓存图片,但是它的加载速度比较快。

特点

Glide几乎可以用相同的方式做Picasso可以做的事情,例如改变Image的size 

Image Resizing

// Picasso
.resize(300, 200);// Glide
.override(300, 200);

Center Cropping

// Picasso
.centerCrop();// Glide
.centerCrop();

Transforming

// Picasso
.transform(new CircleTransform())// Glide
.transform(new CircleTransform(context))

设置占位图和加载失败展示图

// Picasso
.placeholder(R.drawable.placeholder)
.error(R.drawable.imagenotfound)// Glide
.placeholder(R.drawable.placeholder)
.error(R.drawable.imagenotfound)

什么是Glide有而Picasso不具备的?

在ImageView上加载GIF动画,可能是Glide最吸引人的地方 ,Picasso并不具备这样的功能.

gifanimation2

既然GlideActivity/Fragment的声明周期下工作完美,那么动画也会根据Activity/Fragment的状态自动的停止和恢复。

Glide的缓存策略是先resize 然后cache。

通过测量发现GIF占用比较大的内存,注意有选择的使用。

除了GIF加载外,Glide也可以加载本地VIDEO略缩图到ImageView。

另外一个有用的特点是,你可以通过Animator (R.animator 来改变你的Image展现方式,与此同时Picasso只有一种动画,淡入(fading in)。

最后你可以在你加载的时候先通过 thumbnail()加载一张缩略图。

实际上 这里还有其他的特点,但是通常我们用不到,比如把Image转为bite数组等等。

配置

你可以配置很多,比如在磁盘缓存的size,最大内存缓存size,Bitmap格式等等。可以通过 Configuration page了解更多。

库的大小

Picasso (v2.5.1)'s size is around 118KB while Glide (v3.5.2)'s is around 430KB.

librarysize

Anyway 312KB difference might not be that significant.

Method count of Picasso and Glide are at 840 and 2678 respectively.

methodcount

I must say 2678 is quite a lot for 65535 methods limit of Android DEX file. ProGuard is recommended to turn on if you choose Glide. (And you should turn it on anyway for production release).

结论

不论Glide还是Picasso都是完美的。Glide加载图片到内存比Picasso快。因此,也帮助app阻止发生OOM。GIF动画加载时Glide 的杀手锏,同时Picasso的图片编码质量要高于Glide 。

该选择哪一个?尽管我已经使用Picasso相当一段时间,但是我必须承认现在我更倾向于Glide。但是我建议你将Bitmap的编码改成 同时设置Glide缓存全分辨率和当前ImageViewsize的Image,这样会让你的工作更好。

更多方法详细介绍点击:http://blog.csdn.net/u011733020/article/details/52319283

资源

There are not so many online resources related to Glide. But here are what I found. Please take a look on links below.

- Glide 3.0: a media management library for Android

- Glide Wiki

- Android Picasso vs Glide

- Android: Image loading libraries Picasso vs Glide

这篇关于谷歌推荐的Android图片加载库(Glide)介绍的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1066537

相关文章

MySQL常用字符串函数示例和场景介绍

《MySQL常用字符串函数示例和场景介绍》MySQL提供了丰富的字符串函数帮助我们高效地对字符串进行处理、转换和分析,本文我将全面且深入地介绍MySQL常用的字符串函数,并结合具体示例和场景,帮你熟练... 目录一、字符串函数概述1.1 字符串函数的作用1.2 字符串函数分类二、字符串长度与统计函数2.1

Android Paging 分页加载库使用实践

《AndroidPaging分页加载库使用实践》AndroidPaging库是Jetpack组件的一部分,它提供了一套完整的解决方案来处理大型数据集的分页加载,本文将深入探讨Paging库... 目录前言一、Paging 库概述二、Paging 3 核心组件1. PagingSource2. Pager3.

从入门到精通详解LangChain加载HTML内容的全攻略

《从入门到精通详解LangChain加载HTML内容的全攻略》这篇文章主要为大家详细介绍了如何用LangChain优雅地处理HTML内容,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录引言:当大语言模型遇见html一、HTML加载器为什么需要专门的HTML加载器核心加载器对比表二

Spring Boot spring-boot-maven-plugin 参数配置详解(最新推荐)

《SpringBootspring-boot-maven-plugin参数配置详解(最新推荐)》文章介绍了SpringBootMaven插件的5个核心目标(repackage、run、start... 目录一 spring-boot-maven-plugin 插件的5个Goals二 应用场景1 重新打包应用

浅析Spring如何控制Bean的加载顺序

《浅析Spring如何控制Bean的加载顺序》在大多数情况下,我们不需要手动控制Bean的加载顺序,因为Spring的IoC容器足够智能,但在某些特殊场景下,这种隐式的依赖关系可能不存在,下面我们就来... 目录核心原则:依赖驱动加载手动控制 Bean 加载顺序的方法方法 1:使用@DependsOn(最直

zookeeper端口说明及介绍

《zookeeper端口说明及介绍》:本文主要介绍zookeeper端口说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、zookeeper有三个端口(可以修改)aVNMqvZ二、3个端口的作用三、部署时注意总China编程结一、zookeeper有三个端口(可以

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

Android ClassLoader加载机制详解

《AndroidClassLoader加载机制详解》Android的ClassLoader负责加载.dex文件,基于双亲委派模型,支持热修复和插件化,需注意类冲突、内存泄漏和兼容性问题,本文给大家介... 目录一、ClassLoader概述1.1 类加载的基本概念1.2 android与Java Class

基于Python实现一个图片拆分工具

《基于Python实现一个图片拆分工具》这篇文章主要为大家详细介绍了如何基于Python实现一个图片拆分工具,可以根据需要的行数和列数进行拆分,感兴趣的小伙伴可以跟随小编一起学习一下... 简单介绍先自己选择输入的图片,默认是输出到项目文件夹中,可以自己选择其他的文件夹,选择需要拆分的行数和列数,可以通过

Knife4j+Axios+Redis前后端分离架构下的 API 管理与会话方案(最新推荐)

《Knife4j+Axios+Redis前后端分离架构下的API管理与会话方案(最新推荐)》本文主要介绍了Swagger与Knife4j的配置要点、前后端对接方法以及分布式Session实现原理,... 目录一、Swagger 与 Knife4j 的深度理解及配置要点Knife4j 配置关键要点1.Spri