Fresco
Fresco是Facebook开源Android平台上一个强大的图片加载库，也是迄今为止Android平台上最强大的图片加载库。
Fresco最显著的特点是具有三级缓存：两级内存缓存和一级磁盘缓存。他的主要特性如下：
- 渐进式地加载JPEG图片。
- 显示GIF和WebPage动画。
- 可扩展，可自定义的图片加载和显示。
- 在Android 4.x和以下的系统上，将图片放在Android内存一个特殊的区域，从而使得应用运行更流畅，同时极大降低出现OutofMemoryError的错误。
优点：相对于其他开源的第三方图片加载库，Fresco拥有更好的内存管理和强大的功能，基本上能满足所有的日常使用场景。
缺点：整体比较大，不过目前的版本已做了拆分，你只需要导入你使用到的功能相关的库。从代码层面来说侵入性太强，体现在要使用它需要用Fresco的组件SimpleDraweeView替换掉Android原生图片显示组件ImageView，这也是很多人不愿意在项目中接入Fresco的主要原因。
1、内存管理
解压后的图片，即Android中的Bitmap，占用大量的内存。大的内存占用势必引发更加频繁的GC。在5.0以下，GC将会显著地引发界面卡顿。
在5.0以下系统，Fresco将图片放到一个特别的内存区域。当然，在图片不显示的时候，占用的内存会自动被释放。这会使得APP更加流畅，减少因图片内存占用而引发的OOM。
2、Image Pipeline
Fresco中设计有一个叫做 Image Pipeline 的模块。它负责从网络，从本地文件系统，本地资源加载图片和管理。为了最大限度节省空间和CPU时间，它含有3级缓存设计（2级内存，1级磁盘）。两个内存缓存为Bitmap缓存和未解码的图片缓存，这样既可以加快图片的加载速度，又能节省内存的占用（解码后的图片就是Bitmap，其占用内存相对未解码的图片数据而言会大很多）。
Image pipeline 负责完成加载图像，变成Android设备可呈现的形式所要经历的大致流程如下:
a、根据Uri在已解码的（Bitmap缓存）内存缓存中查找，找到了则返回Bitmap对象；如果没找到，则开启后台线程开始后续的工作。
b、根据Uri在未解码的内存缓存中查找，若找到了则解码，然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
d、如果在未解码的内存缓存中没找到，则根据Uri在磁盘缓存中查找，若找到了则读取数据（byte数组），并缓存到未解码的内存缓存中，解码、然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
e、如果在磁盘缓存中没找到，则从网络或者本地加载数据。加载完成后，依次缓存到磁盘缓存、未解码的内存缓存中。解码、然后缓存到已解码的内存缓存中，并且返回Bitmap对象。
加载流程.png
3、Drawees
Fresco 中设计有一个叫做 Drawees 模块，负责图片的呈现。它由三个元素组成分别是：
DraweeView 继承于 View, 负责图片的显示。
DraweeHierarchy 用于组织和维护最终绘制和呈现的 Drawable 对象。
DraweeController 负责和ImagePipeline的交互，可以创建一个这个类的实例，来实现对所要显示的图片做更多的控制。
一般情况下，使用 SimpleDraweeView 即可，你可以配置其XML属性来实现各式各样的展示效果。
a、在图片加载完成前显示占位图；
b、在图片加载的过程中显示加载进度图；
c、加载成功后，将占位图或者加载进度图，自动替换为目标图片。
d、加载失败后，它会显示加载失败的图（若没配置加载失败的图，则显示的是占位图）
e、加载失败后，若配置过重试图，则会显示重试图，用户点击可以重新去加载图片（默认配置可重试3次）
f、自定义居中焦点（配合Google提供的服务可以实现人脸识别，经测试国内目前使用不了）
g、显示圆角图、圆形图和圆圈；
h、添加覆盖物（图层叠加）；
j、 实现图片的按下效果；
k、图片的渐进式呈现；（目前只支持Jpeg格式的图片）
x、当图片不再显示在屏幕上时，它会及时地释放内存和空间占用。
4、Fresco目前所支持的图片格式
a、静态图：png、jpg、web
b、动态图：gif、web格式的gif
优点
- 最大的优势在于5.0以下(最低2.3)的bitmap加载。在5.0以下系统，Fresco将图片放到一个特别的内存区域(Ashmem区)
- 大大减少OOM（在更底层的Native层对OOM进行处理，图片将不再占用App的内存）
- 适用于需要高性能加载大量图片的场景
缺点
- 包较大（2~3M）
- 用法复杂
- 底层涉及c++领域，阅读源码深入学习难度大
Glide 与 Picasso
在泰国举行的谷歌开发者论坛上，谷歌为我们介绍了一个名叫 Glide 的图片加载库，作者是bumptech。这个库被广泛的运用在google的开源项目中，包括2014年google I/O大会上发布的官方app。
Glide和Picasso有90%的相似度，准确的说，就是Picasso的克隆版本。但是在细节上还是有不少区别的。
导入库
Picasso
dependencies {
compile 'com.squareup.picasso:picasso:2.5.1'
}
Glide
dependencies {
compile 'com.github.bumptech.glide:glide:4.8.0'
}
使用方法
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更易用，因为Glide的with方法不光接受Context，还接受Activity 和 Fragment，Context会自动的从他们获取。
image
磁盘缓存
Picasso和Glide在磁盘缓存策略上有很大的不同。Picasso缓存的是全尺寸的，而Glide缓存的是跟ImageView尺寸相同的。
有什么Glide可以做而Picasso 做不到
Glide可以加载GIF动态图，而Picasso不能。
因为Glide和Activity/Fragment的生命周期是一致的，因此gif的动画也会自动的随着Activity/Fragment的状态暂停、重放。Glide 的缓存在gif这里也是一样，调整大小然后缓存。
优点
- 多种图片格式的缓存，适用于更多的内容表现形式（如Gif、WebP、缩略图、Video）
- 生命周期集成（根据Activity或者Fragment的生命周期管理图片加载请求）
- 高效处理Bitmap（bitmap的复用和主动回收，减少系统回收压力）
- 高效的缓存策略，灵活（Picasso只会缓存原始尺寸的图片，Glide缓存的是多种规格），加载速度快且内存开销小（默认Bitmap格式的不同，使得内存开销是Picasso的一半）
缺点
- 没有文件缓存
- java heap比Fresco高
结论
经过对比，对于加载跟动图加载，因为Picasso不能加载动图，所以就只需啊哟考虑另外两个了。首先Fresco虽然很强大，但是包很大，依赖很多，使用复杂，并且使用专有的控件SimpleDraweeView来加载图片。Glide使用简单，配置方便，而且从加载速度和性能方面不相上下。对于轻小量级的app来说使用glide比更好的能够符合要求，如果考虑性能更专业图片来讲，推荐使用fresco
PS：根据业务需求采用不能的框架选择，不建议一个项目中使用多种加载框架。
网友评论