Glide和Picasso使用和区别

最新推荐文章于 2025-06-28 15:31:59 发布

張三疯

最新推荐文章于 2025-06-28 15:31:59 发布

阅读量1.2k

点赞数

CC 4.0 BY-SA版权

分类专栏： Android

本文链接：https://blog.youkuaiyun.com/zhangtongyuan0909/article/details/54407308

Android 专栏收录该内容

25 篇文章

订阅专栏

本文详细介绍了Glide和Picasso两个流行的Android图像加载库的使用方法，并深入比较了它们的性能、内存管理和功能差异，帮助开发者选择更适合项目需求的图片加载库。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

. Glide 优点
(1) 图片缓存->媒体缓存
Glide 不仅是一个图片缓存，它支持 Gif、WebP、缩略图。甚至是 Video，所以更该当做一个媒体缓存。
 
(2) 支持优先级处理
 
(3) 与 Activity/Fragment 生命周期一致，支持 trimMemory
Glide 对每个 context 都保持一个 RequestManager，通过 FragmentTransaction 保持与 Activity/Fragment 生命周期一致，并且有对应的 trimMemory 接口实现可供调用。
 
(4) 支持 okhttp、Volley
Glide 默认通过 UrlConnection 获取数据，可以配合 okhttp 或是 Volley 使用。实际 ImageLoader、Picasso 也都支持 okhttp、Volley。
 
(5) 内存友好
① Glide 的内存缓存有个 active 的设计
从内存缓存中取数据时，不像一般的实现用 get，而是用 remove，再将这个缓存数据放到一个 value 为软引用的 activeResources map 中，并计数引用数，在图片加载完成后进行判断，如果引用计数为空则回收掉。
 
② 内存缓存更小图片
Glide 以 url、view_width、view_height、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中，而不是原始图片以节省大小
 
③ 与 Activity/Fragment 生命周期一致，支持 trimMemory
 
④ 图片默认使用默认 RGB_565 而不是 ARGB_888
虽然清晰度差些，但图片更小，也可配置到 ARGB_888。
 
其他：Glide 可以通过 signature 或不使用本地缓存支持 url 过期

使用方法：
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'
	}
//使用
Picasso
		Picasso.with(context)//上下文
		load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")
		into(ivImg);
Glide
		Glide.with(context)//上下文/Activity
		load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")
		into(ivImg);
区别：
虽然两者看起来一样，但是Glide更易用，因为Glide的with方法不光接受Context，还接受Activity 和 Fragment，Context会自动的从他们获取，同时将Activity/Fragment作为with()参数的好处是：图片加载会和Activity/Fragment的生命周期保持一致，比如Paused状态在暂停加载，在Resumed的时候又自动重新加载。所以我建议传参的时候传递Activity 和 Fragment给Glide，而不是Context。

Glide默认的Bitmap格式是RGB_565 ，比ARGB_8888格式的内存开销要小一半。下面是Picasso在ARGB8888下与Glide在RGB565下的内存开销图（应用自身占用了8m，因此以8为基准线比较）：

我们再来看看内存开销图，这次貌似Glide花费了两倍于上次的内存，但是Picasso的内存开销仍然远大于Glide。

原因在于Picasso是加载了全尺寸的图片到内存，然后让GPU来实时重绘大小。而Glide加载的大小和ImageView的大小是一致的，因此更小。当然，Picasso也可以指定加载的图片大小的：
// 指定Picasso的图片大小
Picasso.with(this)
.load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
.resize(768, 432)
.into(ivImgPicasso);
但是问题在于你需要主动计算ImageView的大小，或者说你的ImageView大小是具体的值（而不是wrap_content），你也可以这样：
Picasso.with(this)
.load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
.fit()
.centerCrop()
.into(ivImgPicasso);
现在Picasso的内存开销就和Glide差不多了。 

虽然内存开销差距不到，但是在这个问题上Glide完胜Picasso。因为Glide可以自动计算出任意情况下的ImageView大小。

将ImageView调整成不同大小，但不管大小如何Picasso只缓存一个全尺寸的。Glide则不同，它会为每种大小的ImageView缓存一次。尽管一张图片已经缓存了一次，但是假如你要在另外一个地方再次以不同尺寸显示，需要重新下载，调整成新尺寸的大小，然后将这个尺寸的也缓存起来。
具体说来就是：假如在第一个页面有一个200x200的ImageView，在第二个页面有一个100x100的ImageView，这两个ImageView本来是要显示同一张图片，却需要下载两次。
不过，你可以改变这种行为，让Glide既缓存全尺寸又缓存其他尺寸：
Glide.with(this)
.load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
.diskCacheStrategy(DiskCacheStrategy.ALL)
.into(ivImgGlide);
下次在任何ImageView中加载图片的时候，全尺寸的图片将从缓存中取出，重新调整大小，然后缓存。
Glide的这种方式优点是加载显示非常快。而Picasso的方式则因为需要在显示之前重新调整大小而导致一些延迟，即便你添加了这段代码来让其立即显示：
//Picasso
.noFade();