Glide与Fresco缓存机制

glide 

特点：
可以传入activity、fragment，图片的加载会和activity、fragment生命周期一致（比如onPause暂停、onResume重新加载，onDestory销毁）
默认Bitmap格式RGB_565（比ARGB_8888小一半，位图位数越高代表其可以存储的颜色信息越多，当然图像也就越逼真；RGB_565无法显示图片本身的透明度）
Glide加载的大小与imageview一致
可加载gif、WebP
可配置图片动画
体积500 KB

Google推荐

缓存策略：
MemeryCache（LruCache最近最少使用算法）、WeakReference（activeResources弱引用，每次GC会被回收）、DiskCache（磁盘缓存）



加载过程：

正在使用中的图片使用弱引用activeResources来进行缓存，不在使用中的图片使用LruCache来进行缓存；

activeResources保证正在使用的图片不被Lru算法回收。

如果要使用图片，首先从LruCache取出图片，然后存到activeResources，图片释放的时候，再把图片存到LruCache。这样在使用LRU算法的时候，正在使用的图片在弱引用里，就不会被回收。

硬盘缓存，默认情况下在硬盘缓存的就是转换过后的图片


缓存处理关 键类 ：LruResourceCache、DiskCache



Fresco

特点：
SimpleDraweeView
图像的渐进式呈现

体积太大2～3M

也可加载gif、webP

5.0以下系统，把bitmap保存到ashmen(匿名共享内存机制)，不会启动gc，使的界面不会因为gc而卡死，

Facebook主导

缓存策略：

Fresco使用三级缓存，已解码内存缓存；未解码内存缓存；磁盘缓存

第一级缓存就是保存bitmap，直接存的就是bitmap对象，5.0 以下，这些位于ashmem，5.0以上，直接位于java的heap上
第二级缓存保存在内存，但是没有解码，使用时需要解码，
第三级缓存就是保存在本地文件，同样文件也未解码，使用的时候要先解码啦！

在5.0以下，GC将会显著地引发界面卡顿。Fresco将图片放到一个特别的内存区域。当然，在图片不显示的时候，占用的内存会自动被释放。这会使得APP更加流畅，减少因图片内存占用而引发的OOM。

加载图片的流程：

查找Bitmap缓存中是否存在，存在则直接返回Bitmap直接使用，不存在则查找未解码图片的缓存，如果存在则进行Decode成Bitmap然后直接使用并加入Bitmap缓存中，如果未解码图片缓存中查找不到，则进行硬盘缓存的检查，如有，则进行IO、转化、解码等一系列操作，最后成Bitmap供我们直接使用，并把未解码（Encode）的图片加入未解码图片缓存，把Bitmap加入Bitmap缓存中，如硬盘缓存中没有，则进行Network操作下载图片，然后加入到各个缓存中。

源码缓存处理位置：

com.facebook.imagepipeline.core.ImagePipelineFactory初始化com.facebook.imagepipeline.core.ImagePipeline.java
ImagePipeline负责图片的获取和管理。图片可以来自远程服务器，本地文件，或者Content Provider，本地资源。压缩后的文件缓存在本地存储中，Bitmap数据缓存在内存中。 
在5.0系统以下，Image Pipeline 使用 pinned purgeables 将Bitmap数据避开Java堆内存，存在ashmem中。这要求图片不使用时，要显式地释放内存。 
SimpleDraweeView自动处理了这个释放过程，所以没有特殊情况，尽量使用SimpleDraweeView，在特殊的场合，如果有需要，也可以直接控制Image Pipeline。
我们可以通过imagepipeline判断bitmap是否被缓存，
ImagePipeline imagePipeline = Fresco.getImagePipeline();
imagePipeline.isInBitmapMemoryCache(Uri.parse(""));
imagePipeline.isInDiskCache(Uri.parse("xxx"));
删除指定缓存
Uri uri = Uri.parse("xxx");
imagePipeline.evictFromCache(uri);
imagePipeline.evictFromDiskCache(uri);