通过 load 方法得到了 GlideRequest 对象，GlideRequest 类也是编译生成的，它的作用更多的是提供一些可选配置，实际执行还要看 RequestBuilder 对象的 into 方法，
public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
BaseRequestOptions<?> requestOptions = this;
//省略部分代码......
return into(glideContext.buildImageViewTarget(view, transcodeClass),null,requestOptions,Executors.mainThreadExecutor());
}
GlideContext.buildImageViewTarget
这里重点看下 glideContext 的 buildImageViewTarget 方法，
public <X> ViewTarget<ImageView, X> buildImageViewTarget(ImageView imageView,Class<X> transcodeClass) {
return imageViewTargetFactory.buildTarget(imageView, transcodeClass);
}
按前面的分析，两个入参类型分别是 ImageView 和 Drawable。imageViewTargetFactory 会在创建 GlideContext 对象是传入赋值，
public class ImageViewTargetFactory {
public <Z> ViewTarget<ImageView, Z> buildTarget(ImageView view,Class<Z> clazz) {
if (Drawable.class.isAssignableFrom(clazz)) {
return (ViewTarget<ImageView, Z>) new DrawableImageViewTarget(view);
}
}
}
所以这里最终创建的对象类型是 DrawableImageViewTarget，类似的还有 BitmapImageViewTarget。
回到前面的 into 方法继续往下看，
private <Y extends Target<TranscodeType>> Y into(Y target,RequestListener<TranscodeType> targetListener,BaseRequestOptions<?> options,Executor callbackExecutor) {
Request request = buildRequest(target, targetListener, options, callbackExecutor);
Request previous = target.getRequest();
if (request.isEquivalentTo(previous) && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {
//省略......
return target;
}
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);
return target;
}
看到这个方法我感觉被 Glide 所蒙蔽了。前面对比过 Glide 与 Picasso 的调用过程，以为 Glide 请求的创建于发起是分开的，但其实好像也是放在一起的。
方法的大致逻辑是 1. 利用入参创建请求对象 request。2. 校验相同 target 是否已有请求，有的话不会再发起。3. 发起请求。
总结一下，Glide 调用的最后一步 into 方法的主要工作依然是创建真正的加载请求并发起请求。这样来看 Glide 和 Picasso 相似度又增加了。前面的 with 和 load 方法其实都是为了请求而做的准备，特别是利用了 APT 来实现自定义选项的配置。
