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啦，将在后续博文中讲解，敬请期待，如有不当之处，欢迎批评指正