关于 Fresco 和 Glide，真的和你想的同样吗

网上对于 Fresco 的讨论通常都是说 Fresco 性能更好，Glide 使用更简单。然而这个问题的答案真的有那么明显吗？web

好比性能问题。Fresco 性能真的比 Glide 好多少吗？毕竟 Fresco 包更大，线程开得也更多，图片重采样也要手动提供 ResizeOptions。此外，Fresco 分配用于缓存的内存也更大，若是不是主动指定 Bitmap.Config 不然不会启用 HARDWARE 格式。其中，我最介意的是必需要手动提供 ResizeOptions 才能执行重采样，但每每须要手动执行的都是不靠谱的，若是开发人员素质不够，或者没注意，那么在加载大图时就很容易致使内存问题。因此，从性能的角度上说，特别若是是面向 5.0 以上的设备，我的认为 Glide 反而更好用、更安全一些。算法

而与此同时，Glide 的使用真的比 Fresco 更简单吗？的确，若是要使用 Java 代码自定义图片请求，那么，Fresco 的确比 Glide 复杂不少。然而，大多数状况下，Fresco 使用 SimpleDraweeView 便可完成图片请求，同时附加圆角、placeholder、宽高比等功能，若是自定义一个通用的 style，Fresco 代码量反而可以比 Glide 少不少。而 Glide 则每次都要 with、load、into，宽高比等功能也要本身实现，圆角的功能也不支持自定义上下左右不一样位置使用不一样的半径，还要本身建立一个 RoundedCorners 对象，而不是直接设置便可，代码写起来反而更麻烦一些。数组

总的来讲，Fresco 功能更丰富，好比圆角、宽高比、渐进式加载 JPEG、在加载过程当中显示进度条、加载失败后点击重试等，对 5.0 如下的手机支持也更好。而 Glide 更方便，好比自动根据 ImageView 尺寸缩放图片、在内存事件回调时自动释放内存等。而对于性能以及使用的问题，答案可能并无网上讨论的那么简单，还须要自行权衡。缓存

	Fresco	Glide
代码结构	相对更复杂难懂	相对更清晰直观
View	自定义的 DraweeView	配合 ImageView 使用
获取 Bitmap	稍显复杂，须要向 ImagePipeline 发送自定义请求	相对更简单，使用 CustomTarget 或 FutureTarget 便可
缩放	方式更多，但默认不执行重采样，须要手动设置为 true，并提供 RezieOptions	默认自动根据 ImageView 的尺寸对图片进行重采样
图层	层级更多，功能更丰富（好比显示进度条、点击重试等）	分为占位图、缩略图、加载失败占位图三层
图片格式	支持 gif、webp、视频缩略图，可添加自定义 svg 解码器	支持 gif、webp、svg、视频缩略图
变换操做	支持圆形、圆角、旋转等	支持圆形、圆角、旋转等，但不支持在不一样位置使用不一样的圆角半径
渐进加载 JPEG	支持	不支持
缓存	1) 内存缓存（活跃、非活跃）2) 未解码的图片缓存（字节流）3) 磁盘缓存（缓存的是原始图像数据，能够手动设置小文件、大文件分开存储，但须要手动指定哪些是小文件）	1) 内存缓存（活跃、非活跃） 2) 磁盘缓存（解码、变换后的图像数据） 3) 磁盘缓存（原始图像数据）
缓存大小	1) 内存缓存通常是 ActivityManager.getMemoryClass / 4 2) 未解码的图片缓存通常是 4MB 3) 磁盘缓存通常是 40MB	1) 内存缓存根据手机分辨率计算，通常是分辨率乘以 2 2) 磁盘缓存默认 250MB（两级缓存共用）
缓存算法	LRU（磁盘缓存经过修改文件 LastModified 属性实现）	LRU（磁盘缓存经过 DiskLruCache 实现）
对象池	都有 Bitmap 对象池和数组对象池
内存事件	须要手动调用 trim 方法释放内存	监听了 ComponentCallbacks2，可自动释放内存
生命周期	监听 DraweeView 的 attach、detach 事件	添加 Fragment 监听生命周期
线程池	线程池更多，线程数也更多	主要有 3 个线程池，线程数相对较少
Bitmap 格式	默认为 ARGB_8888，能够手动设置为 HARDWARE	优先使用 Config.HARDWARE（8.0），不然默认使用 ARGB_8888
Bitmap 存储	5.0 如下使用 native 内存存储，5.0 及以上使用 Java 堆存储	Bitmap 优先使用 GPU 存储（8.0），不然使用 Java 堆存储