Glide&Fresco对比

Posted by Jfson on 2018-02-01

貌似框架都被分析烂了，索性来个总结吧

优点

Glide

  • 多种图片格式的缓存，适用于更多的内容表现形式（如Gif、WebP、缩略图、Video）
  • 生命周期集成（根据Activity或者Fragment的生命周期管理图片加载请求）
  • 高效处理Bitmap（bitmap的复用和主动回收，减少系统回收压力）
  • 高效的缓存策略，灵活（Picasso只会缓存原始尺寸的图片，Glide缓存的是多种规格），加载速度快且内存开销小（默认Bitmap格式的不同，使得内存开销是Picasso的一半）,缓存的key 是根据url,width,height等等生成的，由此可见，宽高不一致也无法复用。
  • 支持图片加载顺序的优先级设置
  • 方法数 2678

Fresco

  • 最大的优势在于5.0以下(最低2.3)的bitmap加载。在5.0以下系统，Fresco将图片放到一个特别的内存区域(Ashmem区)
  • 大大减少OOM（在更底层的Native层对OOM进行处理，图片将不再占用App的内存）
  • 适用于需要高性能加载大量图片的场景
  • 框架设计的没毛病，api支持教好
  • 方法数1w+

Glide

  • Glide 缓存
1
2
3
4
5
默认情况下，Glide 会在开始一个新的图片请求之前检查以下多级的缓存：
1. 活动资源 (Active Resources) 
2. 内存缓存 (Memory Cache) 
3. 资源类型（Resource Disk Cache）
4. 原始数据 (Data Disk Cache)
  • 活动资源：如果当前对应的图片资源正在使用，则这个图片会被Glide放入活动缓存。
  • 内存缓存：如果图片最近被加载过，并且当前没有使用这个图片，则会被放入内存中
  • 资源类型: 被解码后的图片写入磁盘文件中，解码的过程可能修改了图片的参数(如:inSampleSize、inPreferredConfig)
  • 原始数据: 图片原始数据在磁盘中的缓存(从网络、文件中直接获得的原始数据)
  • 内存缓存都为LRU算法，其中包含LruBitmapPool
缓存策略

与其他图片加载库的缓存机制不同，Glide缓存图片时默认只缓存最终加载的那张图片。举个栗子，你要加载的图片分辨率为1000x1000，但是最终显示该图片的ImageView大小只有500x500，那么Glide就会只缓存500x500的小图。这也是在从磁盘缓存中加载图片时Glide比Picasso快的原因。Glide目前提供了四种缓存策略：

  • DiskCacheStrategy.NONE 不缓存文件
  • DiskCacheStrategy.SOURCE 只缓存原图
  • DiskCacheStrategy.RESULT 只缓存最终加载的图（默认的缓存策略）
  • DiskCacheStrategy.ALL 同时缓存原图和结果图
缓存算法

在Glide中磁盘缓存默认使用的是LRU（Least Recently Used）算法。如果你想使用其他的缓存算法，
就只能通过实现DiskCache接口来完成了。

  • Glide 支持图片加载顺序的优先级设置
1
2
3
4
5
6
 Glide
    .with(context)
    .load("...")
    .priority(Priority.HIGH) //优先级Priority.LOW
    .into(imageViewHero);
}

Fresco

  • Fresco有三级缓存，分别是 Bitmap缓存，未解码图片缓存， 文件缓存。
  • 提一点Bitmap缓存：在5.0以下系统，Bitmap缓存位于ashmem，这样Bitmap对象的创建和释放将不会引发GC。5.0及其以上系统，相比之下，内存管理有了很大改进，所以Bitmap缓存直接位于Java的heap上。
  • 当控件比较小的时候，Fresco会在没有做过任何处理的情况下，会将原图片加入到内存中，即缓存原始图像，然后做一些压缩处理显示在控件上。如果需要根据控件修改图片尺寸，需先获取控件的宽高然后进行压缩。
FEATURED TAGS
pv UV: