Glide4（二）内部源码解析

Posted on | 本文阅读 次

上一篇讲到了Glide4.x 的基本功能和使用，如有不了解Glide4的可以查看上一篇文章Glide4（一）基本使用，今天这一篇是从源码的角度来分析Glide4。
上一篇讲到Glide的基本使用核心就只用到一句话 Glide.with(this).load(mUrl).into(mImageView);代码很简单，那么我们就从这句话出发一步一步向前深入。

一、with()

首先我们先看Glide.with（）源码里面做了哪些操作。点击with我们首先会进入到Glide这个类中，看源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
  * Begin a load with Glide by passing in a context.
  * @param context Any context, will not be retained.
  * @return A RequestManager for the top level application that can be used to start a load.
  * @see #with(android.app.Activity)
  * @see #with(android.app.Fragment)
  * @see #with(android.support.v4.app.Fragment)
  * @see #with(android.support.v4.app.FragmentActivity)
  */
 @NonNull
 public static RequestManager with(@NonNull Context context) {
   return getRetriever(context).get(context);
 }
 
 @NonNull
 public static RequestManager with(@NonNull Activity activity) {
   return getRetriever(activity).get(activity);
 }
 ...
 @NonNull
 public static RequestManager with(@NonNull FragmentActivity activity) {
   return getRetriever(activity).get(activity);
 }

 ...
 
 @NonNull
 public static RequestManager with(@NonNull View view) {
   return getRetriever(view.getContext()).get(view);
 }

可以看到在代码中，有很多with方法，并且带有不同的参数，参数也就是Context，Acyivity，Fragment等，这里就不展开讨论。虽然参数不同，但是with方法的目的是一样的，都是为了返回一个RequestManager对象。那么RequestManager是用来做什么的呢？

1
* @return A RequestManager that can be used to start a load.

我们从上面的注释中可以了解到，RequestManager对象是为下一步load做准备，做开始加载数据之用。那么RequestManager对象是如何获取到的呢？在with方法中，最主要的一句话是getRetriever(activity).get(activity);我们跟进到getRetriever方法中可以看到以下代码：

1
2
3
4
5
6
7
8
9
10
11
@NonNull
private static RequestManagerRetriever getRetriever(@Nullable Context context) {
  // Context could be null for other reasons (ie the user passes in null), but in practice it will
  // only occur due to errors with the Fragment lifecycle.
  Preconditions.checkNotNull(
      context,
      "You cannot start a load on a not yet attached View or a Fragment where getActivity() "
          + "returns null (which usually occurs when getActivity() is called before the Fragment "
          + "is attached or after the Fragment is destroyed).");
  return Glide.get(context).getRequestManagerRetriever();
}

看到在getRetriever方法中通过 Glide.get(context).getRequestManagerRetriever();获取到RequestManagerRetriever对象，然后通过RequestManagerRetriever去获取RequestManager。
顺利获得RequestManager，那么with的工作也就做完了，从上面的代码可以看到with方法的源码还是很简单的，只为了获取到RequestManager，开始加载数据。
接着我们来看load（）中做了哪些操作。

二、load()

同样的点击load，我们进入到RequestManager这个类中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
...

@Override
public RequestBuilder<Drawable> load(@Nullable Bitmap bitmap) {
  return asDrawable().load(bitmap);
}

@Override
public RequestBuilder<Drawable> load(@Nullable Drawable drawable) {
  return asDrawable().load(drawable);
}

@Override
public RequestBuilder<Drawable> load(@Nullable String string) {
  return asDrawable().load(string);
}

@Override
public RequestBuilder<Drawable> load(@Nullable Uri uri) {
  return asDrawable().load(uri);
}

...

因为代码很多，就只保留主线。上述代码可以看到带有不同参数的load方法中都有同样的一句代码asDrawable().load(model)，是为了得到RequestBuilder对象，RequestBuilder用以处理不同类型资源并且初始加载，那么到底Glide 是如何处理load的？我们接着进入到asDrawable（）方法中。

1
2
3
4
5
@NonNull
  @CheckResult
  public RequestBuilder<Drawable> asDrawable() {
    return as(Drawable.class);
  }

可以看到asDrawable（）方法中只有一句代码，我们接着进到as（）方法中。

1
2
3
4
5
6
@NonNull
  @CheckResult
  public <ResourceType> RequestBuilder<ResourceType> as(
      @NonNull Class<ResourceType> resourceClass) {
    return new RequestBuilder<>(glide, this, resourceClass, context);
  }

上述代码可以看到as方法也没做很多处理，只是new 了一个RequestBuilder对象。那么我们就接着进入到load（）中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
@NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable Bitmap bitmap) {
    return loadGeneric(bitmap)
        .apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
  }

  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable Drawable drawable) {
    return loadGeneric(drawable)
        .apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
  }

  
  @NonNull
  @Override
  @CheckResult
  public RequestBuilder<TranscodeType> load(@Nullable String string) {
    return loadGeneric(string);
  }


  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable Uri uri) {
    return loadGeneric(uri);
  }

 
  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable File file) {
    return loadGeneric(file);
  }


  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@RawRes @DrawableRes @Nullable Integer resourceId) {
    return loadGeneric(resourceId).apply(signatureOf(ApplicationVersionSignature.obtain(context)));
  }

  
  @Deprecated
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable URL url) {
    return loadGeneric(url);
  }

  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<TranscodeType> load(@Nullable byte[] model) {
    RequestBuilder<TranscodeType> result = loadGeneric(model);
    if (!result.requestOptions.isDiskCacheStrategySet()) {
        result = result.apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
    }
    if (!result.requestOptions.isSkipMemoryCacheSet()) {
      result = result.apply(skipMemoryCacheOf(true /*skipMemoryCache*/));
    }
    return result;
  }

我们可以看见在RequestBuilder的类中，load方法带有例如Url，Drawable等参数，这样就正式开始加载原始资源。所有的load都将参数带入到loadGeneric（）方法中，我们点进去看一下。

1
2
3
4
5
6
@NonNull
 private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
   this.model = model;
   isModelSet = true;
   return this;
 }

loadGeneric也没有做什么特殊的处理，只是将传进来的资源进行保存，并设置isModelSet为true，这个isModelSet的设置是为了告诉后面into方法资源已经设置完毕，否则就不会进行into的处理，并抛出异常”You must call #load() before calling # into()”，这个在下面into的源码中可以看到。

三、into()

上面我们分析了Glide.with.load的源码，其实with和load都很简单，重头戏在于into。那接着我们开始最后一步的操作into，点击进入源码，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
/**
  * Sets the {@link ImageView} the resource will be loaded into, cancels any existing loads into
  * the view, and frees any resources Glide may have previously loaded into the view so they may be
  * reused.
  *
  * @see RequestManager#clear(Target)
  *
  * @param view The view to cancel previous loads for and load the new resource into.
  * @return The
  * {@link com.bumptech.glide.request.target.Target} used to wrap the given {@link ImageView}.
  */
 @NonNull
 public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
   Util.assertMainThread();
   Preconditions.checkNotNull(view);

   RequestOptions requestOptions = this.requestOptions;
   if (!requestOptions.isTransformationSet()
       && requestOptions.isTransformationAllowed()
       && view.getScaleType() != null) {
     // Clone in this method so that if we use this RequestBuilder to load into a View and then
     // into a different target, we don't retain the transformation applied based on the previous
     // View's scale type.
     switch (view.getScaleType()) {
       case CENTER_CROP:
         requestOptions = requestOptions.clone().optionalCenterCrop();
         break;
       case CENTER_INSIDE:
         requestOptions = requestOptions.clone().optionalCenterInside();
         break;
       case FIT_CENTER:
       case FIT_START:
       case FIT_END:
         requestOptions = requestOptions.clone().optionalFitCenter();
         break;
       case FIT_XY:
         requestOptions = requestOptions.clone().optionalCenterInside();
         break;
       case CENTER:
       case MATRIX:
       default:
         // Do nothing.
     }
   }

   return into(
       glideContext.buildImageViewTarget(view, transcodeClass),
       /*targetListener=*/ null,
       requestOptions);
 }

在代码中 首先我们可以看一下注释，注释上面说into方法是设置将要加载的资源，取消当前加载到视图中的所有加载，释放之前加载到视图中的所有资源，然后重新使用。就是将资源设置到指定位置。
那么我们就来分析into中做了哪些处理。首先可以看到此方法中获取到了一个requestOptions对象，然后根据view缩放类型的不同，设置requestOptions内置参数。这段代码不是很重要，就不展开描述，重头戏在最后一句into(glideContext.buildImageViewTarget(view, transcodeClass),
/targetListener=/ null,requestOptions);，into方法中传入了三个参数，第一个是viewTarget，第二个是targetListener，这个不用管，第三个就是刚刚获取的requestOptions。而其中的第一个参数viewTarget就是用来放置最后的图片的。那么我们先来看看viewTarget是如何获取到的。进入到buildImageViewTarget（）方法中：

1
2
3
4
5
@NonNull
public <X> ViewTarget<ImageView, X> buildImageViewTarget(
    @NonNull ImageView imageView, @NonNull Class<X> transcodeClass) {
  return imageViewTargetFactory.buildTarget(imageView, transcodeClass);
}

buildImageViewTarget只是一个中转站，我们接着进入到buildTarget中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/**
 * A factory responsible for producing the correct type of
 * {@link com.bumptech.glide.request.target.Target} for a given {@link android.view.View} subclass.
 */
public class ImageViewTargetFactory {
  @NonNull
  @SuppressWarnings("unchecked")
  public <Z> ViewTarget<ImageView, Z> buildTarget(@NonNull ImageView view,
      @NonNull Class<Z> clazz) {
    if (Bitmap.class.equals(clazz)) {
      return (ViewTarget<ImageView, Z>) new BitmapImageViewTarget(view);
    } else if (Drawable.class.isAssignableFrom(clazz)) {
      return (ViewTarget<ImageView, Z>) new DrawableImageViewTarget(view);
    } else {
      throw new IllegalArgumentException(
          "Unhandled class: " + clazz + ", try .as*(Class).transcode(ResourceTranscoder)");
    }
  }
}

在buildTarget中可以清楚的看到，根据我们传入的Class类型不同，就返回不同类型的ViewTarget。例如是Bitmap类型的资源，最后返回的就是BitmapImageViewTarget类型的ViewTarget。获取到了ViewTarget，那么我们就返回来看into（）这个方法，跟进去可以看到如下代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
private <Y extends Target<TranscodeType>> Y into(
      @NonNull Y target,
      @Nullable RequestListener<TranscodeType> targetListener,
      @NonNull RequestOptions options) {
    Util.assertMainThread();
    Preconditions.checkNotNull(target);
    if (!isModelSet) {
      throw new IllegalArgumentException("You must call #load() before calling #into()");
    }

    options = options.autoClone();
    Request request = buildRequest(target, targetListener, options);

    Request previous = target.getRequest();
    if (request.isEquivalentTo(previous)
        && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {
      request.recycle();
      // If the request is completed, beginning again will ensure the result is re-delivered,
      // triggering RequestListeners and Targets. If the request is failed, beginning again will
      // restart the request, giving it another chance to complete. If the request is already
      // running, we can let it continue running without interruption.
      if (!Preconditions.checkNotNull(previous).isRunning()) {
        // Use the previous request rather than the new one to allow for optimizations like skipping
        // setting placeholders, tracking and un-tracking Targets, and obtaining View dimensions
        // that are done in the individual Request.
        previous.begin();
      }
      return target;
    }

    requestManager.clear(target);
    target.setRequest(request);
    requestManager.track(target, request);

    return target;
  }

我们把目光放在这段代码，可以发现刚才在with模块结尾的地方提到的将isModelSet设为true在这段代码中就有所体现，也就是说如果load没有将资源设置好是不会进行接下来into的处理的。
那么我们接着往下看有一段buildRequest的代码，构建一个Request，而Request的作用在于发出一个加载图片的请求，我们点进去查看Request是如何构建的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
private Request buildRequest(
    Target<TranscodeType> target,
    @Nullable RequestListener<TranscodeType> targetListener,
    RequestOptions requestOptions) {
  return buildRequestRecursive(
      target,
      targetListener,
      /*parentCoordinator=*/ null,
      transitionOptions,
      requestOptions.getPriority(),
      requestOptions.getOverrideWidth(),
      requestOptions.getOverrideHeight(),
      requestOptions);
}

可以看到buildRequest中又调用了buildRequestRecursive，那么我们就接着跟进去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
private Request buildRequestRecursive(
    Target<TranscodeType> target,
    @Nullable RequestListener<TranscodeType> targetListener,
    @Nullable RequestCoordinator parentCoordinator,
    TransitionOptions<?, ? super TranscodeType> transitionOptions,
    Priority priority,
    int overrideWidth,
    int overrideHeight,
    RequestOptions requestOptions) {

  // Build the ErrorRequestCoordinator first if necessary so we can update parentCoordinator.
  ErrorRequestCoordinator errorRequestCoordinator = null;
  if (errorBuilder != null) {
    errorRequestCoordinator = new ErrorRequestCoordinator(parentCoordinator);
    parentCoordinator = errorRequestCoordinator;
  }

  Request mainRequest =
      buildThumbnailRequestRecursive(
          target,
          targetListener,
          parentCoordinator,
          transitionOptions,
          priority,
          overrideWidth,
          overrideHeight,
          requestOptions);

  if (errorRequestCoordinator == null) {
    return mainRequest;
  }

  int errorOverrideWidth = errorBuilder.requestOptions.getOverrideWidth();
  int errorOverrideHeight = errorBuilder.requestOptions.getOverrideHeight();
  if (Util.isValidDimensions(overrideWidth, overrideHeight)
      && !errorBuilder.requestOptions.isValidOverride()) {
    errorOverrideWidth = requestOptions.getOverrideWidth();
    errorOverrideHeight = requestOptions.getOverrideHeight();
  }

  Request errorRequest = errorBuilder.buildRequestRecursive(
      target,
      targetListener,
      errorRequestCoordinator,
      errorBuilder.transitionOptions,
      errorBuilder.requestOptions.getPriority(),
      errorOverrideWidth,
      errorOverrideHeight,
      errorBuilder.requestOptions);
  errorRequestCoordinator.setRequests(mainRequest, errorRequest);
  return errorRequestCoordinator;
}

可以看到在buildRequestRecursive中创建了两个Request，一个为errorRequest，另外是一个mainRequest，我们主要来看mainRequest里面做了什么。
mainRequest其实是一个处理图片缩略图的请求，括号内的参数也是缩略图的类型。我们看buildThumbnailRequestRecursive这个方法中，对缩略图进行处理。对缩略图的处理又分为了三种情况，我们主要来看最后一种case，no thumbnail的情况，进入到obtainRequest中，可以看到接着调用了SingleRequest.obtain方法，我们就跟进去瞧一瞧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public static <R> SingleRequest<R> obtain(
      Context context,
      GlideContext glideContext,
      Object model,
      Class<R> transcodeClass,
      RequestOptions requestOptions,
      int overrideWidth,
      int overrideHeight,
      Priority priority,
      Target<R> target,
      RequestListener<R> targetListener,
      @Nullable List<RequestListener<R>> requestListeners,
      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(
        context,
        glideContext,
        model,
        transcodeClass,
        requestOptions,
        overrideWidth,
        overrideHeight,
        priority,
        target,
        targetListener,
        requestListeners,
        requestCoordinator,
        engine,
        animationFactory);
    return request;
  }

可以看家代码中调用了request.init，继续跟进去。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
private void init(
     Context context,
     GlideContext glideContext,
     Object model,
     Class<R> transcodeClass,
     RequestOptions requestOptions,
     int overrideWidth,
     int overrideHeight,
     Priority priority,
     Target<R> target,
     RequestListener<R> targetListener,
     @Nullable List<RequestListener<R>> requestListeners,
     RequestCoordinator requestCoordinator,
     Engine engine,
     TransitionFactory<? super R> animationFactory) {
   this.context = context;
   this.glideContext = glideContext;
   this.model = model;
   this.transcodeClass = transcodeClass;
   this.requestOptions = requestOptions;
   this.overrideWidth = overrideWidth;
   this.overrideHeight = overrideHeight;
   this.priority = priority;
   this.target = target;
   this.targetListener = targetListener;
   this.requestListeners = requestListeners;
   this.requestCoordinator = requestCoordinator;
   this.engine = engine;
   this.animationFactory = animationFactory;
   status = Status.PENDING;
 }

这时候就清楚了，只是一个初始化的操作和赋值的操作，那么我们就不要继续再看了。
Request的构建确实是有点长，看完Request我们就回到前面into的方法中。

1
2
target.setRequest(request);
requestManager.track(target, request);

我们可以看见into中将新创建的request设置给了target，然后requestManager调用track方法，我们进入到track中。

1
2
3
4
void track(@NonNull Target<?> target, @NonNull Request request) {
    targetTracker.track(target);
    requestTracker.runRequest(request);
  }

首先将传入的target添加到targetTracker中，然后开始跟踪给定的请求，点进runRequest中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
  * Starts tracking the given request.
  */
 public void runRequest(@NonNull Request request) {
   requests.add(request);
   if (!isPaused) {
     request.begin();
   } else {
     request.clear();
     if (Log.isLoggable(TAG, Log.VERBOSE)) {
       Log.v(TAG, "Paused, delaying request");
     }
     pendingRequests.add(request);
   }
 }

代码中显示如果当前的请求不是停止的，那么就调用request的begin方法，否则就将请求删除。其他的不用管我们主要来看begin方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@Override
  public void begin() {
    assertNotCallingCallbacks();
    stateVerifier.throwIfRecycled();
    startTime = LogTime.getLogTime();
    if (model == null) {
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
        width = overrideWidth;
        height = overrideHeight;
      }
      return;
    }
    ...
    if (status == Status.COMPLETE) {
      onResourceReady(resource, DataSource.MEMORY_CACHE);
      return;
    }
    
    status = Status.WAITING_FOR_SIZE;
    if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
      onSizeReady(overrideWidth, overrideHeight);
    } else {
      target.getSize(this);
    }

    ...
  }

我们看到代码有很多的逻辑判断，第一个为model等于空的情况，而model从上面可以知道是创建request传进来的资源，为空的话就开始调用onLoadFailed方法，点进去可以看见当model为空的时候就开始将ErrorPlaceholder占位符设置进去。
接着我们找到真正开始加载的地方onSizeReady（）方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/**
  * A callback method that should never be invoked directly.
  */
 @Override
 public void onSizeReady(int width, int height) {
   stateVerifier.throwIfRecycled();
   ...
   status = Status.RUNNING;

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

   if (IS_VERBOSE_LOGGABLE) {
     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.isScaleOnlyOrNoTransform(),
       requestOptions.getOptions(),
       requestOptions.isMemoryCacheable(),
       requestOptions.getUseUnlimitedSourceGeneratorsPool(),
       requestOptions.getUseAnimationPool(),
       requestOptions.getOnlyRetrieveFromCache(),
       this);

   ...
 }

首先将status设置为正在查询资源的状态，然后获取图片的宽高，接着就调用engine的load方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
/**
  * Starts a load for the given arguments.
  * @param width  The target width in pixels of the desired resource.
  * @param height The target height in pixels of the desired resource.
  * @param cb     The callback that will be called when the load completes.
  */
 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,
     boolean isScaleOnlyOrNoTransform,
     Options options,
     boolean isMemoryCacheable,
     boolean useUnlimitedSourceExecutorPool,
     boolean useAnimationPool,
     boolean onlyRetrieveFromCache,
     ResourceCallback cb) {
   Util.assertMainThread();
   long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;

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

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

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

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

   EngineJob<R> engineJob =
       engineJobFactory.build(
           key,
           isMemoryCacheable,
           useUnlimitedSourceExecutorPool,
           useAnimationPool,
           onlyRetrieveFromCache);

   DecodeJob<R> decodeJob =
       decodeJobFactory.build(
           glideContext,
           model,
           key,
           signature,
           width,
           height,
           resourceClass,
           transcodeClass,
           priority,
           diskCacheStrategy,
           transformations,
           isTransformationRequired,
           isScaleOnlyOrNoTransform,
           onlyRetrieveFromCache,
           options,
           engineJob);

   jobs.put(key, engineJob);

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

   ...
 }

前面一部分代码主要是缓存方面的操作，就先不分析，后面单开一篇分析Glide的缓存。那么我们接着往下看，首先构建了一个用来开启线程的engineJob，接着创建了一个用来图片解码的decodeJob，然后开始调用engineJob的start方法，并将decodeJob作为参数传进去。那么我们就来看看start的处理。

1
2
3
4
5
6
7
public void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
    GlideExecutor executor = decodeJob.willDecodeFromCache()
        ? diskCacheExecutor
        : getActiveSourceExecutor();
    executor.execute(decodeJob);
  }

start中只是调用了GlideExecutor的execute方法，我们继续跟进去

1
2
3
4
@Override
  public void execute(@NonNull Runnable command) {
    delegate.execute(command);
  }

GlideExecutor开启了一个新线程去加载资源，那么我们就从主线程转到子线程，进入到DecodeJob类中找到run方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@Override
  public void run() {
    ...
    DataFetcher<?> localFetcher = currentFetcher;
    try {
      if (isCancelled) {
        notifyFailed();
        return;
      }
      runWrapped();
    } catch (Throwable t) {
     ...
    }
  }

我们主要看runWrapped方法，发现会出现三种不同的case，咱们不管是什么，最后都会走进runGenerators方法中，我们进去看看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private void runGenerators() {
    currentThread = Thread.currentThread();
    startFetchTime = LogTime.getLogTime();
    boolean isStarted = false;
    while (!isCancelled && currentGenerator != null
        && !(isStarted = currentGenerator.startNext())) {
      stage = getNextStage(stage);
      currentGenerator = getNextGenerator();

      if (stage == Stage.SOURCE) {
        reschedule();
        return;
      }
    }
  }

由于细节太多，我们主要看重要的代码部分，那么就来瞧一瞧while部分的代码，可以看到currentGenerator调用了startNext方法，即SourceCacheGenerator类中的startNext方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@Override
 public boolean startNext() {
   if (dataToCache != null) {
     Object data = dataToCache;
     dataToCache = null;
     cacheData(data);
   }

   if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
     return true;
   }
   sourceCacheGenerator = null;

   loadData = null;
   boolean started = false;
   while (!started && hasNextModelLoader()) {
     loadData = helper.getLoadData().get(loadDataListIndex++);
     if (loadData != null
         && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
         || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
       started = true;
       loadData.fetcher.loadData(helper.getPriority(), this);
     }
   }
   return started;
 }

在while的逻辑中，获取数据的代码开始显现出来了，DecodeHelper调用了getLoadData返回了一个数据的List集合，这里就开始获取到了加载的数据。
这里我们如何获取数据就先暂时不细细的去看，当获取到了数据，那么我们就回到
前面begin的方法中，代码中可以看见有个onResourceReady方法，我们点进去看他具体做了什么。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
private void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {
  // We must call isFirstReadyResource before setting status.
  boolean isFirstResource = isFirstReadyResource();
  status = Status.COMPLETE;
  this.resource = resource;

  if (glideContext.getLogLevel() <= Log.DEBUG) {
    Log.d(GLIDE_TAG, "Finished loading " + result.getClass().getSimpleName() + " from "
        + dataSource + " for " + model + " with size [" + width + "x" + height + "] in "
        + LogTime.getElapsedMillis(startTime) + " ms");
  }

  isCallingCallbacks = true;
  try {
    boolean anyListenerHandledUpdatingTarget = false;
    if (requestListeners != null) {
      for (RequestListener<R> listener : requestListeners) {
        anyListenerHandledUpdatingTarget |=
            listener.onResourceReady(result, model, target, dataSource, isFirstResource);
      }
    }
    anyListenerHandledUpdatingTarget |=
        targetListener != null
            && targetListener.onResourceReady(result, model, target, dataSource, isFirstResource);

    if (!anyListenerHandledUpdatingTarget) {
      Transition<? super R> animation =
          animationFactory.build(dataSource, isFirstResource);
      target.onResourceReady(result, animation);
    }
  } finally {
    isCallingCallbacks = false;
  }

  notifyLoadSuccess();
}

上述代码try的里面target调用了onResourceReady，而这个target我们是不是感觉很熟悉，没错，就是上面一开始通过glideContext.buildImageViewTarget构建的viewTarget，因为上面刚开始分析了，因为Class的不同，target返回的类型也不同，分为两种，一种为BitmapImageViewTarget，一种为DrawableImageViewTarget，那么我们就分别进入到这俩个类中，可以清楚的看见
这两个Target都是继承ImageViewTarget，那么就来看看他两的父类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public abstract class ImageViewTarget<Z> extends ViewTarget<ImageView, Z>
    implements Transition.ViewAdapter {
...

  @Override
  public void onResourceReady(@NonNull Z resource, @Nullable Transition<? super Z> transition) {
    if (transition == null || !transition.transition(resource, this)) {
      setResourceInternal(resource);
    } else {
      maybeUpdateAnimatable(resource);
    }
  }
...
private void setResourceInternal(@Nullable Z resource) {
    // Order matters here. Set the resource first to make sure that the Drawable has a valid and
    // non-null Callback before starting it.
    setResource(resource);
    maybeUpdateAnimatable(resource);
  }
...
protected abstract void setResource(@Nullable Z resource);
}

在onResourceReady方法中调用了setResourceInternal，接着调用setResource方法，这个方法是一个抽象方法代表设置图片。那么具体是怎么设置图片的需要去子类中查看，我们知道BitmapImageViewTarget和DrawableImageViewTarget都是他的子类，就随表进入一个类中，例如BitmapImageViewTarget。

1
2
3
4
5
6
7
8
9
10
11
12
13
public class BitmapImageViewTarget extends ImageViewTarget<Bitmap> {
...
  /**
   * Sets the {@link android.graphics.Bitmap} on the view using {@link
   * android.widget.ImageView#setImageBitmap(android.graphics.Bitmap)}.
   *
   * @param resource The bitmap to display.
   */
  @Override
  protected void setResource(Bitmap resource) {
    view.setImageBitmap(resource);
  }
}

在setResource方法中，view调用了setImageBitmap的方法，也就是说最后我们将图片设置到了ImageView中，这样图片也就显示在了指定位置。
到此为止，Glide从with到load在到into的流程也都分析完毕了！！！

四、最后

虽然只有这么简单的一句话，但是所包含的能量是巨大的，with()、load()、into()三个方法的调用只是Glide的冰山一角，后续还有它强大的缓存机制，加载机制等，这是一个漫长的旅程。

推荐阅读:
Glide 4解析系列（一）：如何使用Glide

参考资料：郭霖Android图片加载框架最全解析（二），从源码的角度理解Glide的执行流程