Glide 4.x之请求网络图片数据流程解析

在《Glide工作总体执行流程概述》一篇博文中简单分析了glide的工作流程，简而言之就是Glide先构建RequestManager对象，然后RequestManager对象构建ReqeustBuilder对象，再由RequsetBuilder对象创建一个Requset对像，最后将Request交给RequsetMangaer管理，然后RequestManager通知request调用begin发起请求将生成的图片资源交给具体的Target的过程。只不过上篇文章只是简单的做了梳理工作，并没有对详细的说明，本篇就承接上文来继续分析。所以建议读此篇博文的童鞋大致瞅一眼《Glide工作执行流程概述》

本篇还是以SingleRequest为例来说明，在资源还没有加载好的时候，SingleRequest的begin方法会调用一个onSizeReady方法：

public void begin() {
    //省略部分代码
    status = Status.WAITING_FOR_SIZE;
    if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
      onSizeReady(overrideWidth, overrideHeight);
    } 
   //省略部分代码

  }

进入onSizeReady内部翻看一翻，仍然剔除暂时与本文无关的代码：

private Engine engine;
public void onSizeReady(int width, int height) {
    //省略部分代码
    status = Status.RUNNING;

    loadStatus = engine.load(glideContext,model,//url
        //省略一大堆参数);

  }

也就是说onSizeReady方法内部也就是主要时调用来Engine对象的load方法，那么这个engine对象是什么鬼呢？先看看这个对象是时候初始化的，该对象是在初始化Glide对象的时候进行来初始化，具体的可在GlideBuilder的build方法找到：

 public Glide build(Context context) {

   //省略本分代码

    //如果客户端没有配置自己的Engine
    if (engine == null) {
      engine = new Engine(memoryCache, diskCacheFactory, diskCacheExecutor, sourceExecutor,
          GlideExecutor.newUnlimitedSourceExecutor());
    }

    return new Glide(context,engine,//省略一大堆参数);
  }

从Engine类的构造起所需要的参数来看，Engine负责内存缓存，磁盘缓存等等管理工作,这些内存和磁盘缓存等相关的类可以通过Builder模式让客户端自己构建自己的缓存逻辑，这也是Builder模式的强大之处，该模式也算是常用的设计模式之一，其设计理念还是很值得借鉴的，到此为止Engine的初始化已经创建完毕。下面继续沿着SingleRequest的流程分析engine.load方法：

//返回一个LoadStatus对象
 public <R> LoadStatus load(//一大堆参数) {
    //1、生成一个EngineKey对象
    EngineKey key = keyFactory.buildKey(model,//url
     signature, width, height, transformations,
        resourceClass,
         transcodeClass, //Drawable.class
         options);
   //2、从缓存加载图片资源
    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
    if (cached != null) {
      cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
           return null;
    }

   //3、此处也可以理解为缓存逻辑
    EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
      cb.onResourceReady(active, DataSource.MEMORY_CACHE);
      return null;
    }

    //4、从map中获取一个EngineJob对象
    EngineJob<?> current = jobs.get(key);
    if (current != null) {
      current.addCallback(cb);
      return new LoadStatus(cb, current);
    }

    //5、创建一个EngineJob对象
    EngineJob<R> engineJob = engineJobFactory.build(key, isMemoryCacheable,
        useUnlimitedSourceExecutorPool);
    //6、创建一个DecodeJob对象    
    DecodeJob<R> decodeJob = decodeJobFactory.build(
        glideContext,
        model,//url
        key,
        //省略一大堆参数,
        transcodeClass,
        ,
        engineJob);
    //将engineJob放入map缓存    
    jobs.put(key, engineJob);
    //添加一个callback
    engineJob.addCallback(cb);
    //8、开始engineJob
    engineJob.start(decodeJob);

    //返回一个LoadStatus对象
    return new LoadStatus(cb, engineJob);
  }

load方法的代码很长，1至4是与缓存有关的逻辑，本篇暂时抛开不谈，在第五步的时候创建来一个EngineJob对象这是一个DecodeJob.Callback接口的实现类，后面会提到此处可以留意下，现在暂且可以理解为EngineJob是Engine这个引擎的最小工作单元。然后第六步又创建来一个DecodeJob对象（该对象是一个Runnable)，第八步 engineJob.start(decodeJob);开始来工作，所以此处需要进入start方法探究一二：

 public void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
     //获取一个GlideExecutor对象，为ThreadPoolExecutor的子类
    GlideExecutor executor = decodeJob.willDecodeFromCache()
        ? diskCacheExecutor
        : getActiveSourceExecutor();
    //执行decodeJob这个ruanable
    executor.execute(decodeJob);
  }

EngineJob的start方法只是获取一个ThreadPoolExecutor对象执行DecodeJob这个Runnable而已（当然其内部还是比较复杂的），也就是说EngineJob只是一个壳子，其核心作用的还是DecodeJob这个对象。所以我们来看看DecodeJob这个Runalbe的run方法都做了些神马：

public void run() {
     DataFetcher<?> localFetcher = currentFetcher;
    try {
      if (isCancelled) {
        notifyFailed();
        return;
      }
      //runWrapped方法是重点
      runWrapped();
    } catch (RuntimeException e) {
       //省略部分代码  
    } finally {
      //省略部分代码
    }
  }

抛开run方法的枝枝蔓蔓，其内部调用来runWrapped方法，感觉距离真相越来越近了有木有，这是真的吗？:

  private void runWrapped() {
     switch (runReason) {
      //本篇分析这个分支
      case INITIALIZE:
        stage = getNextStage(Stage.INITIALIZE);
        currentGenerator = getNextGenerator();
        runGenerators();
        break;
      case SWITCH_TO_SOURCE_SERVICE:
        runGenerators();
        break;
      case DECODE_DATA:
        decodeFromRetrievedData();
        break;

    }
  }

上面有三个case分支，但是弱水三千只取一瓢，博主通过追踪内部逻辑准备只分析INITIALIZE分支，正如glide注释所说该分支INITIALIZE的意思是”The first time we’ve been submitted”,鉴于英语水平差，就不翻译了（事实上如果你打断点debug的话也会进入这个分支）。该case分支先调用了getNextGenerator方法，所以还是来看看该方法是干了啥牛逼的事儿，在分析runWrapped的时候有山重水复疑无路的感觉，现在感觉距离最终目的地尚有西天还有十万八千里呢！

 private DataFetcherGenerator getNextGenerator() {
    switch (stage) {
      case RESOURCE_CACHE://缓存相关
        return new ResourceCacheGenerator(decodeHelper, this);
      case DATA_CACHE://缓存相关
        return new DataCacheGenerator(decodeHelper, this);
      case SOURCE://分析该分支
        return new SourceGenerator(decodeHelper, this);
      case FINISHED:
        return null;
    }
  }

因为上文说过，本篇步分析与缓存有关的东西，只分析数据的最初来源（也就是服务器数据），所以本篇博文就分析SOURCE分支，该分支返回里一个SourceGenerator对象，该对象需要decodeHelper对象，decodeHelper对象是在初始化DecodeJob的时候对decodeHelper进行初始化的:

//初始化decodeHelper
 DecodeHelper<R> decodeHelper = new DecodeHelper<>();

 DecodeJob<R> init(
     GlideContext glideContext,
      Object model,//url
      //省略了一大堆参数
      ) {
      //调用decodeHelper的init方法初始化相关参数
    decodeHelper.init(
        glideContext,
        model,//url
        //省略了一大堆参数
        );

   //省略了无关代码
    return this;
  }

调用完getNextGenerator方法之后currentGenerator引用指向的对象就是SourceGenerator对象了，紧接着INITIALIZE的case分支又调用了runGenerators（） 方法：

private void runGenerators() {

    boolean isStarted = false;

    while (!isCancelled && currentGenerator != null
        && !(isStarted = currentGenerator.startNext())) {
      stage = getNextStage(stage);
      //链式调用
      currentGenerator = getNextGenerator();

      if (stage == Stage.SOURCE) {
        reschedule();
        return;
      }
    }
    //省略了部分代码
  }

上面的方法中有一个while循环，while循环的条件题里面有一句：

//currentGenerator为SourceGenerator对象
isStarted = currentGenerator.startNext()

如果该方法执行返回了false，则满足进入循环的条件之一，所以我们看看SourceGenerator的startNext都多了些什么：

 public boolean startNext() {
     //省略了缓存逻辑

    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      //1 、获取一个loadData对像获取LoadData对象
      loadData = helper.getLoadData().get(loadDataListIndex++);

     //省略部分代码
      //调用loadData的fetcher对象获取数据
        loadData.fetcher.loadData(helper.getPriority(), this);

    }
    return started;
  }

上面的代码主要做了两个逻辑：
1、先通过getLoadData获取ModelLoder对象的集合，然后获取一个loadData对象
2、通过loadData对象的fetcher对象的loadData方法来获取图片数据。
其实这里简单打个断点，然后debug一下就知道LoadData对象和fetcher都是什么：

上面说的在这里先埋疑问：
ModeLoder 是什么？什么时候初始化的？
LoadData 有是什么时候初始化的？
Fetcher有是干什么，有是怎么初始化的？
以上三个问题将留在下篇博客说明，本篇为了保持主题不偏方向，先不谈。

这个LoadData是ModelLoader接口的一个内部类：

 class LoadData<Data> {
    public final Key sourceKey;
    public final List<Key> alternateKeys;
    //真正获取数据的类
    public final DataFetcher<Data> fetcher;

  }

loaddata 对象内部有一个DataFetcher，该类就是Glide实际获取数据的类，如上图我们得到的是一个HttpUrlFetcher 对象，所以我们直接进入HttpUrlFetcher对象的loadData方法看看：

public void loadData(Priority priority, DataCallback<? super InputStream> callback) {

     final InputStream result;
      //发起网络请求，讲URL对应的数据转换成InputStream
      result = loadDataWithRedirects(glideUrl.toURL(), 0     , null ,glideUrl.getHeaders());

   //将图片数据输入流交给callback处理
    callback.onDataReady(result);//第一个callback
  }

loaddata方法是真正获取图片数据的地方：
1、调用loadDataWithRedirects方法，发起网络请求，讲URL指定的图片数据转换成InputStream输入流，该方法内部就是通过URLConnection对象来完成的(详细的读者可以自行到HttpUrlFetcher类的loadDataWithRedirects查看）。
2、将图片数据InputStream通过callback的onDataReady来传递，此处是我们遇到的第一个callback。

也就是说通过HttpUrlFecther处理之后，我们的图片数据源转换成来InputStream对象了。
那么上文中的callback 是什么呢？，该callback是一个DataCallback类型的接口（这是我们遇到的第一个callback，后面还有好多，希望读者不要绕晕了）。HttpUrlFecther的loadData方法的第二个参数就是一个DataCallback类型的参数，在SourceGenerator种我们传的是this，也就是说我们这个callback就是SourceGenerator对象，所以看看SourceGenerator对象的onDataReady方法都做了什么：

   //第二个callback
   private final FetcherReadyCallback cb;
  //此处data就是InputStream
  public void onDataReady(Object data) {

  //省略缓存逻辑

  //第二个callback
      cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
          loadData.fetcher.getDataSource(), originalKey);
    }
  }

剔除掉缓存的相关逻辑后，我们迎来了第二个callback，调用了该回调的onDataFetcherReady方法后，我们又将数据传给了这个callback。那么这个callback有是什么呢？该callback是FetcherReadyCallback的一个接口实现。那么这个callback 又是什么时候初始化的呢？当然是初始化SourceGenerator对象的时候，见上文我们是在DecodeJob这个类种初始化SourceGenerator的，DecodeJob就是这个callback的实现类，所以我们进入其onDataFetcherReady方法看看：

  @Override
  public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,
      DataSource dataSource, Key attemptedKey) {
   //将数据交给DecodeJob的currentData持有
    this.currentData = data;//InputStream
     //省略部分代码
        decodeFromRetrievedData();

    }
  }

然后我们看看decodeFromRetrievedData方法：

 private void decodeFromRetrievedData() {
    //1、将Inpustream转换成Resource对象
    Resource<R> resource = 
      resource = decodeFromData(currentFetcher, currentData, currentDataSource);
      //2、将数据继续传递
       if (resource != null) {
      notifyEncodeAndRelease(resource, currentDataSource);
    } else {
      runGenerators();
    }
  }

上面的方法做了两件事：
1、将图片数据InputStream流转换成Resource对象
2、调用notifyEncodeAndRelease将数据继续传递。
此时我们的图片数据由InputStream转换成了Resource对象。看看notifyEncodeAndRelease都做了写什么：

  private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {

    Resource<R> result = resource;
    //省略部分代码

    notifyComplete(result, dataSource);

   //省略部分代码
    }
  }

省略了与本文无关的代码之后，如上面所示我们来到了DecodeJob类的notifyComplete方法：

 private Callback<R> callback;
private void notifyComplete(Resource<R> resource, DataSource dataSource) {
   //省略一行代码
    //第三个callback
    callback.onResourceReady(resource, dataSource);
  }

notifyComplete方法中我们见到了第三callback，并且调用其onResourceReady方法，那么这个 callback的具体实现类是什么呢？该对象通过观察源码发现是在初始化DecodeJob初始化的，而根据上文DecodeJob的初始化是在Engine 的load方法里面完成的,在该类初始化的时候我们还初始化了EngineJob这个类，这个类就是这个第三个callback的具体实现（见上文engine.load 的讲解），所以看看EngineJob的onResourceReady方法：

  public void onResourceReady(Resource<R> resource, DataSource dataSource) {
    //原始数据
    this.resource = resource;
    this.dataSource = dataSource;
    MAIN_THREAD_HANDLER.obtainMessage(MSG_COMPLETE, this).sendToTarget();
  }

finally,见到了Handler的身影，说明我们距离终点不远了，上文的handler发送了MSG_COMPLETE消息该handler来处理，handler的初始化如下：

private static final Handler MAIN_THREAD_HANDLER =
      new Handler(Looper.getMainLooper(), new MainThreadCallback());

所以我们进入MainThreadcallback来看看MSG_COMPLETE消息的处理逻辑是什么，关于handler的具体工作流程参考博主《android消息处理机制详解》：

 //MainThreadcallback
 public boolean handleMessage(Message message) {
      EngineJob<?> job = (EngineJob<?>) message.obj;
      switch (message.what) {
        case MSG_COMPLETE:
          job.handleResultOnMainThread();
          break;

      }
      return true;
    }

仅仅是调用了EngineJob的handleResultOnMainThread方法，此时我们已经将图片数据切换到了UI线程：

  void handleResultOnMainThread() {
    //省略部分代码
    //将数据转换成engineResource
    engineResource = engineResourceFactory.build(resource, isCacheable);
    hasResource = true;

  //省略部分代码
    for (ResourceCallback cb : cbs) {
      if (!isInIgnoredCallbacks(cb)) {
       //特么的第四个callback
        cb.onResourceReady(engineResource, dataSource);
      }
    }

  }

该方法做了两件事：
1、将resource交给engineResource来持有
2、将engineResource交给本文的**第四个callback**

那么这第四个callback又是什么？是ResourceCallback接口，该接口是通过初始化EngineJob的时候调用EngineJob的 addCallback(ResourceCallback cb)方法传进来的。且EngineJob 的初始化是在Engine的load 方法中，而load 的方法的一个参数就是又这个callback, 且load的调用又是在文章开头的SingleReqeust方法，顺藤摸瓜发现第四个callback就是SingleReqeust，所以我们进入该SingleReqeust的onResourceReady方法：

 public void onResourceReady(Resource<?> resource, DataSource dataSource) {
    //调用重载方法：
    onResourceReady((Resource<R>) resource, (R) received, dataSource);
  }

private void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {

    this.resource = resource;
    //最终调用target的onResourceReady
     target.onResourceReady(result, animation);

  }

如果你读过博主的《Glide工作总体执行流程概述》这篇文章的话，就可以知道此处的target就是DrawableImageViewTarget,该target的onResourceReady方法的最总逻辑就是调用：

imageView.setImageDrawable(resource);

来完成图片的展示。

到此为止，本篇分析完毕，分析源码的过程中四个callback来回调度可把我绕坏了，为了本篇博文的主题连续性，基本上省略了好多东西没讲，什么ModelLoader啦，LoadData啦，Fetcher啦，将在后续博文中讲解，敬请期待，如有不当之处，欢迎批评指正