在泰国举行的谷歌开发者论坛上，谷歌为我们介绍了一个名叫 Glide 的图片加载库，作者是 bumptech。这个库被广泛的运用在 google 的开源项目中，包括 2014 年 google I/O 大会上发布的官方 app。
它的成功让我非常感兴趣。我花了一整晚的时间把玩，决定分享一些自己的经验。在开始之前我想说，Glide 和 Picasso 有 90%的相似度，准确的说，就是 Picasso 的克隆版本。但是在细节上还是有不少区别的。
导入库
Picasso 和 Glide 都在 jcenter 上。在项目中添加依赖非常简单：
Picasso
|
1
2
3
|
|
Glide
|
1
2
3
4
|
|
Glide 需要依赖Support Library v4，别忘了。其实Support Library v4已经是应用程序的标配了，这不是什么问题。
基础
就如我所说的 Glide 和 Picasso 非常相似，Glide 加载图片的方法和 Picasso 如出一辙。
Picasso
|
1
2
3
|
|
Glide
|
1
2
3
|
|
虽然两者看起来一样，但是 Glide 更易用，因为 Glide 的 with 方法不光接受 Context，还接受 Activity 和 Fragment，Context 会自动的从他们获取。
同 时将 Activity/Fragment 作为 with()参数的好处是：图片加载会和 Activity/Fragment 的生命周期保持一致，比如 Paused 状态在暂停加载，在 Resumed 的时候又自动重新加载。所以我建议传参的时候传递 Activity 和 Fragment 给 Glide，而不是 Context。
默认 Bitmap 格式是 RGB_565
下面是加载图片时和 Picasso 的比较（1920×1080 像素的图片加载到 768×432 的 ImageView 中）
可以看到 Glide 加载的图片质量要差于 Picasso（ps：我看不出来哈），为什么？这是因为 Glide 默认的 Bitmap 格式是
1 | RGB_565 |
，比
1 | ARGB_8888 |
格式的内存开销要小一半。下面是 Picasso 在 ARGB8888 下与 Glide 在 RGB565 下的内存开销图（应用自身占用了 8m，因此以 8 为基准线比较）：
如果你对默认的
1 | RGB_565 |
效果还比较满意，可以不做任何事，但是如果你觉得难以接受，可以创建一个新的
1 | GlideModule |
将 Bitmap 格式转换到
1 | ARGB_8888 |
：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
|
1 | 同时在<code>AndroidManifest.xml |
中将
1 | GlideModule |
定义为
1 | meta-data |
|
1
2
|
|
这样看起来就会好很多。
我们再来看看内存开销图，这次貌似 Glide 花费了两倍于上次的内存，但是 Picasso 的内存开销仍然远大于 Glide。
原因在于 Picasso 是加载了全尺寸的图片到内存，然后让 GPU 来实时重绘大小。而 Glide 加载的大小和 ImageView 的大小是一致的，因此更小。当然，Picasso 也可以指定加载的图片大小的：
|
1
2
3
4
|
|
但是问题在于你需要主动计算 ImageView 的大小，或者说你的 ImageView 大小是具体的值（而不是 wrap_content），你也可以这样：
|
1
2
3
4
5
|
|
现在 Picasso 的内存开销就和 Glide 差不多了。
虽然内存开销差距不到，但是在这个问题上 Glide 完胜 Picasso。因为 Glide 可以自动计算出任意情况下的 ImageView 大小。
Image 质量的细节
这是将 ImageView 还原到真实大小时的比较。
你可以看到，Glide 加载的图片没有 Picasso 那么平滑，我还没有找到一个可以直观改变图片大小调整算法的方法。
但是这并不算什么坏事，因为很难察觉。
磁盘缓存
Picasso 和 Glide 在磁盘缓存策略上有很大的不同。Picasso 缓存的是全尺寸的，而 Glide 缓存的是跟 ImageView 尺寸相同的。
上面提到的平滑度的问题依然存在，而且如果加载的是 RGB565 图片，那么缓存中的图片也是 RGB565。
我 尝试将 ImageView 调整成不同大小，但不管大小如何 Picasso 只缓存一个全尺寸的。Glide 则不同，它会为每种大小的 ImageView 缓存 一次。尽管一张图片已经缓存了一次，但是假如你要在另外一个地方再次以不同尺寸显示，需要重新下载，调整成新尺寸的大小，然后将这个尺寸的也缓存起来。
具体说来就是：假如在第一个页面有一个 200×200 的 ImageView，在第二个页面有一个 100×100 的 ImageView，这两个 ImageView 本来是要显示同一张图片，却需要下载两次。
不过，你可以改变这种行为，让 Glide 既缓存全尺寸又缓存其他尺寸：
|
1
2
3
4
|
|
下次在任何 ImageView 中加载图片的时候，全尺寸的图片将从缓存中取出，重新调整大小，然后缓存。
Glide 的这种方式优点是加载显示非常快。而 Picasso 的方式则因为需要在显示之前重新调整大小而导致一些延迟，即便你添加了这段代码来让其立即显示：
|
1
2
|
|
Picasso 和 Glide 各有所长，你根据自己的需求选择合适的。
对我而言，我更喜欢 Glide，因为它远比 Picasso 快，虽然需要更大的空间来缓存。
特性
你可以做到几乎和 Picasso 一样多的事情，代码也几乎一样。
Image Resizing
|
1
2
3
4
5
|
|
Center Cropping
|
1
2
3
4
5
|
|
Transforming
|
1
2
3
4
5
|
|
设置占位图或者加载错误图：
|
1
2
3
4
5
6
7
|
|
几乎和 Picasso 一样，从 Picasso 转换到 Glide 对你来说就是小菜一碟。
有什么 Glide 可以做而Picasso 做不到
Glide 可以加载 GIF 动态图，而 Picasso 不能。
同时因为 Glide 和 Activity/Fragment 的生命周期是一致的，因此 gif 的动画也会自动的随着 Activity/Fragment 的状态暂停、重放。Glide 的缓存在 gif 这里也是一样，调整大小然后缓存。
但是从我的一次测试结果来看 Glide 动画会消费太多的内存，因此谨慎使用。
除了 gif 动画之外，Glide 还可以将任何的本地视频解码成一张静态图片。
还有一个特性是你可以配置图片显示的动画，而 Picasso 只有一种动画：fading in。
最后一个是可以使用
1 | thumbnail()产生一个你所加载图片的thumbnail。 |
1 | 其实还有一些特性，不过不是非常重要，比如将图像转换成字节数组等。 |
1
配置
1 | 配置 |
有许多可以配置的选项，比如大小，缓存的磁盘位置，最大缓存空间，位图格式等等。可以在这个页面查看这些配置
1 | <a href="https://github.com/bumptech/glide/wiki/Configuration" target="_blank">Configuration</a> |
。
库的大小
Picasso (v2.5.1)的大小约 118kb，而 Glide (v3.5.2)的大小约 430kb。
Anyway 312KB difference might not be that significant.
不过 312kb 的差距并不是很重要。
Picasso 和 Glide 的方法个数分别是 840 和 2678 个。
必须指出，对于 DEX 文件 65535 个方法的限制来说，2678 是一个相当大的数字了。建议在使用 Glide 的时候开启 ProGuard。
总结
Glide 和 Picasso 都是非常完美的库。Glide 加载图像以及磁盘缓存的方式都要优于 Picasso，速度更快，并且 Glide 更有利于减少 OutOfMemoryError 的发生，GIF 动画是 Glide 的杀手锏。不过 Picasso 的图片质量更高。你更喜欢哪个呢？
虽然我使用了很长时间的 Picasso，但是我得承认现在我更喜欢 Glide。我的建议是使用 Glide，但是将 Bitmap 格式换成 ARGB_8888、让 Glide 缓存同时缓存全尺寸和改变尺寸两种。
转载自：Google 推荐的图片加载库 Glide 介绍 – 泡在网上的日子
