图片加载框架

图像加载

一般来说一图片加载框架应该具有以下基本特性：

1、图片的同步/异步加载

2、图片缓存（内存缓存/磁盘缓存）

3、网络加载

4、图片处理（压缩、裁剪、左右变幻等）

基本使用

UIL

 1、设置全局配置
 ImageLoaderConfiguration config = new ImageLoaderConfiguration
   .Builder(context)
   .memoryCacheExtraOptions(480, 800) // max width, max height，即保存的每个缓存文件的最大长宽
   .threadPoolSize(3)//线程池内加载的数量
   .threadPriority(Thread.NORM_PRIORITY - 2)
   .denyCacheImageMultipleSizesInMemory()
   .memoryCache(new UsingFreqLimitedMemoryCache(2 * 1024 * 1024)) // You can pass your own memory cache implementation/你可以通过自己的内存缓存实现
   .memoryCacheSize(2 * 1024 * 1024)
   .discCacheSize(50 * 1024 * 1024)
   .discCacheFileNameGenerator(new Md5FileNameGenerator())//将保存的时候的URI名称用MD5 加密
   .tasksProcessingOrder(QueueProcessingType.LIFO)
   .discCacheFileCount(100) //缓存的文件数量
   .defaultDisplayImageOptions(DisplayImageOptions.createSimple())
   .imageDownloader(new BaseImageDownloader(context, 5 * 1000, 30 * 1000)) // connectTimeout (5 s), readTimeout (30 s)超时时间
   .writeDebugLogs() // Remove for release app
   .build();//开始构建
    ImageLoader.getInstance().init(config);

 2、设置具体ImageView配置
    DisplayImageOptions options = new DisplayImageOptions.Builder()
   .showImageOnLoading(R.drawable.ic_launcher) //设置图片在下载期间显示的图片
            .showImageForEmptyUri(R.drawable.ic_launcher)//设置图片Uri为空或是错误的时候显示的图片
            .showImageOnFail(R.drawable.ic_launcher)  //设置图片加载/解码过程中错误时候显示的图片
            .cacheInMemory(true)//设置下载的图片是否缓存在内存中
            .cacheOnDisc(true)//设置下载的图片是否缓存在SD卡中
            .considerExifParams(true)  //是否考虑JPEG图像EXIF参数（旋转，翻转）
            .imageScaleType(ImageScaleType.EXACTLY_STRETCHED)//设置图片以如何的编码方式显示
            .bitmapConfig(Bitmap.Config.RGB_565)//设置图片的解码类型//
           .decodingOptions(android.graphics.BitmapFactory.Options decodingOptions)//设置图片的解码配置
             //.delayBeforeLoading(int delayInMillis)//int delayInMillis为你设置的下载前的延迟时间
            //设置图片加入缓存前，对bitmap进行设置
            //.preProcessor(BitmapProcessor preProcessor)
            .resetViewBeforeLoading(true)//设置图片在下载前是否重置，复位
            .displayer(new RoundedBitmapDisplayer(20))//是否设置为圆角，弧度为多少
            .displayer(new FadeInBitmapDisplayer(100))//是否图片加载好后渐入的动画时间
            .build();//构建完成
 3、展示图片
 ImageLoader.getInstance().displayImage(uri.getPath(), im, options, new ImageLoadingListener() {
        @Override
        public void onLoadingStarted(String imageUri, View view) {

        }

        @Override
        public void onLoadingFailed(String imageUri, View view, FailReason failReason) {

        }

        @Override
        public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {

        }

        @Override
        public void onLoadingCancelled(String imageUri, View view) {

        }
    });

fresco

    Fresco.initialize(getApplicationContext());
    SimpleDraweeView testFre;//需要在xml布局文件中使用fresco自定义的布局和设置
    testFre.setImageURI(uri);

picasso&glide

    ImageView img；
    Glide.with(this)
            .load(uri)
            .into(img);
    Picasso.with(this)
            .load(uri)
            .into(img);

想比起UIL繁杂的设置和用法，其他的则显得简洁得多。

UIL

Universal Imager loader是比较悠久的图片加载框架。
其核心类是ImageLoader类，采用经典的单例模式，核心的方法有初始化设置的：

public synchronized void init(ImageLoaderConfiguration configuration)

以及展示图片的一系列重载方法：

displayImage()和loadImage()；

以及操作缓存及一些基本配置的方法。
框架结构设计相对清晰明了。

其中ImageLoaderConfiguration采用的是Builder设计模式，主要功能是为ImageLoader配置一些设置，如缓存大小、线程数量、默认DisplayImageOptions设置等。DisplayImageOptions也是采用的Builder设计模式，但是主要是正对特定的ImageView进行设置，主要配置是否缓存，圆角、动画、默认显示图片、网络获取失败显示图片等。
1、在display()方法中首先会判断url是否为空，如果为空先会判断在DisplayImageOptions对象options中是否设置了Uri为空或是错误的时候显示的图片，如果有则加载给图片，否则直接设置图片为空，并返回renturn结束方法。

2、一旦uri不为空，那么首先会从内存缓存中取得相应的Bitmap（注意不是磁盘缓存），如果Bitmap不为空并且没有被回收，如果不需要进行处理，那么直接加载图片，否则会构建一个ProcessAndDisplayImageTask对象，其本质上是一个Runnable即线程，如果在options中设置了同步加载那么会直接执行线程的run方法，否则使用异步加载，即通过缓存线程池（taskExecutorForCachedImages）执行线程。

3、如果2中的Bitmap为空，即缓存为空或者已经被回收了，如果设置了加载过程中显示的图片那么设置为该图片，然后构造一个LoadAndDisplayImageTask，其本质上也是一个线程，也分同步和异步执行。

fresco

fresco是由facebook开源的图片加载框架，导入的时候fresco会自动的导入5个包：fresco、fbcore、drawee、imagepipeline、imagepipeline-base。其构成是有些复杂的。采用典型的MVC设计模式。有点晕。。。下午写完

首先需要在application中调用Fresco.initialize(Context context,@Nullable ImagePipelineConfig imagePipelineConfig,@Nullable DraweeConfig draweeConfig))，这一步看似无关紧要，其实是串联整个流程的至关重要一部，在这里，初始化了context，imagePipelineConfig（如果为null，则通过传递的context进而新建一个ImagePipelineConfig）创建了一个ImagePipelineFactory对象，并且调用initializeDrawee(context, draweeConfig),在其中初始化了一个PipelineDraweeControllerBuilderSupplier，同时通过 SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier)，将sDraweeControllerBuilderSupplier传递到具体的View中。

其次Fresco的使用很简单，在全局初始化完成之后，直接调用setImageURI(Uri uri）方法即可实现所有的流程。

public void setImageURI(Uri uri, @Nullable Object callerContext) {
DraweeController controller = mSimpleDraweeControllerBuilder
    .setCallerContext(callerContext)
    .setUri(uri)
    .setOldController(getController())
    .build();
setController(controller);
}

注意这里的controller是一个SimpleDraweeControllerBuilder对象向上转型。关键实现是setController(controller)，一步步追踪进去：(DraweeView.java)setController()–>(DraweeHolder.java)setController()–>(DraweeHolder.java)attachController()–>mController.onAttach(),此时来到AbstractDraweeController以及PipelineDraweeController中的onAttach()方法，核心为submitRequest();此时已经接触到了框架的核心实现。mDataSource = getDataSource();定位方法，发现AbstractDraweeController类中只是定义了一个抽象方法，其具体实现在其子类PipelineDraweeController中：

@Override
protected DataSource<CloseableReference<CloseableImage>> getDataSource() {
if (FLog.isLoggable(FLog.VERBOSE)) {
  FLog.v(TAG, "controller %x: getDataSource", System.identityHashCode(this));
}
return mDataSourceSupplier.get();
}

mDataSourceSupplier是全局初始化的时候传递的PipelineDraweeControllerBuilderSupplier，定位到其中的get()方法,发现是新建了一个PipelineDraweeControllerBuilder实例，最终会执行其中的obtainController()方法，然后进入到AbstractDraweeControllerBuilder中的obtainDataSourceSupplier()方法，并调用getDataSourceSupplierForRequest方法以及getDataSourceForRequest()方法，具体的实现在PipelineDraweeControllerBuilder中：

  @Override
 protected DataSource<CloseableReference<CloseableImage>> getDataSourceForRequest(
  ImageRequest imageRequest,
  Object callerContext,
  CacheLevel cacheLevel) {
return mImagePipeline.fetchDecodedImage(
    imageRequest,
    callerContext,
    convertCacheLevelToRequestLevel(cacheLevel));
 }

定位到fetchDecodedImage中：

  public DataSource<CloseableReference<CloseableImage>> fetchDecodedImage(
  ImageRequest imageRequest,
  Object callerContext,
  ImageRequest.RequestLevel lowestPermittedRequestLevelOnSubmit) {
try {
  //获取数据
  Producer<CloseableReference<CloseableImage>> producerSequence =
      mProducerSequenceFactory.getDecodedImageProducerSequence(imageRequest);
  //主要是传递数据
  return submitFetchRequest(
      producerSequence,
      imageRequest,
      lowestPermittedRequestLevelOnSubmit,
      callerContext);
} catch (Exception exception) {
  return DataSources.immediateFailedDataSource(exception);
}
}

定位getDecodedImageProducerSequence(imageRequest)，进入到ProducerSequenceFactory中的getDecodedImageProducerSequence，核心实现为：

  public Producer<Void> getDecodedImagePrefetchProducerSequence(
  ImageRequest imageRequest) {
return getDecodedImagePrefetchSequence(getBasicDecodedImageSequence(imageRequest));
}

private Producer<CloseableReference<CloseableImage>> getBasicDecodedImageSequence(
  ImageRequest imageRequest) {
Preconditions.checkNotNull(imageRequest);

Uri uri = imageRequest.getSourceUri();
Preconditions.checkNotNull(uri, "Uri is null.");

switch (imageRequest.getSourceUriType()) {
  case SOURCE_TYPE_NETWORK:
    return getNetworkFetchSequence();
  case SOURCE_TYPE_LOCAL_VIDEO_FILE:
    return getLocalVideoFileFetchSequence();
  case SOURCE_TYPE_LOCAL_IMAGE_FILE:
    return getLocalImageFileFetchSequence();
  case SOURCE_TYPE_LOCAL_CONTENT:
    return getLocalContentUriFetchSequence();
  case SOURCE_TYPE_LOCAL_ASSET:
    return getLocalAssetFetchSequence();
  case SOURCE_TYPE_LOCAL_RESOURCE:
    return getLocalResourceFetchSequence();
  case SOURCE_TYPE_QUALIFIED_RESOURCE:
    return getQualifiedResourceFetchSequence();
  case SOURCE_TYPE_DATA:
    return getDataFetchSequence();
  default:
    throw new IllegalArgumentException(
        "Unsupported uri scheme! Uri is: " + getShortenedUriString(uri));
}
}

到这里源码就比较清晰了，会根据不同情况，使用不同的获取序列数据。
ps：Fresco是笔者看到过的源代码最复杂的图片框架，复杂到分了5个包和铺天盖地的类，虽然其使用较简单，但是使用起来的是时候总感觉太重。

picasso

该框架采用的单例模式，通过Picasso.with(this)方法取得Picasso对象的实例。

public static Picasso with(Context context) {
 if (singleton == null) {
  synchronized (Picasso.class) {
    if (singleton == null) {
      singleton = new Builder(context).build();
    }
  }
 }
return singleton;
}

可以看出这里还采用了Builder模式，Builder中初始化了关键的一些参数，如：线程池、下载器、缓存等。

然后调用load(Uri uri)方法，返回一个RequestCreator对象，构造器传递了一个Picasso对象的实例，并且将uri封装初始化了一个Request.Builder()对象。

再调用with(imageview，callback)方法，如果有内存缓存则直接设置显示图片，没有则将imageview以及request打包成一个Action对象，同时调用picasso.enqueueAndSubmit(action)，此时运行流程又回到了Picasso对象中，然后调用dispatcher.dispatchSubmit(action)，进入Dispatcher，这是一个分发器，使用了Handler消息机制，最终的运行落实在performSubmit、performCancel等一些列perform方法上，performSubmit方法主要是进行网络获取，通过submit方法在线程池中运行BitmapHunter线程，在BitmapHunter的run()方法中核心是Bitmap result = hunt()，其中会调用requestHandler.load(data, networkPolicy)，RequestHandler共有7个具体的实现类。

网络获取的类为：NetworkRequestHandler，在构造器中初始了一个下载器Downloader类，Downloader是一个接口，具体的实现类有两个：OkHttpDownloader和UrlConnectionDownloader。
其中OkHttpDownloader封装的是OkHttp，而UrlConnectionDownloader封装的是HttpURLConnection，默认使用OkHttpDownloader。NetworkRequestHandler中重载了load方法，通过Response response = downloader.load(request.uri, request.networkPolicy)取得最终的响应，取得InputStream，并最终封装成为一个new Result(is, loadedFrom)对象。

glide

glide与picasso的较为相似，相似度为90%。首先调用with()方法，但是glide做了一定程度的优化，picasso中with方法必须以context为参数，glide中则支持Activity、Fragment等，此方法会返回一个RequestManager。

然后调用RequestManager中的load方法，会返回一个RequestBuilder对象，调用该类的into方法，会触发buildRequest(target)，返回一个SingleRequest实例，然后调用 requestManager.track(target, request)–>requestTracker.runRequest(request)–> request.begin()，也就是最终会调用SingleRequest的begin()方法，会调用onSizeReady以及其中的engine.load，然后调用其中的

engineJob.addCallback(cb);
engineJob.start(decodeJob);

其中engineJob代表线程池，decodeJob代表具体的线程。所以最终会调用其中的run()方法。可以看到其核心实现是runWrapped()方法，而runWrapped()中只存在一个一个switch语句，如果不细看会造成很大的困扰，runReason的初始值在构造器中初始为INITIALIZE，并且这里通过getNextStage和getNextGenerator不断的，遍历stage的五个值（），同时根据stage选定不同的DataFetcherGenerator，并且在runGenerators()方法中，不断的调用DataFetcherGenerator的startNext()方法，并且回调FetcherReadyCallback方法，然后在其中进行相应的处理。startNext()方法中关键代码如下：

loadData.fetcher.loadData(helper.getPriority(), this);

实际调用的是DataFetcher的loadData方法。DataFetcher的具体实现类有7个，会根据构造策略选用不同的DataFetcher。

后续

这四个图片框架，从使用便捷角度来说，UIL最复杂，fresco、picasso、glide差不多。
从源码角度来说，UIL和picasso逻辑最清晰，glide较复杂，比一般的网络框架都要复杂，fresco的复杂程度简直。。。或许作为一个单纯的图片框架，显得太重了，如果对图片显示不是太专业级别，那么不推荐使用Fresco。查看其包可以发现，其大小在达到了3M。picasso在120KB左右，UIL：160KB，glide：475KB。picasso是不错的选择，当需要在Activity或者Fragment中使用到时，可以参考使用glide。