写在之前
上一篇博文写的是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有个全面的理解。
好了，终于写完了，真的很不容易，很辛苦，希望大家也能从中学到知识。
各位如果还有哪里不明白的，或是我这里讲的还不够透彻，亦或是讲错了的地方请留言指正，让我们共同进步，谢谢
同时，请大家扫一扫关注我的微信公众号，虽然写的不是很勤，但是每一篇都有质量保证，让您学习到真正的知识。
