Fresco特性与性能分析

Facebook于今年开源了一个非常强大的图片加载组件，Fresco。https://github.com/facebook/fresco

主要有以下一些特性：

内存管理

  对于Android平台来说，图片一直是它需要关注的地方，如怎样进行高效图片显示和存储。我们知道每个像素由红、绿、蓝以及透明度组成，所以一个像素就占用了4个字节的大小内存空间，而设备本身分配给每个应用的内存大小是有限的，所以如何显示更多的图片，特别是高清的，对于应用来说，如何管理好内存是非常重要的。
  而Fresco的出现就为该问题提供了一个很好的解决方案(API>8)。其3级缓存设计，合理运用好了设备本身的内存区域，图片管理过程非常高效，使得前端体验更加流畅，也较有效地避免了常见内存问题的产生。

图片预览

1、渐进式呈现
  了解JPEG文件的同学应该清楚其有两种保存方式，Baseline JPEG
和Progressive JPEG。Progressive JPEG就是我们所说的渐进式加载，即图片先大致显示图片轮廓，然后随着图片下载，会逐渐呈现清晰的图片，从未图片预览效果。对于移动网络来说，这样就大大提升了用户的体验。
  Android本身是不支持该格式的显示的，但Fresco支持，并且可以设置清晰度，即达到该清晰度后才开始显示，从而使得图片预览效果更好的运用到android移动设备上来，效果如下图：

2、多图请求
  图片预览的另一种实现方式就是先显示低分辨率的图片，然后再显示高分辨率。
  由于网络的原因，下载一张高清的图片可能需要一定的时间，特别是在移动网络的情况下。此时我们可以先加载一张低分辨率的缩略图，然后再假装高分辨率的图片，而Fresco就将这一过程进行了很好的封装，包扩这两种图的切换及内存管理。

图片呈现效果
  Fresco支持图片的自定义居中、圆角图、自定义占位图、加载回调通知、图片的缩放与旋转等，从而为我们的应用带来更灵活的设计与渲染效果。

Gif、WebP格式
  动画图在安卓原生上的显示之前就是件”不爽”的事情，常需要通过webview方式来达到目的。Fresco在这块上就做的不错，同时支持gif和webP两种动画图格式，并能灵活对动画进行控制。

性能对比
  Fresco性能是否真的跟所说的一样呢，这需要我们来进行相应的测试，让数据来说话。
测试对象：主流的图片加载组件：Fresco、Gilde、Picasso、ImageLoader、Volley
测试环境：Moto X Pro、网络环境WIFI、图片源：400x300，50张
变量控制：实验次数、缓存

1、 Fresco

1） 先是看看Fresco在首次加载这么多图片的平均用时(为避免缓存的影响，每次测试前都需要清理下应用的缓存)，单位ms

2） 然后是Fresco二次加载的效果(即看Fresco在加载缓存图片的时的效率) ,单位ms

3） 接着就看看Fresco内存管理方面的表现，这里主要看两个内容，即java堆和native堆。Java堆最大值是受设备限制的，并且其内存回收是个麻烦事，其进行回收时会直接影响前端的性能响应。Native堆是通过c++来写的，能获更多的内存，内存管理也更灵活，但也相对麻烦。

小结：
  从测试数据来看，Fresco在首次加载图片的速度上是非常快的，几组数据的均值只有400ms，而在加载图片缓存方面，时间均值也只有45ms，速度很快，整个图片加载过程非常的流程，给用户的体验非常好。
  在内存方面，整个内存变化和波动过程都非常平稳，特别java heap的内存占用，一直在25mb这个水平线上小范围浮动，这也就说明了Fresco在图片缓存这块做得很出色，有效地对内存块的图片进行了管理，大大降低了内存溢出等问题的出现。

2、 Glide
  简介：谷歌今年发布的图片加载库，在方便性与稳定性上达到了很好的平衡。其原理中比较核心的技术就是对象池，非常有效地管理了Bitmap对象的内存分配与回收。

1） 先是看看Glide首次加载图片的效率，单位ms

2） 然后是Glide加载图片缓存的效率，单位ms

3） 最后再看看Glid在内存管理这块的表现，单位mb

小结：
  从数据来看，Glide在首次加载图片时，几组数据的用时均值是537ms，二次加载图片的均值时间是54ms，表现也挺不错。
  内存方面，java堆的管理也挺不错，但native堆的内存占用多了点，也直接拉高了整个应用的内存占用大小。

3、 Picasso
  简介：Glide跟Picasso很像，感觉Glide就是从Picasso中克隆出来的。Picasso通过一定的压缩算法来减少内存的消耗，加载图片时会自动进行缓存处理。

1） 先是看看Picasso首次加载图片的效率怎么样，单位ms

2） 然后是Picasso二次加载图片的效率，单位ms

3） 最后再看看Picasso内存管理的性能怎样，单位mb

小结：
  Picasso在首次加载图片时平均用时接近2s，二次图片加载则用了140多ms，整体图片加载效率稍微慢了些。
  在内存这一块，内存占用不稳定，特别是java堆的占用变化，这样也说明了其会有较大的内存溢出隐患。

4、 Universal Image Loader
  简介：比较常用的一个图片加载组件，支持多线程异步加载图片、3级缓存、慢网络环境下进行高效的图片加载。

1） 先是看看Universal-ImageLoader首次加载图片时的效率怎么样，单位ms

2） 然后就是Universal-ImageLoader在加载缓存图片的效率怎么样，单位ms

3） 最后看看其的内存管理的表现如何，单位mb

小结：
  Universal Image Loader在首次加载图片时平均用时是700多ms，表现也不错，而加载缓存图片的时间均也就只有25ms，非常快。
  内存管理这块整体来说内存占用很稳定，java堆这块波动也不大，稳定性好，这块跟Fresco表现挺像。
  Universal Image Loader在内存这块表现不俗，用起来非常稳定，这应该也是广受开发者欢迎的原因之一吧。

5、 Volley
  简介：之前比较火的一个开源网络组件，拓展性强，提供了高性能的网络通信功能，并对网络图片加载提供了良好的支持。非常适合迅速、简单的网络请求。

1） 先来看看Volley首次加载图片时的表现，单位是ms

2） 再看看Volley加载缓存图片的效率怎么样，单位ms

3） 接着就是看看Volley内存管理得怎么样，单位mb

小结：
  Volley在测试中首次加载图片的均用时是900多ms，加载缓存图片的均用时是140多ms，表现一般。
  Volley加载图片内存管理这块，整体来说还是稳定，但java堆这块相对来说没有那么稳定。
  整体来说Volley在加载图片的效率上效率并不突出，但其在网络请求这块简单和高效的优点，也是广受大家欢迎的重要原因。

总结：
  经过以上测试与小结后，我们可以得出如下结论：

1、首次图片加载(即缓存中没有相应的图片内容)：

  从图中(取所有数据的平均值形成统计图)我们可以发现，Fresco在这块表现不俗，较Glide有一点点的优势(其实优势不明显),之前广受欢迎的Volley在加载图片这块优势并不明显。

2、二次图片加载，即组件加载缓存中的图片效率：

  从图中我们可以发现，Universal Image Loader在这块的优势明显，加载缓存图片的效率非常高，这样对前端的体验来说是非常好的。而Fresco和Glide也表现不俗，而它们之间的差距也不明显。

3、而在图片的内存管理这块，通过以上的测试数据可以发现，Fresco、Glide和Universal Image Loader的表现相对突出，图片在内存里的占用大小变化相对稳定，尤其是java堆这块相关处理得不错，直接降低了内内存问题产生的风险。合理的缓存设计，如它们的3级缓存的设计，就直接给前端带来了良好交互的体验。

  总的来说，Fresco在以上各项的测试结果中表现优秀，图片加载效率高，图片内存管理稳定，加上其自身的特性(图片预览、动图展示等)，对于我们项目开发来说，是个非常不错的选择。

---