Android 图片加载框架Glide4.0源码完全解析（二）

写在之前

上一篇博文写的是Android 图片加载框架Glide4.0源码完全解析（一），主要分析了Glide4.0源码中的with方法和load方法，原本打算是一起发布的，但是由于into方法复杂性远不是前两个方法所能比拟的，又不愿意马马虎虎的随便应付的写作，还是保持一贯的一步步深入的讲解，所以就提前发布了一篇，以减少篇幅。

正文

这篇是讲Glide源码中into方法的实现原理，可以说with和load方法只是做了前期的初始化配置工作，而真正意义上的图片加载就是在into方法中实现的，所以该方法的复杂程度是可以想象的，还是依照我之前的写作习惯，一步步的分析，不留下任何的盲点给大家带来困惑，那么下面就开始吧。

Glide 源码分析

into()

前面两个方法把所需的基础配置基本已做好，那么接下来就是真正的要去加载资源了，那么我们来看看吧：

首先进去into方法中：

public Target<TranscodeType> into(ImageView view) {
    Util.assertMainThread();
    Preconditions.checkNotNull(view);

    if (!requestOptions.isTransformationSet()
        && requestOptions.isTransformationAllowed()
        && view.getScaleType() != null) {
      if (requestOptions.isLocked()) {
        requestOptions = requestOptions.clone();
      }
      switch (view.getScaleType()) {
        case CENTER_CROP:
          requestOptions.optionalCenterCrop();
          break;
        case CENTER_INSIDE:
          requestOptions.optionalCenterInside();
          break;
        case FIT_CENTER:
        case FIT_START:
        case FIT_END:
          requestOptions.optionalFitCenter();
          break;
        case FIT_XY:
          requestOptions.optionalCenterInside();
          break;
        case CENTER:
        case MATRIX:
        default:
          // Do nothing.
      }
    }

    return into(context.buildImageViewTarget(view, transcodeClass));
  }

主要是为requestOptions 做一些配置，这个配置时根据View的属性而来的。

然后调用GlideContext的buildImageViewTarget方法，并把view和transcodeClass传递进去来构造一个viewTarget的对象，跟进去看看：

直接的调用imageViewTargetFactory的buildTarget方法，然后看下buildTarget的源码：

还记得我多次提醒transcodeClass是什么吗？没错就是Drawable.class，就是在这个分支中使用到，那么在buildTarget中就是创建一个DrawableImageViewTarget对象，并它view传递进去，DrawableImageViewTarget继承于ImageViewTarget，又把view传递到了ViewTarget中，最终把view存放到了ViewTarget中的view变量中，并且还创建了一个SizeDeterminer对象：

ok，这就是我们的ImageView的最终去向，知道了view的去向，我们在返回到RequestBuilder中，创建个DrawableImageViewTarget对象后，又把它重定向到into方法中：

这个方法是非常重要的，必须要理解清楚，其实真正的理解好了也就很简单的了：

首先，从target中调用getRequest方法获取Request请求，这个getRequest方法是在ViewTarget父类中：

它首先从View中获取tag标识，但是我们从未为view设置标识，它也就不存在什么标识，所以getTag方法会返回一个null值，由此request也就是一个null空值。

在从taget中获取不到request，那么就需要为它去构造request对象，所以它调用了buildRequest：

private Request buildRequest(Target<TranscodeType> target) {
    return buildRequestRecursive(target, null, transitionOptions, requestOptions.getPriority(),
        requestOptions.getOverrideWidth(), requestOptions.getOverrideHeight());
  }

buildRequest方法又调用了buildRequestRecursive方法：

private Request buildRequestRecursive(Target<TranscodeType> target,
      @Nullable ThumbnailRequestCoordinator parentCoordinator,
      TransitionOptions<?, ? super TranscodeType> transitionOptions,
      Priority priority, int overrideWidth, int overrideHeight) {
    ...
      return obtainRequest(target, requestOptions, parentCoordinator, transitionOptions, priority,
          overrideWidth, overrideHeight);
  }

buildRequestRecursive做了一堆判断，最终会调用obtainRequest方法：

在这里它直接的调用SingleRequest.obtain方法，并返回一个Request对象，由此我们看到最终是调用到SingleRequest来真正的构造Request对象：

 public static <R> SingleRequest<R> obtain(
      GlideContext glideContext,
      Object model,
      Class<R> transcodeClass,
      RequestOptions requestOptions,
      int overrideWidth,
      int overrideHeight,
      Priority priority,
      Target<R> target,
      RequestListener<R> requestListener,
      RequestCoordinator requestCoordinator,
      Engine engine,
      TransitionFactory<? super R> animationFactory) {
    @SuppressWarnings("unchecked") SingleRequest<R> request =
        (SingleRequest<R>) POOL.acquire();
    if (request == null) {
      request = new SingleRequest<>();
    }
    request.init(
        glideContext,
        model,
        transcodeClass,
        requestOptions,
        overrideWidth,
        overrideHeight,
        priority,
        target,
        requestListener,
        requestCoordinator,
        engine,
        animationFactory);
    return request;
  }

由obtain方法看到，创建了一个SingleRequest对象，并调用它的init方法来进行初始化操作。

ok，到此Request创建完毕，来看看它拥有哪些成员：

让我们再回到into方法中，创建了Request对象后，把它设置给我们的target，最终则是调用setTag方法为view设置tag：

private void setTag(@Nullable Object tag) {
    if (tagId == null) {
      isTagUsedAtLeastOnce = true;
      view.setTag(tag);
    } else {
      view.setTag(tagId, tag);
    }
  }

设置完毕之后将会调用requestManager中的track方法：

void track(Target<?> target, Request request) {
    targetTracker.track(target);
    requestTracker.runRequest(request);
  }

track方法中分别把target和request添加到targetTracker和requestTracker追踪器中。

然后来看看runRequest方法：

它将会调用Request对象的begin方法来企图开启我们的请求，我们知道request其实就是我们的SingleRequest对象，那么到它的begin方法中看看到底做了哪些事情：

@Override
  public void begin() {
    stateVerifier.throwIfRecycled();
    startTime = LogTime.getLogTime();
    if (model == null) {
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
        width = overrideWidth;
        height = overrideHeight;
      }
      // Only log at more verbose log levels if the user has set a fallback drawable, because
      // fallback Drawables indicate the user expects null models occasionally.
      int logLevel = getFallbackDrawable() == null ? Log.WARN : Log.DEBUG;
      onLoadFailed(new GlideException("Received null model"), logLevel);
      return;
    }

    status = Status.WAITING_FOR_SIZE;
    if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
      onSizeReady(overrideWidth, overrideHeight);
    } else {
      target.getSize(this);
    }

    if ((status == Status.RUNNING || status == Status.WAITING_FOR_SIZE)
        && canNotifyStatusChanged()) {
      target.onLoadStarted(getPlaceholderDrawable());
    }
    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logV("finished run method in " + LogTime.getElapsedMillis(startTime));
    }
  }

首先，它判断model是否为空，如果请求url为空的话，那就不用请求了，直接调用onLoadFailed加载失败。

然后，调用onSizeReady方法，真正的资源加载就是从这个方法中开始的。

最后，根据Status对象状态和是否有占位图来设置加载过程中的占位图。

那么重点就是在onSizeReady方法中了，我们来详细的看看它的源码：

  @Override
  public void onSizeReady(int width, int height) {
    stateVerifier.throwIfRecycled();
    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logV("Got onSizeReady in " + LogTime.getElapsedMillis(startTime));
    }
    if (status != Status.WAITING_FOR_SIZE) {
      return;
    }
    status = Status.RUNNING;

    float sizeMultiplier = requestOptions.getSizeMultiplier();
    this.width = maybeApplySizeMultiplier(width, sizeMultiplier);
    this.height = maybeApplySizeMultiplier(height, sizeMultiplier);

    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logV("finished setup for calling load in " + LogTime.getElapsedMillis(startTime));
    }
    loadStatus = engine.load(
        glideContext,
        model,
        requestOptions.getSignature(),
        this.width,
        this.height,
        requestOptions.getResourceClass(),
        transcodeClass,
        priority,
        requestOptions.getDiskCacheStrategy(),
        requestOptions.getTransformations(),
        requestOptions.isTransformationRequired(),
        requestOptions.getOptions(),
        requestOptions.isMemoryCacheable(),
        requestOptions.getUseUnlimitedSourceGeneratorsPool(),
        requestOptions.getOnlyRetrieveFromCache(),
        this);
    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime));
    }
  }

onSizeReady方法中首先把State状态更改为RUNNING，然后获取到ImageView的宽高属性值，这个属性值就是要加载的图片的宽高，顺便提一句，Glide框架会根据请求加载图片的ImageView的宽高来进行加载相对应的宽高图片，每次根据view的大小加载的图片是不一定一样的。最后调用engine中的load方法，我们再来看看load方法的源码：

public <R> LoadStatus load(
      GlideContext glideContext,
      Object model,
      Key signature,
      int width,
      int height,
      Class<?> resourceClass,
      Class<R> transcodeClass,
      Priority priority,
      DiskCacheStrategy diskCacheStrategy,
      Map<Class<?>, Transformation<?>> transformations,
      boolean isTransformationRequired,
      Options options,
      boolean isMemoryCacheable,
      boolean useUnlimitedSourceExecutorPool,
      boolean onlyRetrieveFromCache,
      ResourceCallback cb) {
    Util.assertMainThread();
    long startTime = LogTime.getLogTime();

    EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);

    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
    if (cached != null) {
      cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Loaded resource from cache", startTime, key);
      }
      return null;
    }

    EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
      cb.onResourceReady(active, DataSource.MEMORY_CACHE);
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Loaded resource from active resources", startTime, key);
      }
      return null;
    }

    EngineJob<?> current = jobs.get(key);
    if (current != null) {
      current.addCallback(cb);
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Added to existing load", startTime, key);
      }
      return new LoadStatus(cb, current);
    }

    EngineJob<R> engineJob = engineJobFactory.build(key, isMemoryCacheable,
        useUnlimitedSourceExecutorPool);
    DecodeJob<R> decodeJob = decodeJobFactory.build(
        glideContext,
        model,
        key,
        signature,
        width,
        height,
        resourceClass,
        transcodeClass,
        priority,
        diskCacheStrategy,
        transformations,
        isTransformationRequired,
        onlyRetrieveFromCache,
        options,
        engineJob);
    jobs.put(key, engineJob);
    engineJob.addCallback(cb);
    engineJob.start(decodeJob);

    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logWithTimeAndKey("Started new load", startTime, key);
    }
    return new LoadStatus(cb, engineJob);
  }

哇吼，所有重要的东西都在这里了，解析下：

①：判断是否在主线程运行，说明到目前为止还是在主线程执行的，并没有真正的开启子线程。

②：通过keyFactory工厂来构建一个EngineKey对象，key关联着model，也就是url，它很根据model，view的宽高等等属性来构建一个EngineKey对象，这个对象可以用来指定缓存地址，可以用来从缓存中查找资源等。

③：根据创建的key对象分别调用loadFromCache和loadFromActiveResources方法来从内存中查找是否有缓存资源，如果有，则回调cb.onResourceReady来直接设置图片了。

④：分别使用engineJobFactory和decodeJobFactory构建EngineJob和DecodeJob对象，这两个对象是真正的加载资源的两个重要类，EngineJob对象负责开启线程去加载资源，并且加载得资源后转换到主线程并进行回调；DecodeJob是真正的执行者，它就是去网络加载资源的地方，EngineJob开启线程，真正执行的是DecodeJob，DecodeJob之后完毕之后叫道EngineJob去分发回调。这就是这两个类的关系。

⑤：EngineJob和DecodeJob的构建是基本一致的，我们看看比较复杂的DecodeJob的构建：在build方法中，首先通过pool来创建一个DecodeJob对象，然后调用DecodeJob对象的init方法进行初始化，在初始化中值得注意的是调用了decodeHelper对象的init方法。decodeHelper方法是DecodeJob的重要辅助类，后面我们会详细的接触它。

⑥：上面也提到回调，这里先cb添加到engineJob.addCallback();中，然后调用EngineJob的start方法来开启线程。

我们再来看看start方法中的源码：

start方法中将会调用GlideExecutor的execute方法：

execute中正式的开启了线程池进行加载资源。由此我们也正式的由主线程转到了子线程中。

上面我们也分析了，真正执行线程的是在DecodeJob类中，那么我们去看看的run方法是怎么执行的：

run方法中调用runWrapped方法，主要就是在它里面执行的，来看看它的源码：

我们知道，在构造DecodeJob时调用init方法是runReason被赋值为INITIALIZE值，由此它将会进入到INITIALIZE分支中，调用getNextStage方法：

在getNextStage方法中经错几次的经转会返回Stage.SOURCE值，然后在调用getNextGenerator方法来获取当前的currentGenerator对象，我们在来看看获取的这个currentGenerator到底是什么？

getNextGenerator方法中根据stage值来创建对象，由此我们可以知道currentGenerator是一个SourceGenerator对象，那么我们继续往下走，来看看runGenerators方法：

runGenerators最重要的就是执行了currentGenerator的startNext方法，这里将会真正的去加载网络资源：

我们从上面知道currentGenerator就是SourceGenerator对象，那么我们去看看SourceGenerator中startNext的实现：

到这里就太关键了，因为很多人都死在这一步上，根本找不到是怎么去加载资源的，是怎么执行到我们熟悉的HttpURLConnection的，那么到这里你千万不能分神，稍微分神就会转迷糊了，哈哈，那么接下来就开始分析吧：

由于我们在创建SourceGenerator对象时，只是传递了DecodeHelper和回调cb对象，其他的一切初始化操作都是不存在的，所以在startNext中，前面的两个判断是不成立的，主要是看while循环里面的内容：

while循环中首先调用hasNextModelLoader进行判断，我们来看下hasNextModelLoader的内容，这里必须集中精力理解清楚，不然肯定不知所云：

private boolean hasNextModelLoader() {
    return loadDataListIndex < helper.getLoadData().size();
  }

在hasNextModelLoader中它要去helper加载数据，调用getLoadData方法，我们跟进去看看：

在getLoadData方法中是调用GlideContext中的getRegistry方法来回去Registry对象，它是在Glide的构造方法中创建的，而且注册添加了很多解析器还记得吗？不记得的赶快去看看Glide的构造方法。这里我们插入一点非常重要的分析，理解清楚它对接下来的网络执行非常的重要：回到Glidet的构造方法来看看Registry中几个特殊的解析类：

registry.register(xx)
		.append(xx)
		...
		.append(Uri.class, InputStream.class, new HttpUriLoader.Factory())
		...
		.append(GlideUrl.class, InputStream.class, new HttpGlideUrlLoader.Factory())
		...
		;

还有印象这段很长的代码吧？

我们重点来看看上面的两个append方法，其他的都是一样或是类似的道理的。跟进去registry的append方法中：

继续进入modelLoaderRegistry.append方法中：

再跟进multiModelLoaderFactory.append方法中：

重点来了，最后进去add方法：

这里可以看到什么？你理解了吗？

创建了一个Entry对象，把我们的modelClass，dataClass和factory对象关联起来，然后存放到entries的list集合中，就这么简单，但是对这个Entry对象的理解关系到我们后面对整个网络加载的流程十分的巨大，ok，到这里，我们插入的讲解已经完了，主要想告诉你的就是这个entries集合包含了那些对象和创建Entry对象所关联的类和工厂。

那么现在回到DecodeHelper中的getLoadData方法中，它从GlideContext获取到Registry对象，Registry对象有哪些内容在上面的插入讲解中也已举特例分析了，然后调用getModelLoaders方法，并传进model对象，那么来看看它是怎么实现的：

它会从modelLoaderRegistry中获取，在来看：

它会通过model从getModelLoadersForClass方法中获取到modelLoaders的集合，来看看：

首先从cache缓存中获取，如果为空，将会从multiModelLoaderFactory工厂中获取，在继续跟进multiModelLoaderFactory的build方法看看:

从entries集合中分别的遍历出entry对象，然后调用entry.handles来进行匹配是否符合，来看handles方法：

this.modelClass是什么还记得吗？没错就是在Glide创建Registry对象是append的XX.class，例如：

.append(Uri.class, InputStream.class, new HttpUriLoader.Factory())

而modelClass呢，这里就是我们传递用来加载网络图片的一个url地址，那么调用isAssignableFrom方法进行匹配，我们知道entries包含很多的解析器，所以在这一步将会排除掉不匹配的解析器，然后调用调用build方法来创建加载器：

entry.factory知道是什么吧？没错就是append方法中new的一个工厂类。

还是以下面的特例来说：

.append(Uri.class, InputStream.class, new HttpUriLoader.Factory())

在这里这个factory就是HttpUriLoader.Factory，我们来看看它是怎么实现的：

这里它将会multiFactory.build方法来构造一个ModelLoader对象，看清楚它传递的参数：GlideUrl.class, InputStream.class，然后跟进去查看：

历史总是惊人的相似，再次从entries中获取Entry对象，然后调用entry.handles方法根据GlideUrl.class, InputStream.class这两个参数进行匹配过滤。

然后我们找到了以下的append内容相匹配的Entry对象

.append(GlideUrl.class, InputStream.class, new HttpGlideUrlLoader.Factory())

找到HttpGlideUrlLoader.Factory之后，然后调用build方法去构建，在build方法中同样的方式调用entry.factory.build(this)，来看看HttpGlideUrlLoader.Factory()的build的源码：

直接的创建一个HttpGlideUrlLoader对象并返回。

到此我们获取了真正的图片加载对象，然后我们回到HttpUriLoader的Factory中：在multiFactory.build(GlideUrl.class, InputStream.class)获取到HttpGlideUrlLoader对象后，并传递到创建的HttpUriLoader对象中去，我们来看看：

把HttpGlideUrlLoader对象赋值给HttpUriLoader的成员变量this.urlLoader中。

ok，到此我们真正的加载器已经获取到了，当然并不是只有一个，可能有多个，因为在Registry注册了多个可以解析Uri.class的解析器。

好，我们在回到ModelLoaderRegistry类中的getModelLoaders方法中，从getModelLoadersForClass方法中我们获取到了可以解析我们请求modle的所有解析器，通过for循环遍历出所有的解析器，存放到filteredLoaders集合中并返回，一直返回到DecodeHelper类中的getLoadData方法中。

然后遍历modelLoaders集合，分别获取ModelLoader对象，并调用buildLoadData方法，我们知道modelLoaders集合中一定会包含一个ModelLoader是HttpUriLoader，那来看看它的buildLoadData方法：

它会调用urlLoader.buildLoadData方法，这个urlLoader就是HttpGlideUrlLoader对象，再来看看：

这里最重要的就是创建个一个HttpUrlFetcher对象：

然后把HttpUrlFetcher对象存放到新建的LoadData对象中：

最后把LoadData对象返回，我们往上返回到SourceGenerator的startNext方法中：

在获取到LoadData对象后，调用loadData.fetcher.loadData(helper.getPriority(), this);这个方法，从上面分析loadData.fetcher就是HttpUrlFetcher对象，那我们来看看它里面的loadData是怎么加载数据的：

它会调用loadDataWithRedirects方法来返回一个InputStream输入流，来看看loadDataWithRedirects的源码：

private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl,
      Map<String, String> headers) throws IOException {
    if (redirects >= MAXIMUM_REDIRECTS) {
      throw new HttpException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");
    } else {
      // Comparing the URLs using .equals performs additional network I/O and is generally broken.
      // See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html.
      try {
        if (lastUrl != null && url.toURI().equals(lastUrl.toURI())) {
          throw new HttpException("In re-direct loop");

        }
      } catch (URISyntaxException e) {
        // Do nothing, this is best effort.
      }
    }

    urlConnection = connectionFactory.build(url);
    for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
      urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
    }
    urlConnection.setConnectTimeout(timeout);
    urlConnection.setReadTimeout(timeout);
    urlConnection.setUseCaches(false);
    urlConnection.setDoInput(true);

    // Stop the urlConnection instance of HttpUrlConnection from following redirects so that
    // redirects will be handled by recursive calls to this method, loadDataWithRedirects.
    urlConnection.setInstanceFollowRedirects(false);

    // Connect explicitly to avoid errors in decoders if connection fails.
    urlConnection.connect();
    if (isCancelled) {
      return null;
    }
    final int statusCode = urlConnection.getResponseCode();
    if (statusCode / 100 == 2) {
      return getStreamForSuccessfulRequest(urlConnection);
    } else if (statusCode / 100 == 3) {
      String redirectUrlString = urlConnection.getHeaderField("Location");
      if (TextUtils.isEmpty(redirectUrlString)) {
        throw new HttpException("Received empty or null redirect url");
      }
      URL redirectUrl = new URL(url, redirectUrlString);
      return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
    } else if (statusCode == -1) {
      throw new HttpException(statusCode);
    } else {
      throw new HttpException(urlConnection.getResponseMessage(), statusCode);
    }
  }

这里的代码我们就非常的熟悉了，稍微的简单介绍下：

①：connectionFactory对象是在创建HttpUrlFetcher对象时在构造方法中初始化的，它就是DEFAULT_CONNECTION_FACTORY，也就是DefaultHttpUrlConnectionFactory工厂类，当调用它的build方法时：

通过url打开连接，返回一个HttpURLConnection对象，用于网络请求，这些代码平常我们都有接触，不多说。

②：建立连接，过去返回状态码，判断，然后通过getStreamForSuccessfulRequest方法返回一个InputStream输入流。

在获取到InputStream输入流之后，最会将会调用callback.onDataReady(result);回调方法，并把输入流传递过去。

那这个callback是什么呢？

还记得loadData.fetcher.loadData(helper.getPriority(), this);这段代码吧？

没错他就是SourceGenerator类实现的DataCallback回调类。

那么在进到SourceGenerator找到onDataReady方法吧：

在这里它又调用cb回调类的onDataFetcherReady方法，并传递了相关参数：loadData.fetcher是HttpUrlFetcher，loadData.fetcher.getDataSource()则是DataSource.REMOTE：

 @Override
  public DataSource getDataSource() {
    return DataSource.REMOTE;
  }

那么这个cb又是什么呢，它是FetcherReadyCallback回调类，在DecodeJob中实现，那么回到DecodeJob的onDataFetcherReady方法中：

在onDataFetcherReady方法中保存了相关的参数变量，判断是否是当前线程，然后调用decodeFromRetrievedData方法来解码数据：

首先创建一个Resource类型的变量，通过decodeFromData方法把输入流解码并返回给resource，由此可也看出，解码主要是在decodeFromData方法中：

在这里已经体现loadData.fetcher这个fetcher的用意，主要是去关闭输入流和HttpUrlConnection的。

@Override
  public void cleanup() {
    if (stream != null) {
      try {
        stream.close();
      } catch (IOException e) {
        // Ignore
      }
    }
    if (urlConnection != null) {
      urlConnection.disconnect();
    }
  }

在这之前它又调用decodeFromFetcher方法来进行解码返回一个Resource：

在这里获取到data.getClass，这个Class就是InputStrem.class，那么在调用decodeHelper.getLoadPath方法后，我们来看看做了哪些操作：

getLoadPath方法啥也没做，直接调用Registry中的getLoadPath，并传递了拥有的变量，其中resourceClass是Object.class，transcodeClass则是Drawable.class，这是在前面已构建初始化好的，直接拿来用。

我们在来跟进去看看

这里首先从loadPathCache缓存中获取LoadPath对象，如果没有则调用getDecodePaths方法进行获取：

getDecodePaths方法中还是蛮重要的，对真个解码过程的理解有很大的帮助，所以我们来认真的分析下：

①：首先从decoderRegistry.getResourceClasses方法中获取已经注册的registeredResourceClasses：

还记得我们创建Registry是注册了一大堆的东西吗？

对，通过handles方法对InputStrem.class和Object.class进行匹配的就是我们用红色框画出来的部分。由此我们可以得出registeredResourceClasses集合中分别对应的是Bitmap.class，BitmapDrawable.class和GifDrawable.class的三种Class对象。

②：遍历registeredResourceClasses集合，通过transcoderRegistry.getTranscodeClasses方法获取到已注册的registeredTranscodeClasses集合：

这是对registeredResourceClasses集合的再次匹配，我们知道transcodeClasses实际上是Drawable.class，在registeredResourceClasses集合中只有BitmapDrawable.class和GifDrawable.class是继承Drawable的，由此我们得出registeredTranscodeClasses包含BitmapDrawable.class和GifDrawable.class两种Class对象。

那么由此可知decoders存放了两种解码器：

对应的BitmapDrawable的BitmapDrawableDecoder解码器。

对应的GifDrawable.class的StreamGifDecoder解码器。

这个非常重要，在后面有使用到。必须理解清楚。

③：通过上面获取的registeredResourceClass和registeredTranscodeClass获取到transcoder转化器，主要是从transcoderRegistry集合中通过get方法获取，而transcoderRegistry又包含哪些转化器呢？

而又有get方法我们可以知道：

当时普通图片是transcoder将会是BitmapDrawableTranscoder，如是过动态图片gif的话transcoder将会是GifDrawableBytesTranscoder。

然后把它们存放到创建的DecodePath对象中：

最后是把封装好的DecodePath对象存储到decodePaths集合中并返回。

然后在回到Registry中的getLoadPath方法中，在获取到decodePaths集合中，把它和dataClass, resourceClass, transcodeClass又封装到LoadPath对象中，并缓存到loadPathCache对象中。

再次返回DecodeJob类中的decodeFromFetcher方法中，在获取到LoadPath后，调用runLoadPath方法，来看下它的源码：

它调用glideContext.getRegistry()获取Registry对象，然后调用Registry的getRewinder获取装置器，跟进去看看：

在getRewinder方法中直接的调用dataRewinderRegistry对象的build方法，那么这个dataRewinderRegistry又是什么呢？

它是在Registry构造方法中创建的对象：

this.dataRewinderRegistry = new DataRewinderRegistry();

而且在Glide中进行了注册：

获取到factory之后调用dataRewinderRegistry.register方法注册到Map集合rewinders中去：

再来看看factory.getDataClass()都获取到哪些key：

①：在ByteBufferRewinder.Factory中调用getDataClass()获取的key是ByteBuffer.class

②：在InputStreamRewinder.Factory中调用getDataClass()获取的key是InputStream.class

上面两个key值在接下来会使用到。

那么我们在返回到getRewinder方法中，调用dataRewinderRegistry对象的build方法到底做了什么：

在build的方法中总共做了四件事，分别用不同的线框标注出来了：

①：从rewinders集合中获取到和data.getClass()相匹配的Factory对象，从上面的分析中，我们知道rewinders注册的只有两个key，分别是ByteBuffer.class和InputStream.class，而我们又知道data.getClass()是一个InputStream.class，由此可以匹配成功。这个result就是InputStreamRewinder.Factory对象。

②：假如result没有匹配成功的话，也就是没有通过key匹配成功，那么就进行遍历rewinders集合，通过values值进行匹配，把匹配成功的Factory对象再赋值给result。

③：假如通过键key和值values都没有匹配成功，那么也不要紧，直接使用默认的DEFAULT_FACTORY

④：最后调用result的build方法。

这里由于我们通过键key直接已匹配成功，所以我们知道result就是InputStreamRewinder.Factory对象，那么来看看调用它的build方法做了什么事情：

这里直接的返回了一个InputStreamRewinder对象，在InputStreamRewinder的构造方法中又创建了RecyclableBufferedInputStream对象，并它InputStream流传递进去：

RecyclableBufferedInputStream继承FilterInputStream流，那么我们的InputStream流最终保存的位置就是在FilterInputStream类中。

ok，到这里我们知道了InputStream数据流的去向，而在InputStreamRewinder中又有对InputStream流的引用，那么在回到InputStreamRewinder之后我们来看看接下来又做了什么呢？

再次定位到DecodeJob类中的runLoadPath方法，在获取到InputStreamRewinder后，它会调用path.load方法并返回Resource资源类，这个path是在之前获取到的LoadPath对象，这里注意下，传递了一个new DecodeCallback 对象的回调类，后面会用到。最后调用InputStreamRewinder.cleanup()进行资源释放。那么我们来看看LoadPath的load方法是怎么实现的：

它直接调用loadWithExceptionList方法进行移交：

在loadWithExceptionList方法中则会调用decode方法进行解码：

decode方法中调用decodeResource方法，然后在调用decodeResourceWithList方法真正的开始解码：

①：这里首先遍历decoders集合，分别的获取到ResourceDecoder解码器，还记得我们的decoders都包含哪些解码器吗？没错主要包含两种：BitmapDrawable.class和GifDrawable.class。不记得的往上面翻下，上面已详细的讲解过了。

②：然后通过rewinder.rewindAndGet()获取我们的InputStream数据流：

③：通过decoder.handles(data, options)方法来过滤掉不相匹配的解码器，再来看看前面的这张图：

Bitmap.class已被我们过滤掉，剩下的就只有BitmapDrawable.class和GifDrawable.class，当我们调用handles方法进行匹配时，StreamGifDecoder解码器是怎么处理的：

它主要是针对options属性为gif的图片来解码的，其实这不用我说大家也是知道的，而我们加载的只是普通的静态图片，因此它是不符合我们的匹配规则的，在来看BitmapDrawableDecoder中，它传入的是StreamBitmapDecoder的解码器：

而downsampler.handles(source);中只要source是InputStream就返回true，因此匹配成功。

那么由上分析，我们真正的decoder就是BitmapDrawableDecoder。

回到decodeResourceWithList方法中，获取到真正的decoder解码器，将会调用decode方法正式解码：

它又会交给StreamBitmapDecoder的decode方法，然后在转移到Downsampler类中的decode方法中：

这里就不再一个一个的看方法了，主要是在Downsampler中decodeFromWrappedStreams方法中把InputStream数据流根据width, height, options给转化成Bitmap图片，然后把Bitmap存放到BitmapResource对象中去且直接的返回本身。

ok，获取到BitmapResource对象后，再次返回最初开始解码的DecodePath类中的decode方法中：

从上面分析我们知道，我们解析的是普通的图片，所以这个transcoder就是BitmapDrawableTranscoder转换器类。（前面有详细的分析，忘记的可以向上翻看）

接着我们去BitmapDrawableTranscoder中的transcode方法看看：

在transcode方法中通过toTranscode.get()获取bitmap图片，这个bitmap虽然经过多层的包装，它其实就是一个BitmapResource对象，这在上面我们有清楚的分析，只不过在返回的回调方法中有多次的封装而已。

获取到Bitmap图片后，调用LazyBitmapDrawableResource的obtain方法再次进行一次的封装：

把Bitmap封装到LazyBitmapDrawableResource对象中进行返回。

ok，到这里其实已完成了完完全全的解码和封装到。

一路把LazyBitmapDrawableResource对象返回到DecodeJob类中的decodeFromRetrievedData中，并赋值给resource变量：

当resource不为空时，将会调用notifyEncodeAndRelease方法并传递参数：

方法里面就不多解析了，它会调用notifyComplete方法：

这里调用了callback.onResourceReady(resource, dataSource);方法，那这个callback是什么呢？它其实是一个ResourceCallback，在SingleRequest中发起的，并且SingleRequest还实现了ResourceCallback接口内的方法：

public void onResourceReady(Resource<?> resource, DataSource dataSource) {
    stateVerifier.throwIfRecycled();
    loadStatus = null;
    if (resource == null) {
      GlideException exception = new GlideException("Expected to receive a Resource<R> with an "
          + "object of " + transcodeClass + " inside, but instead got null.");
      onLoadFailed(exception);
      return;
    }

    Object received = resource.get();
    if (received == null || !transcodeClass.isAssignableFrom(received.getClass())) {
      releaseResource(resource);
      GlideException exception = new GlideException("Expected to receive an object of "
          + transcodeClass + " but instead" + " got "
          + (received != null ? received.getClass() : "") + "{" + received + "} inside" + " "
          + "Resource{" + resource + "}."
          + (received != null ? "" : " " + "To indicate failure return a null Resource "
          + "object, rather than a Resource object containing null data."));
      onLoadFailed(exception);
      return;
    }

    if (!canSetResource()) {
      releaseResource(resource);
      // We can't put the status to complete before asking canSetResource().
      status = Status.COMPLETE;
      return;
    }

    onResourceReady((Resource<R>) resource, (R) received, dataSource);
  }

重点讲解下：在onResourceReady中使用resource.get()，我们知道这个resource就是LazyBitmapDrawableResource对象，来看看这个get获取到了什么：

在get中获取到了BitmapDrawable对象直接复制给了received变量，然后调用重载方法onResourceReady方法：

在onResourceReady方法中调用了target.onResourceReady(result, animation);还记得target是什么吗？

它在load方法中已讲解过，就是DrawableImageViewTarget对象，调用它的onResourceReady会转移到父类ImageViewTarget中：

然后在调用setResourceInternal方法：

setResource是抽象方法，由它的子类实现，我们在回到DrawableImageViewTarget中：

到这里直接调用view进行设置图片了，这个view就是我们Imageview了，所以到这里就设置好了加载的图片了。

ok，到这里就完完全全的解析完了Glide的执行原理了。

说实在的Glide的源码非常的复杂，往往深入进去就无法出来了，相信这篇博客很能好的给大家一个参考，能让大家对整个Glide有个全面的理解。

好了，终于写完了，真的很不容易，很辛苦，希望大家也能从中学到知识。

各位如果还有哪里不明白的，或是我这里讲的还不够透彻，亦或是讲错了的地方请留言指正，让我们共同进步，谢谢

同时，请大家扫一扫关注我的微信公众号，虽然写的不是很勤，但是每一篇都有质量保证，让您学习到真正的知识。