Fresco.initialize(context);

ImagePipelineConfig config = ImagePipelineConfignewBuilder()
    setBitmapMemoryCacheParamsSupplier(bitmapCacheParamsSupplier)
    setCacheKeyFactory(cacheKeyFactorysetEncodedMemoryCacheParamsSupplier(encodedCacheParamsSuppliersetExecutorSupplier(executorSuppliersetImageCacheStatsTracker(imageCacheStatsTrackersetMainDiskCacheConfig(mainDiskCacheConfigsetMemoryTrimmableRegistry(memoryTrimmableRegistry) 
    setNetworkFetchProducer(networkFetchProducersetPoolFactory(poolFactorysetProgressiveJpegConfig(progressiveJpegConfigsetRequestListeners(requestListenerssetSmallImageDiskCacheConfig(smallImageDiskCacheConfigbuild();
Fresco, config 请记得将配置好的ImagePipelineConfig传递给Fresco.initialize!否则仍旧是默认配置。
 
 关于Supplier 许多配置的Builder都接受一个Supplier类型的参数而不是一个配置的实例。
 
 创建时也许有一些麻烦，但这带来更多的利好：这允许在运行时改变创建行为。以内存缓存为例，每隔5分钟就可检查一下Supplier，根据实际情况返回不同类型。
 
 如果你需要动态改变参数，那就是用Supplier每次都返回同一个对象。
 
 
 
Supplier<X> xSupplier = new Supplier>() {
  public X get() {
    return new X(xparam1xparam2...);
  }
);
// when creating image pipeline
setXSupplier(xSupplier);
 
 
 线程池 Image pipeline 默认有3个线程池:
 
 
 
3个线程用于网络下载
 
 
两个线程用于磁盘操作: 本地文件的读取，磁盘缓存操作。
 
 
两个线程用于CPU相关的操作: 解码，转换，以及后处理等后台操作。
 
 
 对于网络下载，你可以定制网络层的操作，具体参考:自定义网络层加载.
 
 对于其他操作，如果要改变他们的行为，传入一个ExecutorSupplier即可。
 
 内存缓存的配置 内存缓存和未解码的内存缓存的配置由一个Supplier控制，这个Supplier返回一个MemoryCacheParams对象用于内存状态控制。
 
 配置磁盘缓存 你可使用Builder模式创建一个DiskCacheConfig:
 
 
 
DiskCacheConfig diskCacheConfig = DiskCacheConfig()
   set....
   ()

// when building ImagePipelineConfig
(diskCacheConfig)
 
 
 缓存统计 如果你想统计缓存的命中率，你可以实现ImageCacheStatsTracker,在这个类中，每个缓存时间都有回调通知，基于这些事件，可以实现缓存的计数和统计。
 
 缓存 
 
 三级缓存
 
 1. Bitmap缓存
 
 Bitmap缓存存储Bitmap对象，这些Bitmap对象可以立刻用来显示或者用于后处理
 
 在5.0以下系统，Bitmap缓存位于ashmem，这样Bitmap对象的创建和释放将不会引发GC，更少的GC会使你的APP运行得更加流畅。
 
 5.0及其以上系统，相比之下，内存管理有了很大改进，所以Bitmap缓存直接位于Java的heap上。
 
 当应用在后台运行时，该内存会被清空。
 
 2. 未解码图片的内存缓存 这个缓存存储的是原始压缩格式的图片。从该缓存取到的图片在使用之前，需要先进行解码。
 
 如果有调整大小，旋转，或者WebP编码转换工作需要完成，这些工作会在解码之前进行。
 
 APP在后台时，这个缓存同样会被清空。
 
 3. 文件缓存 和未解码的内存缓存相似，文件缓存存储的是未解码的原始压缩格式的图片，在使用之前同样需要经过解码等处理。
 
 和内存缓存不一样，APP在后台时，内容是不会被清空的。即使关机也不会。用户可以随时用系统的设置菜单中进行清空缓存操作。
 
 查找一个bitmap是否被缓存？ 你可以使用ImagePipeline(http://frescolib.org/javadoc/reference/com/facebook/imagepipeline/core/ImagePipeline.html)检查bitmap是否在缓存中。
 
 查询bitmap是否在内存缓存中的操作是同步的。java ImagePipeline imagePipeline = Fresco.getImagePipeline(); Uri uri; boolean inMemoryCache = imagePipeline.isInBitmapMemoryCache(uri);
 
 查询bitmap是否在文件缓存中的操作时异步的。因为这个操作可以使用另一个线程操作。你可以这样使用。java DataSource<Boolean> inDiskCacheSource = imagePipeline.isInDiskCache(uri); DataSubscriber<Boolean> subscriber = new BaseDataSubscriber<Boolean>() { @Override protected void onNewResultImpl(DataSource<Boolean> dataSource) { if (!dataSource.isFinished()) { return; } boolean isInCache = dataSource.getResult(); // your code here } }; inDiskCacheSource.subscribe(subscriber,executor);以上API假设你使用默认的CacheKeyFactory。如果你自定义，你可能需要用把ImageRequest作为参数的方程，即imagePipeline.isInDiskCache(ImageRequest)和imagePipeline.isInBitmapMemoryCache(ImageRequest)
 
 清除缓存中的一条url ImagePipeline现有函数可以删除缓存中的一条url。
 
 
 
ImagePipeline imagePipeline = FrescogetImagePipeline();
Uri uri;
imagePipelineevictFromMemoryCache(uri);
imagePipelineevictFromDiskCache);

// combines above two lines
imagePipelineevictFromCache 如同上面一样，evictFromDiskCache(Uri)假定你使用的是默认的CacheKeyFactory。如果你自定义，请使用evictFromDiskCache(ImageRequest)。
 
 清除缓存
 
();
imagePipelineclearMemoryCachesclearDiskCaches();

clearCaches();
 
 
 用一个文件还是两个文件缓存? 如果要使用2个缓存，在配置image pipeline时调用setMainDiskCacheConfig和setSmallImageDiskCacheConfig方法即可。
 
 大部分的应用有一个文件缓存就够了，但是在一些情况下，你可能需要两个缓存。比如你也许想把小文件放在一个缓存中，大文件放在另外一个文件中，这样小文件就不会因大文件的频繁变动而被从缓存中移除。
 
 至于什么是小文件，这个由应用来区分，在创建image request,设置ImageType即可:
 
 
 
ImageRequest request = ImageRequestnewBuilderWithSourceUrisetImageType(ImageTypeSMALL)
 
 
 如果你仅仅需要一个缓存，那么不调用setSmallImageDiskCacheConfig即可。Image pipeline 默认会使用同一个缓存，同时ImageType也会被忽略。
 
 内存用量的缩减 在配置Image pipeline时，我们可以指定每个缓存最大的内存用量。但是有时我们可能会想缩小内存用量。比如应用中有其他数据需要占用内存，不得不把图片缓存清除或者减小 或者我们想检查看看手机是否已经内存不够了。
 
 Fresco的缓存实现了DiskTrimmable或者MemoryTrimmable接口。这两个接口负责从各自的缓存中移除内容。
 
 在应用中，可以给Image pipeline配置上实现了DiskTrimmableRegistry和MemoryTrimmableRegistry接口的对象。
 
 实现了这两个接口的对象保持着一个列表，列表中的各个元素在内存不够时，缩减各自的内存用量。
 
 直接使用Image Pipeline 本页介绍Image pipeline的高级用法，大部分的应用使用Drawees和image pipeline打交道就好了。
 
 直接使用Image pipeline是较为有挑战的事情，这意味着要维护图片的内存使用。Drawees 会根据各种情况确定图片是否需要在内存缓存中，在需要时加载，在不需要时移除。直接使用的话，你需要自己完成这些逻辑。
 
 Image pipeline返回的是一个CloseableReference对象。在这些对象不需要时，Drawees会调用.close()方法。如果你的应用不使用Drawees，那你需要自己完成这个事情。
 
 Java的GC机制会在Bitmap不使用时，清理掉Bitmap。但要GC时总是太迟了，另外GC是很昂贵的开销。GC大对象也会带来性能问题，尤其是在5.0以下系统。
 
 调用 pipeline 首先创建一个image request. 然后传递给ImagePipeline:
 
();
DataSource<CloseableReference<CloseableImage>> 
    dataSource = imagePipelinefetchDecodedImage(imageRequest 关于如果接收数据，请参考数据源章节。
 
 忽略解码 如果你不保持图片原始格式，不执行解码，使用fetchEncodedImage即可:
 
 
 
DataSource<PooledByteBufferfetchEncodedImage);
 
 
 从Bitmap缓存中立刻取到结果 不像其他缓存，如果图片在内存缓存中有的话，可以在UI线程立刻拿到结果。
 
>> dataSource =
    mImagePipelinefetchImageFromBitmapCache);
CloseableReference> imageReference;
try {
  imageReference = dataSourcegetResult();
  if (imageReference != null) {
    CloseableImage image = imageReferenceget();
    // do something with the image
  } finally {
  dataSourceclose();
  CloseableReferencecloseSafely(imageReference);
}