Glide的源码解析（一）（附方法调用图）

前言

上一篇博客讲了Glide的基本使用，知其然，也要知其所以然，这篇博客一起来学习Glide的源码。如果不知道Glide的基本使用，可以看上一篇博客：http://blog.csdn.net/luofen521/article/details/71210005

该博客也是基于郭霖大侠的Glide源码分析总结而得，算是自己做的笔记，郭大侠的博客传送门：http://blog.csdn.net/guolin_blog/article/details/53939176

问题

在没阅读Glide源码之前，我们带着下面几个问题去阅读源码，希望在阅读源码的过程中可以解决：

1. Glide图片是用什么来下载的？HttpClient还是HttpURLConnection?亦或OKHttp?
2. Glide图片是通过怎么解码的？是我们通常使用的BitmapFactory.decodeXXX方法么？
3. Glide下载好图片以后，是怎么加载到ImageView上的？
4. Glide怎么实现缓存的？是LruCache和DiskLruCache么？
5. Glide的线程是怎么管理的？几个核心线程？几个最大线程？有最大任务数的限制么？
6. Glide是怎么支持Gif图的？是通过Movie对象么？

源码版本

不同版本的Glide源码有些出入，该博客基于Glide3.7.0版本，来分析Glide如何在主线程中加载一张网络图片的，由于篇幅问题，该博客不考虑线程、缓存等流程。

源码解析

如何阅读源码：抽丝剥茧、点到即止。
Glide的流程过于复杂，其中的接口很多，为了方便阅读，强烈推荐下载方法调用流程图来对照着源码看，Pdf高清无码链接：http://download.csdn.net/detail/luofen521/9834616

从上一篇博客可知，Glide加载图片的流程就是先with，再load，最后into

Glide.with(context).load(imageUrl).into(imageView);

那我们顺着这条主线往下走

1. Glide.with()

public static RequestManager with(Context context) {    RequestManagerRetriever retriever = RequestManagerRetriever.get();    return retriever.get(context);}public static RequestManager with(Activity activity) {    RequestManagerRetriever retriever = RequestManagerRetriever.get();    return retriever.get(activity);}public static RequestManager with(FragmentActivity activity) {    RequestManagerRetriever retriever = RequestManagerRetriever.get();    return retriever.get(activity);}@TargetApi(Build.VERSION_CODES.HONEYCOMB)public static RequestManager with(android.app.Fragment fragment) {    RequestManagerRetriever retriever = RequestManagerRetriever.get();    return retriever.get(fragment);}public static RequestManager with(Fragment fragment) {    RequestManagerRetriever retriever = RequestManagerRetriever.get();    return retriever.get(fragment);}

该方法首先调用了 RequestManagerRetriever的get无参方法，并返回一个 RequestManagerRetriever实例，该实例是单例的，代码如下：

private static final RequestManagerRetriever INSTANCE = new RequestManagerRetriever();public static RequestManagerRetriever get() {    return INSTANCE;}

然后调用其get的有参对象，得到RequestManager对象，并返回。下面看看RequestManagerRetriever的get方法：

public RequestManager get(Context context) {    if (context == null) {        throw new IllegalArgumentException("You cannot start a load on a null Context");    } else if (Util.isOnMainThread() && !(context instanceof Application)) {        if (context instanceof FragmentActivity) {            return get((FragmentActivity) context);        } else if (context instanceof Activity) {            return get((Activity) context);        } else if (context instanceof ContextWrapper) {            return get(((ContextWrapper) context).getBaseContext());        }    }    return getApplicationManager(context);}private RequestManager getApplicationManager(Context context) {    if (applicationManager == null) {        synchronized (this) {            if (applicationManager == null) {                applicationManager = new RequestManager(context.getApplicationContext(),                        new ApplicationLifecycle(), new EmptyRequestManagerTreeNode());            }        }    }    return applicationManager;}public RequestManager get(FragmentActivity activity) {    if (Util.isOnBackgroundThread()) {        return get(activity.getApplicationContext());    } else {        assertNotDestroyed(activity);        FragmentManager fm = activity.getSupportFragmentManager();        return supportFragmentGet(activity, fm);    }}public RequestManager get(Fragment fragment) {    if (fragment.getActivity() == null) {        throw new IllegalArgumentException("You cannot start a load on a fragment before it is attached");    }    if (Util.isOnBackgroundThread()) {        return get(fragment.getActivity().getApplicationContext());    } else {        FragmentManager fm = fragment.getChildFragmentManager();        return supportFragmentGet(fragment.getActivity(), fm);    }}@TargetApi(Build.VERSION_CODES.HONEYCOMB)public RequestManager get(Activity activity) {    if (Util.isOnBackgroundThread() || Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {        return get(activity.getApplicationContext());    } else {        assertNotDestroyed(activity);        android.app.FragmentManager fm = activity.getFragmentManager();        return fragmentGet(activity, fm);    }}@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)public RequestManager get(android.app.Fragment fragment) {    if (fragment.getActivity() == null) {        throw new IllegalArgumentException("You cannot start a load on a fragment before it is attached");    }    if (Util.isOnBackgroundThread() || Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {        return get(fragment.getActivity().getApplicationContext());    } else {        android.app.FragmentManager fm = fragment.getChildFragmentManager();        return fragmentGet(fragment.getActivity(), fm);    }}@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)RequestManagerFragment getRequestManagerFragment(final android.app.FragmentManager fm) {    RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);    if (current == null) {        current = pendingRequestManagerFragments.get(fm);        if (current == null) {            current = new RequestManagerFragment();            pendingRequestManagerFragments.put(fm, current);            fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();            handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();        }    }    return current;}@TargetApi(Build.VERSION_CODES.HONEYCOMB)RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {    RequestManagerFragment current = getRequestManagerFragment(fm);    RequestManager requestManager = current.getRequestManager();    if (requestManager == null) {        requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());        current.setRequestManager(requestManager);    }    return requestManager;}SupportRequestManagerFragment getSupportRequestManagerFragment(final FragmentManager fm) {    SupportRequestManagerFragment current = (SupportRequestManagerFragment) fm.findFragmentByTag(        FRAGMENT_TAG);    if (current == null) {        current = pendingSupportRequestManagerFragments.get(fm);        if (current == null) {            current = new SupportRequestManagerFragment();            pendingSupportRequestManagerFragments.put(fm, current);            fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();            handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER, fm).sendToTarget();        }    }    return current;}RequestManager supportFragmentGet(Context context, FragmentManager fm) {    SupportRequestManagerFragment current = getSupportRequestManagerFragment(fm);    RequestManager requestManager = current.getRequestManager();    if (requestManager == null) {        requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());        current.setRequestManager(requestManager);    }    return requestManager;}

with方法可以分为两类，一类是参数为Application，一类是参数为非Appliction

参数为Application时，调用的是with(Context context)方法，可知，在其方法里直接调getApplicationManager(context)方法，可以看到，在getApplicationManager方法中，就是直接创建了一个RequestManager并返回，在构建RequestManager对象时，传入了ApplicationLifecycle对象，也就是说，当with方法传入的是Application时，Glide加载图片的生命周期和应用的生命周期一致，当退出应用时，图片停止加载。

参数为非Application时，调用的是with(Activity/Fragment)方法，在其方法里调用了fragmentGet/supportFragmentGet方法，而fragmentGet/supportFragmentGet方法中会先去调用getRequestManagerFragment／getSupportRequestManagerFragment方法去创建RequestManagerFragment／SupportRequestManagerFragment，并添加到Activity/Fragment上去，然后去创建一个RequestManager，在构建RequestManager时，会传入current.getLifeCycle，其实就是ActivityFragmentLifeCycle对象。也就是说，当with方法传入的是Activity或者Fragment时，会创建一个隐藏的Fragment加载到Activity／Fragment上，用于保证Glide加载图片的生命周期和Actiivty／Fragment一致，当退出Activity/Fragment时，图片停止加载。

这时候Glide.with()方法就完成了，它的主要作用是根据with的参数类型，创建一个RequestManager对象，在RequestManager的构造方法中，会调用Glide.get方法，在这个方法里会初始化线程池、缓存、Engin对象和Glide对象，等下篇讲线程池博客时再详细展开。这里要记住的就是RequestManager对象持有了不同的LifeCycle对象， 用于控制Glide加载图片的生命周期。

2.load()

由于Glide.with返回的是RequestManager，则需要到RequestManager类中查看load源码

public DrawableTypeRequest<String> load(String string) {     return (DrawableTypeRequest<String>) fromString().load(string);}

load方法直接调用了fromString方法，然后用返回值调用了load方法，下面看看fromString方法

public DrawableTypeRequest<String> fromString() {    return loadGeneric(String.class);}

而fromString方法直接调用了loadGeneric 方法并返回，下面看看loadGeneric方法

private <T> DrawableTypeRequest<T> loadGeneric(Class<T> modelClass) {    ModelLoader<T, InputStream> streamModelLoader = Glide.buildStreamModelLoader(modelClass, context);    ModelLoader<T, ParcelFileDescriptor> fileDescriptorModelLoader =            Glide.buildFileDescriptorModelLoader(modelClass, context);    return optionsApplier.apply(            new DrawableTypeRequest<T>(modelClass, streamModelLoader, fileDescriptorModelLoader, context,                    glide, requestTracker, lifecycle, optionsApplier));}

这里调用了Glide.buildStreamModelLoader和Glide.buildFileDescriptorModelLoader去创建了两个ModelLoader，用于后续的图片加载，其中Glide.buildStreamModelLoader返回的是StreamStringLoader，至于为什么返回StreamStringLoader，可以从Glide的构造方法中找到原因。然后直接构建出了一个DrawableTypeRequest，这里用到了之前返回的StreamStringLoader，最后调用了OptionsApplier.apply方法，返回了一个DrawableTypeRequest对象。

这里需要注意的是构建出DrawableTypeRequest的步骤，其中初始化了很多后续步骤需要使用到的数据。

DrawableTypeRequest(Class<ModelType> modelClass, ModelLoader<ModelType, InputStream> streamModelLoader,        ModelLoader<ModelType, ParcelFileDescriptor> fileDescriptorModelLoader, Context context, Glide glide,        RequestTracker requestTracker, Lifecycle lifecycle, RequestManager.OptionsApplier optionsApplier) {    super(context, modelClass,            buildProvider(glide, streamModelLoader, fileDescriptorModelLoader, GifBitmapWrapper.class,                    GlideDrawable.class, null),            glide, requestTracker, lifecycle);    this.streamModelLoader = streamModelLoader;    this.fileDescriptorModelLoader = fileDescriptorModelLoader;    this.optionsApplier = optionsApplier;}

在DrawableTypeRequest的构造方法里，调用了buildProvider方法，并把返回值传入到了DrawableTypeRequest的父类构造方法当中。先看看buildProvider方法：

private static <A, Z, R> FixedLoadProvider<A, ImageVideoWrapper, Z, R> buildProvider(Glide glide,        ModelLoader<A, InputStream> streamModelLoader,        ModelLoader<A, ParcelFileDescriptor> fileDescriptorModelLoader, Class<Z> resourceClass,        Class<R> transcodedClass,        ResourceTranscoder<Z, R> transcoder) {    if (streamModelLoader == null && fileDescriptorModelLoader == null) {        return null;    }    if (transcoder == null) {        transcoder = glide.buildTranscoder(resourceClass, transcodedClass);    }    DataLoadProvider<ImageVideoWrapper, Z> dataLoadProvider = glide.buildDataProvider(ImageVideoWrapper.class,            resourceClass);    ImageVideoModelLoader<A> modelLoader = new ImageVideoModelLoader<A>(streamModelLoader,            fileDescriptorModelLoader);    return new FixedLoadProvider<A, ImageVideoWrapper, Z, R>(modelLoader, transcoder, dataLoadProvider);}

这里需要注意的是glide.buildTranscoder方法，它返回了一个GifBitmapWrapperDrawableTranscoder对象，用于后续图片格式的转换；通过glide.buildDataProvider得到一个DataLoadProvider对象；通过StreamStringLoader包装出来一个ImageVideoModelLoader对象，最后创建一个FixedLoadProvider对象，并把之前创建的三个对象传入构造方法中，最后把FixedLoadProvider对象返回。

回到loadGeneric方法中可知，返回的是一个DrawableTypeRequest对象，即fromString方法返回的是DrawableTypeRequest对象，在之前RequestManager中的load方法调用formString().load()，则是调用DrawableTypeRequest中的load方法，但是发现DrawableTypeRequest中并没有load方法，原来是在其父类DrawableRequestBuilder中，下面看看DrawableRequestBuilder中的load方法。

@Overridepublic DrawableRequestBuilder<ModelType> load(ModelType model) {    super.load(model);    return this;}

这里没有多余的逻辑，只是调用了父类中的load方法，并返回了this,最后看看其父类GenericRequestBuilder中的load方法

public GenericRequestBuilder<ModelType, DataType, ResourceType, TranscodeType> load(ModelType model) {    this.model = model;    isModelSet = true;    return this;}

到这里，RequestManager中的load方法就结束了，可知，最后返回的是一个DrawRequestBuilder对象。

3. into()

因为RequestManager类中的load方法返回了DrawableRequestBuilder对象，则到DrawableRequestBuilder中看into方法，代码如下：

public Target<GlideDrawable> into(ImageView view) {    return super.into(view);}

没有什么逻辑，直接调用父类的into方法，那我们看下其父GenericRequestBuilder的into方法，代码如下：

public Target<TranscodeType> into(ImageView view) {    Util.assertMainThread();    if (view == null) {        throw new IllegalArgumentException("You must pass in a non null View");    }    if (!isTransformationSet && view.getScaleType() != null) {        switch (view.getScaleType()) {            case CENTER_CROP:                applyCenterCrop();                break;            case FIT_CENTER:            case FIT_START:            case FIT_END:                applyFitCenter();                break;            //$CASES-OMITTED$            default:                // Do nothing.        }    }    return into(glide.buildImageViewTarget(view, transcodeClass));}

先看第一行，这里调用了Util.assertMainThread方法，用于判断当前线程是否是主线程，我们看看其中的逻辑：

public static void assertMainThread() {    if (!isOnMainThread()) {        throw new IllegalArgumentException("You must call this method on the main thread");    }}

如果不是主线程，就直接抛出异常。也就是说，使用Glide加载图片，必须要在主线程。

然后可以直接看into方法的最后一行，调用了into的重载方法，不过它的参数是通过Glide的buildImageViewTarget方法来构建出来的，我们先看看这个方法的逻辑，代码如下：

<R> Target<R> buildImageViewTarget(ImageView imageView, Class<R> transcodedClass) {    return imageViewTargetFactory.buildTarget(imageView, transcodedClass);}

其实就是调用了一个ImageViewTargetFactory的buildTarget方法，并把返回值返回，从名字可以看出，该类是一个构建ImageViewTarget对象的工厂类，代码如下：

public <Z> Target<Z> buildTarget(ImageView view, Class<Z> clazz) {    if (GlideDrawable.class.isAssignableFrom(clazz)) {        return (Target<Z>) new GlideDrawableImageViewTarget(view);    } else if (Bitmap.class.equals(clazz)) {        return (Target<Z>) new BitmapImageViewTarget(view);    } else if (Drawable.class.isAssignableFrom(clazz)) {        return (Target<Z>) new DrawableImageViewTarget(view);    } else {        throw new IllegalArgumentException("Unhandled class: " + clazz                + ", try .as*(Class).transcode(ResourceTranscoder)");    }}

一般来说，就是返回GlideDrawableImageViewTarget对象，如果在into方法之前，调用了asBitmap方法，则是返回BitmapImageViewTarget对象。
再回到GenericRequestBuilder类中的into方法，glide.buildImageViewTarget方法返回了一个GlideDrawableImageViewTarget对象，接下来看GenericRequestBuilder类中into(Target)这个重载方法

public <Y extends Target<TranscodeType>> Y into(Y target) {    Util.assertMainThread();    if (target == null) {        throw new IllegalArgumentException("You must pass in a non null Target");    }    if (!isModelSet) {        throw new IllegalArgumentException("You must first set a model (try #load())");    }    Request previous = target.getRequest();    if (previous != null) {        previous.clear();        requestTracker.removeRequest(previous);        previous.recycle();    }    Request request = buildRequest(target);    target.setRequest(request);    lifecycle.addListener(target);    requestTracker.runRequest(request);    return target;}

在这个方法里，调用了buildRequest来得到Request对象，先看下buildRequest的代码，如下：

private Request buildRequest(Target<TranscodeType> target) {    if (priority == null) {        priority = Priority.NORMAL;    }    return buildRequestRecursive(target, null);}private Request buildRequestRecursive(Target<TranscodeType> target, ThumbnailRequestCoordinator parentCoordinator) {    if (thumbnailRequestBuilder != null) {        if (isThumbnailBuilt) {            throw new IllegalStateException("You cannot use a request as both the main request and a thumbnail, "                    + "consider using clone() on the request(s) passed to thumbnail()");        }        // Recursive case: contains a potentially recursive thumbnail request builder.        if (thumbnailRequestBuilder.animationFactory.equals(NoAnimation.getFactory())) {            thumbnailRequestBuilder.animationFactory = animationFactory;        }        if (thumbnailRequestBuilder.priority == null) {            thumbnailRequestBuilder.priority = getThumbnailPriority();        }        if (Util.isValidDimensions(overrideWidth, overrideHeight)                && !Util.isValidDimensions(thumbnailRequestBuilder.overrideWidth,                        thumbnailRequestBuilder.overrideHeight)) {          thumbnailRequestBuilder.override(overrideWidth, overrideHeight);        }        ThumbnailRequestCoordinator coordinator = new ThumbnailRequestCoordinator(parentCoordinator);        Request fullRequest = obtainRequest(target, sizeMultiplier, priority, coordinator);        // Guard against infinite recursion.        isThumbnailBuilt = true;        // Recursively generate thumbnail requests.        Request thumbRequest = thumbnailRequestBuilder.buildRequestRecursive(target, coordinator);        isThumbnailBuilt = false;        coordinator.setRequests(fullRequest, thumbRequest);        return coordinator;    } else if (thumbSizeMultiplier != null) {        // Base case: thumbnail multiplier generates a thumbnail request, but cannot recurse.        ThumbnailRequestCoordinator coordinator = new ThumbnailRequestCoordinator(parentCoordinator);        Request fullRequest = obtainRequest(target, sizeMultiplier, priority, coordinator);        Request thumbnailRequest = obtainRequest(target, thumbSizeMultiplier, getThumbnailPriority(), coordinator);        coordinator.setRequests(fullRequest, thumbnailRequest);        return coordinator;    } else {        // Base case: no thumbnail.        return obtainRequest(target, sizeMultiplier, priority, parentCoordinator);    }}private Request obtainRequest(Target<TranscodeType> target, float sizeMultiplier, Priority priority,        RequestCoordinator requestCoordinator) {    return GenericRequest.obtain(            loadProvider,            model,            signature,            context,            priority,            target,            sizeMultiplier,            placeholderDrawable,            placeholderId,            errorPlaceholder,            errorId,            fallbackDrawable,            fallbackResource,            requestListener,            requestCoordinator,            glide.getEngine(),            transformation,            transcodeClass,            isCacheable,            animationFactory,            overrideWidth,            overrideHeight,            diskCacheStrategy);}

这里逻辑很简单，buildRequest中调用了buildRequestRecursive，而buildRequestRecursive调用了obtainRequest方法，在obtainRequest方法里，直接调用了GenericRequest.obtain方法，并返回，接下来，看一下GenericRequest的obtaion方法，如下：

public static <A, T, Z, R> GenericRequest<A, T, Z, R> obtain(        LoadProvider<A, T, Z, R> loadProvider,        A model,        Key signature,        Context context,        Priority priority,        Target<R> target,        float sizeMultiplier,        Drawable placeholderDrawable,        int placeholderResourceId,        Drawable errorDrawable,        int errorResourceId,        Drawable fallbackDrawable,        int fallbackResourceId,        RequestListener<? super A, R> requestListener,        RequestCoordinator requestCoordinator,        Engine engine,        Transformation<Z> transformation,        Class<R> transcodeClass,        boolean isMemoryCacheable,        GlideAnimationFactory<R> animationFactory,        int overrideWidth,        int overrideHeight,        DiskCacheStrategy diskCacheStrategy) {    @SuppressWarnings("unchecked")    GenericRequest<A, T, Z, R> request = (GenericRequest<A, T, Z, R>) REQUEST_POOL.poll();    if (request == null) {        request = new GenericRequest<A, T, Z, R>();    }    request.init(loadProvider,            model,            signature,            context,            priority,            target,            sizeMultiplier,            placeholderDrawable,            placeholderResourceId,            errorDrawable,            errorResourceId,            fallbackDrawable,            fallbackResourceId,            requestListener,            requestCoordinator,            engine,            transformation,            transcodeClass,            isMemoryCacheable,            animationFactory,            overrideWidth,            overrideHeight,            diskCacheStrategy);    return request;}

Glide中的Request是通过Queue来管理的，先从队列里出队一个GenericRequest对象，它实现了Request接口，如果为空就创建一个，然后完成初始化，并返回。
然后返回到GenericRequestBuilder中的into(Target)方法，buildRequest返回了一个GenericRequest对象，然后调用了RequestTracker.runRequest(Request)方法，我们来看看这个方法

public void runRequest(Request request) {    requests.add(request);    if (!isPaused) {        request.begin();    } else {        pendingRequests.add(request);    }}

这里调用了request对象的begin方法，request就是之前buildRequest方法返回的GenericRequest对象，接下来，看GenericRequest中的begin方法:

public void begin() {    startTime = LogTime.getLogTime();    if (model == null) {        onException(null);        return;    }    status = Status.WAITING_FOR_SIZE;    if (Util.isValidDimensions(overrideWidth, overrideHeight)) {        onSizeReady(overrideWidth, overrideHeight);    } else {        target.getSize(this);    }    if (!isComplete() && !isFailed() && canNotifyStatusChanged()) {        target.onLoadStarted(getPlaceholderDrawable());    }    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logV("finished run method in " + LogTime.getElapsedMillis(startTime));    }}

这里先判断了model是否为null，model其实就是加载的资源，这里就是url，如果url无效，则调用了onException方法，接下来看onException方法；

public void onException(Exception e) {    if (Log.isLoggable(TAG, Log.DEBUG)) {        Log.d(TAG, "load failed", e);    }    status = Status.FAILED;    //TODO: what if this is a thumbnail request?    if (requestListener == null || !requestListener.onException(e, model, target, isFirstReadyResource())) {        setErrorPlaceholder(e);    }}private void setErrorPlaceholder(Exception e) {    if (!canNotifyStatusChanged()) {        return;    }    Drawable error = model == null ? getFallbackDrawable() : null;    if (error == null) {      error = getErrorDrawable();    }    if (error == null) {        error = getPlaceholderDrawable();    }    target.onLoadFailed(e, error);}

在onException中直接调用了setErrorPlaceholder方法，而setErrorPlaceholder方法中调用了target的onLoadFailed方法，target就是之前创建的GlideDrawableImageViewTarget对象，接下来看它里面的onLoadFailed方法，发现没有这个方法，但是在父类ImageViewTarge中发现了onLoadFailed方法，如下：

public void onLoadFailed(Exception e, Drawable errorDrawable) {    view.setImageDrawable(errorDrawable);}

代码很简单，直接给ImageView设置加载图片失败时的占位图，这就完成了当图片链接无效时，显示图片加载失败占位符的逻辑。GenericRequest中的begin方法中的target.onLoadStarted方法，显示图片加载成功之前的占位符，也是同样的逻辑。

回到GenericRequest中的begin方法中，如果url有效，且在into之前没有调用override()方法指定宽高，则会调用target的getSize参数，并把当前对象，就是GenericRequest对象作为参数传递过去了，这个target就是之前glide.buildImageViewTarget得到的GlideDrawableImageViewTarget对象，那我们看看GlideDrawableImageViewTarget类中是否有getSize方法，发现没有，则从其父类ImageViewTarget中寻找getSize方法，发现也没有，只有从ImageViewTarget的父类ViewTarget中寻找getSize方法，果不其然，getSize方法就是在ViewTarget中，方法如下：

public void getSize(SizeReadyCallback cb) {    sizeDeterminer.getSize(cb);}

这里直接调用了sizeDeterminer的getSize方法，SizeDeterminer其实就是ViewTarget的一个内部类，我们来看看SizeDeterminer中的getSize方法，代码如下：

public void getSize(SizeReadyCallback cb) {    int currentWidth = getViewWidthOrParam();    int currentHeight = getViewHeightOrParam();    if (isSizeValid(currentWidth) && isSizeValid(currentHeight)) {        cb.onSizeReady(currentWidth, currentHeight);    } else {        if (!cbs.contains(cb)) {            cbs.add(cb);        }        if (layoutListener == null) {            final ViewTreeObserver observer = view.getViewTreeObserver();            layoutListener = new SizeDeterminerLayoutListener(this);            observer.addOnPreDrawListener(layoutListener);        }    }}

这里直接调用了cb的onSizeReady方法，cb是SizeReadyCallback对象，那是从哪里传过来的呢？还记得tagert.getSize(this)这句代码吗？其实就是这个this，也就是GenericRequest对象，来看看GenericRequest的定义：

public final class GenericRequest<A, T, Z, R> implements Request, SizeReadyCallback, ResourceCallback {

所以调用的就是GenericRequest的onSizeReady方法，接下来我们看看这个方法：

public void onSizeReady(int width, int height) {    if (status != Status.WAITING_FOR_SIZE) {        return;    }    status = Status.RUNNING;    width = Math.round(sizeMultiplier * width);    height = Math.round(sizeMultiplier * height);    ModelLoader<A, T> modelLoader = loadProvider.getModelLoader();    final DataFetcher<T> dataFetcher = modelLoader.getResourceFetcher(model, width, height);    if (dataFetcher == null) {        onException(new Exception("Failed to load model: \'" + model + "\'"));        return;    }    ResourceTranscoder<Z, R> transcoder = loadProvider.getTranscoder();    loadedFromMemoryCache = true;    loadStatus = engine.load(signature, width, height, dataFetcher, loadProvider, transformation, transcoder,            priority, isMemoryCacheable, diskCacheStrategy, this);    loadedFromMemoryCache = resource != null;    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime));    }}

这里代码比较复杂，先看第8行代码，这里调用的是loadProvider的getModelLoader方法，那loadProvider是个什么对象呢？它其实就是在load方法中创建的FixLoadProvider对象，则这里调用的getModelLoader方法得到的就是load方法时，创建的ImageVideoModelLoader对象。
然后看第9行代码，则是调用的ImageVideoModelLoader类中的getResourceFetcher方法，代码如下：

@Overridepublic DataFetcher<ImageVideoWrapper> getResourceFetcher(A model, int width, int height) {    DataFetcher<InputStream> streamFetcher = null;    if (streamLoader != null) {        streamFetcher = streamLoader.getResourceFetcher(model, width, height);    }    DataFetcher<ParcelFileDescriptor> fileDescriptorFetcher = null;    if (fileDescriptorLoader != null) {        fileDescriptorFetcher = fileDescriptorLoader.getResourceFetcher(model, width, height);    }    if (streamFetcher != null || fileDescriptorFetcher != null) {        return new ImageVideoFetcher(streamFetcher, fileDescriptorFetcher);    } else {        return null;    }}

直接调用了streamLoader的getResourceFetcher方法，这里的streamLoader是load方法中创建的StreamStringLoader对象，这里返回的是一个HttpUrlFetcher对象，然后把HttpUrlFetcher作为参数构造出ImageVideoFetcher对象，并返回

onSizeReady方法中的第14行代码，通过loadProvider调用getTranscoder()方法，得到的是load方法中创建的GifBitmapWrapperDrawableTranscoder对象

onSizeReady方法中第16代码，调用了engine.load方法，其中参数有前面得到的ImageVideoFetcher对象、GifBitmapWrapperDrawableTranscoder对象、FixedLoadProvider对象和this(GenericRequest对象)。engine是一个Engine对象，下面我们来看看Engine中的load方法：

public <T, Z, R> LoadStatus load(Key signature, int width, int height, DataFetcher<T> fetcher,        DataLoadProvider<T, Z> loadProvider, Transformation<Z> transformation, ResourceTranscoder<Z, R> transcoder,        Priority priority, boolean isMemoryCacheable, DiskCacheStrategy diskCacheStrategy, ResourceCallback cb) {    Util.assertMainThread();    long startTime = LogTime.getLogTime();    final String id = fetcher.getId();    EngineKey key = keyFactory.buildKey(id, signature, width, height, loadProvider.getCacheDecoder(),            loadProvider.getSourceDecoder(), transformation, loadProvider.getEncoder(),            transcoder, loadProvider.getSourceEncoder());    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);    if (cached != null) {        cb.onResourceReady(cached);        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);        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 engineJob = engineJobFactory.build(key, isMemoryCacheable);    DecodeJob<T, Z, R> decodeJob = new DecodeJob<T, Z, R>(key, width, height, fetcher, loadProvider, transformation,            transcoder, diskCacheProvider, diskCacheStrategy, priority);    EngineRunnable runnable = new EngineRunnable(engineJob, decodeJob, priority);    jobs.put(key, engineJob);    engineJob.addCallback(cb);    engineJob.start(runnable);    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logWithTimeAndKey("Started new load", startTime, key);    }    return new LoadStatus(cb, engineJob);}

第38行，调用了一个EngineJobFactory的build方法，创建了一个EngineJob对象
第39行，直接创建了一个DecodeJob对象
第41行，通过之前创建的EngineJob和DecodeJob构建出了一个EngineRunnable对象，EngineRunnale实现了Runnable接口
第43行，调用EngineJob的addCallback方法，把cb加入到EngineJob的回调集合中，那似曾相识的cb是什么对象呢？就是之前提到的GenericRequest，它实现了ResourceCallback接口
第44行，调用了EngineJob的start方法，并把EngineRunnable对象传入进去，可以看出，重头戏要来了。
接下来看EngineJob的start方法:

public void start(EngineRunnable engineRunnable) {    this.engineRunnable = engineRunnable;    future = diskCacheService.submit(engineRunnable);}

diskCacheService是一个Executorservice对象，这里直接调用了它的submit方法去执行EngineRunnable，接下来，看看EngineRunnable的run方法，注意这个方法已经是在子线程中运行了

@Overridepublic void run() {    if (isCancelled) {        return;    }    Exception exception = null;    Resource<?> resource = null;    try {        resource = decode();    } catch (Exception e) {        exception = e;    }    if (isCancelled) {        if (resource != null) {            resource.recycle();        }        return;    }    if (resource == null) {        onLoadFailed(exception);    } else {        onLoadComplete(resource);    }}

第10行，这里是调用了decode方法，最后返回了一个Resource的对象
第23行，这是当前面decode方法的返回值为null时，调用了onLoadFiled方法，和之前url无效，展示加载图片失败时的占位符
第25行，这是当decode方法的返回值不为null时，调用了onLoadComplete方法，顾名思义，就是对图片加载成功后对处理逻辑
显而易见，run方法中的逻辑就是调用decode方法得到图片资源，然后根据是否成功地得到图片资源，分别调用onLoadFailed方法和onLoadComplete方法对图片加载结果进行响应处理。
下面先来看本类中的decode方法：

private Resource<?> decode() throws Exception {    if (isDecodingFromCache()) {        return decodeFromCache();    } else {        return decodeFromSource();    }}

这里先不管缓存逻辑，则调用decodeFromSource方法，并返回，下面看看decodeFromSource方法

private Resource<?> decodeFromSource() throws Exception {    return decodeJob.decodeFromSource();}

直接调用了decodeJob的decodeFromSource方法，decodeJob就是在Engine的load方法中创建的DecodeJob，下面看看DecodeJob中的decodeFromSource

public Resource<Z> decodeFromSource() throws Exception {    Resource<T> decoded = decodeSource();    return transformEncodeAndTranscode(decoded);}

第2行，调用了decodeSource方法，去得到图片资源，返回了一个Resource对象，这个跟返回值Resource是不是有什么千丝万缕的联系呢？这就要说到第3行的transfromEncodeAndTranscode方法了，这个方法接受了一个Resource参数，然后返回了一个Resource参数，没错，这个方法就是用来转换的，就是把下载的图片资源类型转换成一个可供展示的图片资源类型。至于Z和T的具体类型，下面会讲到
先看decodeSource方法：

private Resource<T> decodeSource() throws Exception {    Resource<T> decoded = null;    try {        long startTime = LogTime.getLogTime();        final A data = fetcher.loadData(priority);        if (Log.isLoggable(TAG, Log.VERBOSE)) {            logWithTimeAndKey("Fetched data", startTime);        }        if (isCancelled) {            return null;        }        decoded = decodeFromSourceData(data);    } finally {        fetcher.cleanup();    }    return decoded;}

第5行，是用来真正进行下载图片逻辑，返回的是一个ImageVideoWrapper对象，这个对象里包装了图片的InputStream
第12行，是用来解析前面返回的ImageVideoWrapper，返回值是一个GitfBitmapWrapperResource对象，里面包装了Bitmap
先来看第5行代码，调用了fetcher.loadData方法，那fetcher是什么东西呢？fetcher其实就是构建EngineJob传入的ImageVideoFetcher对象，我们先来看看ImageVideoFetcher中的loadData方法：

public ImageVideoWrapper loadData(Priority priority) throws Exception {    InputStream is = null;    if (streamFetcher != null) {        try {            is = streamFetcher.loadData(priority);        } catch (Exception e) {            if (fileDescriptorFetcher == null) {                throw e;            }        }    }    ParcelFileDescriptor fileDescriptor = null;    if (fileDescriptorFetcher != null) {        try {            fileDescriptor = fileDescriptorFetcher.loadData(priority);        } catch (Exception e) {            if (is == null) {                throw e;            }        }    }    return new ImageVideoWrapper(is, fileDescriptor);}

先看第5行代码，这里调用了streamFetcher的loadData方法，那streamFetcher是个什么东东呢？它就是在前面调用ImageVideoModelLoader的getResourceFetcher方法时，传入的HttpUrlFetcher，我们先看看HttpUrlFetcher的loadData方法，这里应该要下载图片了

public InputStream loadData(Priority priority) throws Exception {    return loadDataWithRedirects(glideUrl.toURL(), 0 /*redirects*/, null /*lastUrl*/, glideUrl.getHeaders());}

这里直接调用了loadDataWithRedirects方法并返回，下面看看该方法

private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl, Map<String, String> headers)        throws IOException {    if (redirects >= MAXIMUM_REDIRECTS) {        throw new IOException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");    } else {        try {            if (lastUrl != null && url.toURI().equals(lastUrl.toURI())) {                throw new IOException("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(2500);    urlConnection.setReadTimeout(2500);    urlConnection.setUseCaches(false);    urlConnection.setDoInput(true);    // 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 IOException("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 IOException("Unable to retrieve response code from HttpUrlConnection.");        }        throw new IOException("Request failed " + statusCode + ": " + urlConnection.getResponseMessage());    }}

第28行代码，调用了connectionFactory的build方法，用于构建网络通信的Connection，而connectonFactory是个HttpUrlConnectionFactory接口的对象，HttpUrlConnectionFactory的默认实现类为DefaultHttpUrlConnectionFactory，如下：

interface HttpUrlConnectionFactory {    HttpURLConnection build(URL url) throws IOException;}private static class DefaultHttpUrlConnectionFactory implements HttpUrlConnectionFactory {    @Override    public HttpURLConnection build(URL url) throws IOException {        return (HttpURLConnection) url.openConnection();    }}

这里直接返回了一个HttpURLConnection对象，原来Glide中下载图片是使用的HttpURLConnection
再回到loadDataWithRedirects方法的第20行代码，一般下载图片成功是返回200状态码，所以会调用getStreamForSuccessfulRequest方法，我们看看这个方法：

private InputStream getStreamForSuccessfulRequest(HttpURLConnection urlConnection)        throws IOException {    if (TextUtils.isEmpty(urlConnection.getContentEncoding())) {        int contentLength = urlConnection.getContentLength();        stream = ContentLengthInputStream.obtain(urlConnection.getInputStream(), contentLength);    } else {        stream = urlConnection.getInputStream();    }    return stream;}

可以看到，这个方法就是通过HttpURLConnection的getInputStream方法，得到InputStream并返回。
然后逐级返回，来到ImageVideoFetcher的loadData方法的最后一行代码，这里就是通过HttpURLConnection返回的InputStream对象，包装成一个ImageVideoWrapper对象，并返回
然后返回到DecodeJob的decodeStream方法，再调用了ImageVideoFetcher的loadData方法得到ImageVideoWrapper对象以后，调用了decodeFromSourceData方法，并把ImageVideoWrapper传入进去，进行图片解码，我们来看看decodeFromSourceData方法：

private Resource<T> decodeFromSourceData(A data) throws IOException {    final Resource<T> decoded;    if (diskCacheStrategy.cacheSource()) {        decoded = cacheAndDecodeSourceData(data);    } else {        long startTime = LogTime.getLogTime();        decoded = loadProvider.getSourceDecoder().decode(data, width, height);    }    return decoded;}

这里的主要逻辑是第7行代码，先调用了loadProvider的getSourceDecoder方法，loadProvider就是在Engine的load方法中构建DecodeJob时传进来的FixedLoadProvider对象，而它的getSourceDecoder方法如下：

public ResourceDecoder<T, Z> getSourceDecoder() {    return dataLoadProvider.getSourceDecoder();}

可以看到这里就是调用了dataLoadProvider的getSourceDecoder方法，而dataLoadProvider是在DrawableTypeRequest的buildProvider方法中构建FixLoadProvider时传入的ImageVideoGifDrawableLoadProvider对象，我们看看ImageVideoGifDrawableLoadProvider的getSourceEncoder方法：

@Overridepublic Encoder<ImageVideoWrapper> getSourceEncoder() {    return sourceEncoder;}public ImageVideoGifDrawableLoadProvider(DataLoadProvider<ImageVideoWrapper, Bitmap> bitmapProvider,        DataLoadProvider<InputStream, GifDrawable> gifProvider, BitmapPool bitmapPool) {    final GifBitmapWrapperResourceDecoder decoder = new GifBitmapWrapperResourceDecoder(            bitmapProvider.getSourceDecoder(),            gifProvider.getSourceDecoder(),            bitmapPool    );    cacheDecoder = new FileToStreamDecoder<GifBitmapWrapper>(new GifBitmapWrapperStreamResourceDecoder(decoder));    sourceDecoder = decoder;    encoder = new GifBitmapWrapperResourceEncoder(bitmapProvider.getEncoder(), gifProvider.getEncoder());    //TODO: what about the gif provider?    sourceEncoder = bitmapProvider.getSourceEncoder();}

可知，得到的是一个GifBitmapWrapperResourceDecoder对象，所以decodeFromSourceData方法中loadProvider.getSourceDecoder().decode()其实就是调用GifBitmapWrapperResourceDecoder类中的decode方法，如下：

public Resource<GifBitmapWrapper> decode(ImageVideoWrapper source, int width, int height) throws IOException {    ByteArrayPool pool = ByteArrayPool.get();    byte[] tempBytes = pool.getBytes();    GifBitmapWrapper wrapper = null;    try {        wrapper = decode(source, width, height, tempBytes);    } finally {        pool.releaseBytes(tempBytes);    }    return wrapper != null ? new GifBitmapWrapperResource(wrapper) : null;}

第6行代码，直接调用了decode的重载方法，得到解析出来的图片资源，然后在最后一行代码包装成GifBitmapWrapperResource对象，并返回。
我们先看decode的重载方法：

private GifBitmapWrapper decode(ImageVideoWrapper source, int width, int height, byte[] bytes) throws IOException {    final GifBitmapWrapper result;    if (source.getStream() != null) {        result = decodeStream(source, width, height, bytes);    } else {        result = decodeBitmapWrapper(source, width, height);    }    return result;}

这里的source.getStream其实就是之前用HttpURLConnection得到的图片InputStream，所以不为空，则调用decodeStream对输入流进行解码，再看decodeStream的源码：

private GifBitmapWrapper decodeStream(ImageVideoWrapper source, int width, int height, byte[] bytes)        throws IOException {    InputStream bis = streamFactory.build(source.getStream(), bytes);    bis.mark(MARK_LIMIT_BYTES);    ImageHeaderParser.ImageType type = parser.parse(bis);    bis.reset();    GifBitmapWrapper result = null;    if (type == ImageHeaderParser.ImageType.GIF) {        result = decodeGifWrapper(bis, width, height);    }    // Decoding the gif may fail even if the type matches.    if (result == null) {        // We can only reset the buffered InputStream, so to start from the beginning of the stream, we need to        // pass in a new source containing the buffered stream rather than the original stream.        ImageVideoWrapper forBitmapDecoder = new ImageVideoWrapper(bis, source.getFileDescriptor());        result = decodeBitmapWrapper(forBitmapDecoder, width, height);    }    return result;}

这里先对流进行了解析，判断图片格式是否是Gif格式，如果是，则执行第10行代码，解析Gif图片；如果不是，则执行第17行代码，解析静态图片。我们这里是静态图片，所以会调用decodeBitmapWrapper方法，我们看看源码：

private GifBitmapWrapper decodeBitmapWrapper(ImageVideoWrapper toDecode, int width, int height) throws IOException {    GifBitmapWrapper result = null;    Resource<Bitmap> bitmapResource = bitmapDecoder.decode(toDecode, width, height);    if (bitmapResource != null) {        result = new GifBitmapWrapper(bitmapResource, null);    }    return result;}

这里调用bitmapDecoder的decode方法，那bitmapDecoder方法是个什么对象呢？这个就说来话长了还记得，GifBitmapWrapperResourceDecoder中有这么一段代码：

public ImageVideoGifDrawableLoadProvider(DataLoadProvider<ImageVideoWrapper, Bitmap> bitmapProvider,        DataLoadProvider<InputStream, GifDrawable> gifProvider, BitmapPool bitmapPool) {    final GifBitmapWrapperResourceDecoder decoder = new GifBitmapWrapperResourceDecoder(            bitmapProvider.getSourceDecoder(),            gifProvider.getSourceDecoder(),            bitmapPool    );    cacheDecoder = new FileToStreamDecoder<GifBitmapWrapper>(new GifBitmapWrapperStreamResourceDecoder(decoder));    sourceDecoder = decoder;    encoder = new GifBitmapWrapperResourceEncoder(bitmapProvider.getEncoder(), gifProvider.getEncoder());    //TODO: what about the gif provider?    sourceEncoder = bitmapProvider.getSourceEncoder();}

其实bitmapDecoder就是上处第5行代码bitmapProvider.getSourceDecoder的返回值，而bitmapProvider又是什么呢？这就要看到找到创建ImageVideoGifDrawableLoadProvid的地方了，这个代码在Glide的构造方法里

Glide(Engine engine, MemoryCache memoryCache, BitmapPool bitmapPool, Context context, DecodeFormat decodeFormat) {    dataLoadProviderRegistry.register(ImageVideoWrapper.class, GifBitmapWrapper.class,            new ImageVideoGifDrawableLoadProvider(imageVideoDataLoadProvider, gifDrawableLoadProvider, bitmapPool));}

所以bitmapProvider就是一个ImageVideoDataLoadProvider对象，所以bitmapDecoder就是ImageVideoDataLoadProvider的getSourceDecoder方法的返回值，我们看看该方法：

public ImageVideoDataLoadProvider(DataLoadProvider<InputStream, Bitmap> streamBitmapProvider,        DataLoadProvider<ParcelFileDescriptor, Bitmap> fileDescriptorBitmapProvider) {    encoder = streamBitmapProvider.getEncoder();    sourceEncoder = new ImageVideoWrapperEncoder(streamBitmapProvider.getSourceEncoder(),            fileDescriptorBitmapProvider.getSourceEncoder());    cacheDecoder = streamBitmapProvider.getCacheDecoder();    sourceDecoder = new ImageVideoBitmapDecoder(streamBitmapProvider.getSourceDecoder(),            fileDescriptorBitmapProvider.getSourceDecoder());}@Overridepublic ResourceDecoder<ImageVideoWrapper, Bitmap> getSourceDecoder() {    return sourceDecoder;}

可知，bitmapDecoder其实就是一个ImageVideoBitmapDecoder对象，回到GifBitmapWrapperResourceDecoder的decodeBitmapWrapper方法，继续主流程，那这时候就是调用的ImageVideoBitmapDecoder的decode方法，代码如下：

public Resource<Bitmap> decode(ImageVideoWrapper source, int width, int height) throws IOException {    Resource<Bitmap> result = null;    InputStream is = source.getStream();    if (is != null) {        try {            result = streamDecoder.decode(is, width, height);        } catch (IOException e) {        }    }    if (result == null) {        ParcelFileDescriptor fileDescriptor = source.getFileDescriptor();        if (fileDescriptor != null) {            result = fileDescriptorDecoder.decode(fileDescriptor, width, height);        }    }    return result;}

关键代码就是第6行代码，调用了streamDecoder的decode方法，那streamDecoder是个什么对象呢？其实和ImageVideoBitmapDecoder逻辑差不多，也是在Glide的构造方法里有这么一段：

Glide(Engine engine, MemoryCache memoryCache, BitmapPool bitmapPool, Context context, DecodeFormat decodeFormat) {    StreamBitmapDataLoadProvider streamBitmapLoadProvider =            new StreamBitmapDataLoadProvider(bitmapPool, decodeFormat); ImageVideoDataLoadProvider imageVideoDataLoadProvider =        new ImageVideoDataLoadProvider(streamBitmapLoadProvider, fileDescriptorLoadProvider);dataLoadProviderRegistry.register(ImageVideoWrapper.class, Bitmap.class, imageVideoDataLoadProvider);dataLoadProviderRegistry.register(ImageVideoWrapper.class, GifBitmapWrapper.class,        new ImageVideoGifDrawableLoadProvider(imageVideoDataLoadProvider, gifDrawableLoadProvider, bitmapPool));}

就是这样逐级封装，我们看看StreamBitmapDataLoadProvider的构造方法：

public StreamBitmapDataLoadProvider(BitmapPool bitmapPool, DecodeFormat decodeFormat) {    sourceEncoder = new StreamEncoder();    decoder = new StreamBitmapDecoder(bitmapPool, decodeFormat);    encoder = new BitmapEncoder();    cacheDecoder = new FileToStreamDecoder<Bitmap>(decoder);}

所以streamDecoder其实就是一个StreamBitmapDecoder对象，继续回到ImageVideoBitmapDecoder的decode方法中，继续主流程，相当于调用了StreamBitmapDecoder中的decode方法，代码如下：

@Overridepublic Resource<Bitmap> decode(InputStream source, int width, int height) {    Bitmap bitmap = downsampler.decode(source, bitmapPool, width, height, decodeFormat);    return BitmapResource.obtain(bitmap, bitmapPool);}

第3行代码，是调用DownSampler中的decode方法，从InputStream解析处Bitmap
第4行代码，是调用BitmapResource的obtain方法，把解析出的Bitmap封装成BitmapResource对象中，并返回
我们先看DownSampler中的decode方法：

public Bitmap decode(InputStream is, BitmapPool pool, int outWidth, int outHeight, DecodeFormat decodeFormat) {    final ByteArrayPool byteArrayPool = ByteArrayPool.get();    final byte[] bytesForOptions = byteArrayPool.getBytes();    final byte[] bytesForStream = byteArrayPool.getBytes();    final BitmapFactory.Options options = getDefaultOptions();    // Use to fix the mark limit to avoid allocating buffers that fit entire images.    RecyclableBufferedInputStream bufferedStream = new RecyclableBufferedInputStream(            is, bytesForStream);    // Use to retrieve exceptions thrown while reading.    // TODO(#126): when the framework no longer returns partially decoded Bitmaps or provides a way to determine    // if a Bitmap is partially decoded, consider removing.    ExceptionCatchingInputStream exceptionStream =            ExceptionCatchingInputStream.obtain(bufferedStream);    // Use to read data.    // Ensures that we can always reset after reading an image header so that we can still attempt to decode the    // full image even when the header decode fails and/or overflows our read buffer. See #283.    MarkEnforcingInputStream invalidatingStream = new MarkEnforcingInputStream(exceptionStream);    try {        exceptionStream.mark(MARK_POSITION);        int orientation = 0;        try {            orientation = new ImageHeaderParser(exceptionStream).getOrientation();        } catch (IOException e) {            if (Log.isLoggable(TAG, Log.WARN)) {                Log.w(TAG, "Cannot determine the image orientation from header", e);            }        } finally {            try {                exceptionStream.reset();            } catch (IOException e) {                if (Log.isLoggable(TAG, Log.WARN)) {                    Log.w(TAG, "Cannot reset the input stream", e);                }            }        }        options.inTempStorage = bytesForOptions;        final int[] inDimens = getDimensions(invalidatingStream, bufferedStream, options);        final int inWidth = inDimens[0];        final int inHeight = inDimens[1];        final int degreesToRotate = TransformationUtils.getExifOrientationDegrees(orientation);        final int sampleSize = getRoundedSampleSize(degreesToRotate, inWidth, inHeight, outWidth, outHeight);        final Bitmap downsampled =                downsampleWithSize(invalidatingStream, bufferedStream, options, pool, inWidth, inHeight, sampleSize,                        decodeFormat);        final Exception streamException = exceptionStream.getException();        if (streamException != null) {            throw new RuntimeException(streamException);        }        Bitmap rotated = null;        if (downsampled != null) {            rotated = TransformationUtils.rotateImageExif(downsampled, pool, orientation);            if (!downsampled.equals(rotated) && !pool.put(downsampled)) {                downsampled.recycle();            }        }        return rotated;    } finally {        byteArrayPool.releaseBytes(bytesForOptions);        byteArrayPool.releaseBytes(bytesForStream);        exceptionStream.release();        releaseOptions(options);    }}

这里的核心代码就是第47行代码，调用里downsampleWithSize方法，并得到Bitmap，终于要到从InputStream解除Bitmap的地方里，是不是使用的我们常用的BitmapFactory.decodeStream的方式去解析的呢？继续往下看：

private Bitmap downsampleWithSize(MarkEnforcingInputStream is, RecyclableBufferedInputStream  bufferedStream,        BitmapFactory.Options options, BitmapPool pool, int inWidth, int inHeight, int sampleSize,        DecodeFormat decodeFormat) {    // Prior to KitKat, the inBitmap size must exactly match the size of the bitmap we're decoding.    Bitmap.Config config = getConfig(is, decodeFormat);    options.inSampleSize = sampleSize;    options.inPreferredConfig = config;    if ((options.inSampleSize == 1 || Build.VERSION_CODES.KITKAT <= Build.VERSION.SDK_INT) && shouldUsePool(is)) {        int targetWidth = (int) Math.ceil(inWidth / (double) sampleSize);        int targetHeight = (int) Math.ceil(inHeight / (double) sampleSize);        // BitmapFactory will clear out the Bitmap before writing to it, so getDirty is safe.        setInBitmap(options, pool.getDirty(targetWidth, targetHeight, config));    }    return decodeStream(is, bufferedStream, options);}

这个方法里有对options的设置，核心代码就是第14行代码，调用了decodeStream方法，解析出Bitmap并返回，我们继续往下跟踪：

private static Bitmap decodeStream(MarkEnforcingInputStream is, RecyclableBufferedInputStream bufferedStream,        BitmapFactory.Options options) {     if (options.inJustDecodeBounds) {         // This is large, but jpeg headers are not size bounded so we need something large enough to minimize         // the possibility of not being able to fit enough of the header in the buffer to get the image size so         // that we don't fail to load images. The BufferedInputStream will create a new buffer of 2x the         // original size each time we use up the buffer space without passing the mark so this is a maximum         // bound on the buffer size, not a default. Most of the time we won't go past our pre-allocated 16kb.         is.mark(MARK_POSITION);     } else {         // Once we've read the image header, we no longer need to allow the buffer to expand in size. To avoid         // unnecessary allocations reading image data, we fix the mark limit so that it is no larger than our         // current buffer size here. See issue #225.         bufferedStream.fixMarkLimit();     }    final Bitmap result = BitmapFactory.decodeStream(is, null, options);    try {        if (options.inJustDecodeBounds) {            is.reset();        }    } catch (IOException e) {    }    return result;}

真是千呼万唤始出来，第17行代码，就是使用的BitmapFactory的decodeStream方法，从InputStream解析出图片，当然，Glide已经对options参数已经进行过处理，这里我们就不展开了。到这里，Glide就完成了图片的下载和解析。
我们继续逐级返回到StreamBitmapDecode类中的decode方法，这里会返回BitmapResource对象，里面封装了Bitmap。
再返回到GifBitmapWrapperResourceDecoder类中的decodeBitmapWrapper方法，这里会创建一个GifBitmapWrapper对象，里面封装了BitmapResource，并返回
再返回到GifBitmapWrapperResourceDecoder类中的decode方法，这里会创建一个GifBitmapWarpperResource对象，里面封装了GifBitmapWrapper，并返回
我们再回到DecodeJob.decodeFromSource方法，再来看一遍代码：

public Resource<Z> decodeFromSource() throws Exception {    Resource<T> decoded = decodeSource();    return transformEncodeAndTranscode(decoded);}

由之前的分析可得，decodeSource返回了一个GifBitmapWarpperResource对象，并把该对象传入到transfromEncodeAndTranscode方法中进行转换，我们继续沿着转换的逻辑往下走：

private Resource<Z> transformEncodeAndTranscode(Resource<T> decoded) {    long startTime = LogTime.getLogTime();    Resource<T> transformed = transform(decoded);    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logWithTimeAndKey("Transformed resource from source", startTime);    }    writeTransformedToCache(transformed);    startTime = LogTime.getLogTime();    Resource<Z> result = transcode(transformed);    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logWithTimeAndKey("Transcoded transformed from source", startTime);    }    return result;}

关键代码就是上述第11行代码，调用了transcode方法，把Resource转变成了Resource，由之前的分析可得，Resource就是GifBitmapWarpperResource，那Rsource是什么呢？继续往下看：

private Resource<Z> transcode(Resource<T> transformed) {    if (transformed == null) {        return null;    }    return transcoder.transcode(transformed);}

这里直接调用了transcoder的transcode方法，那transcoder是什么对象呢？它就是中Engine的load方法中构建DecodeJob对象时，传入的GifBitmapWrapperDrawableTranscoder对象，那我们来看看GifBitmapWrapperDrawableTranscoder的transcode方法：

public Resource<GlideDrawable> transcode(Resource<GifBitmapWrapper> toTranscode) {    GifBitmapWrapper gifBitmap = toTranscode.get();    Resource<Bitmap> bitmapResource = gifBitmap.getBitmapResource();    final Resource<? extends GlideDrawable> result;    if (bitmapResource != null) {        result = bitmapDrawableResourceTranscoder.transcode(bitmapResource);    } else {        result = gifBitmap.getGifResource();    }    // This is unchecked but always safe, anything that extends a Drawable can be safely cast to a Drawable.    return (Resource<GlideDrawable>) result;}

第3行代码，就是从GifBitmapWarpperResource中取出GifBitmapWarpperResource
第7行代码，调用了bitmapDrawableResourceTranscoder的transcode方法，bitmapDrawableResourceTranscoder是个什么对象呢？这个也可以从Glide的构造方法里找到，这里就不展开了，它其实就是一个GlideBitmapDrawableTranscoder对象，我们来看它的transcode方法：

@Overridepublic Resource<GlideBitmapDrawable> transcode(Resource<Bitmap> toTranscode) {    GlideBitmapDrawable drawable = new GlideBitmapDrawable(resources, toTranscode.get());    return new GlideBitmapDrawableResource(drawable, bitmapPool);}

这个方法就是从GifBitmapWarpperResource中取出Bitmap，然后构建出GlideBitmapDrawableResource对象，这里其实就是为了图片的统一显示，把封装Bitmap的GifBitmapWarpperResource对象，转换成封装GlideBitmapDrawable的GlideBitmapDrawableResource对象。
这里就逐级返回GlideBitmapDrawableResource，一直到EngineRunnable的run方法中，我们再来看看run方法：

public void run() {    if (isCancelled) {        return;    }    Exception exception = null;    Resource<?> resource = null;    try {        resource = decode();    } catch (Exception e) {        exception = e;    }    if (isCancelled) {        if (resource != null) {            resource.recycle();        }        return;    }    if (resource == null) {        onLoadFailed(exception);    } else {        onLoadComplete(resource);    }}

我们之前流程分析的都是第9行代码的decode，即完成了图片的下载、解析、转换，并返回了GlideBitmapDrawableResource对象，这时候就来到最后的流程，图片展示。
我们先看第24行代码，即图片下载成功，会调用onLoadComplete方法，源码如下：

private void onLoadComplete(Resource resource) {    manager.onResourceReady(resource);}

这里直接调用了manager的onRsourceReady方法，manager是个什么对象呢？其实就是在Engine.load方法中创建EngineRunnable时传入的EngineJob对象，我们看看EngineJob的onResourceReady

@Overridepublic void onResourceReady(final Resource<?> resource) {    this.resource = resource;    MAIN_THREAD_HANDLER.obtainMessage(MSG_COMPLETE, this).sendToTarget();}

这个方法还是在子线程当中执行的，所以为了给ImageView设置图片，使用Handler发消息，注意的一点，这里会把this即EnginJob当作msg.obj发送出去，我们来看看MAIN_THREAD_HANDLER的定义

class EngineJob implements EngineRunnable.EngineRunnableManager {    private static final Handler MAIN_THREAD_HANDLER = new Handler(Looper.getMainLooper(), new MainThreadCallback());

它其实是EnginJob中的一个static属性，注意的一点就是，在创建Handler时，传入了主线程的Looper，这样就保证了通过MAIN_THREAD_HANDLER这个Handler发送的消息，永远是在主线程中处理的。
我们来看看MainThreadCallback的handlerMessage方法，在这里会响应MSG_COPLETE的消息：

private static class MainThreadCallback implements Handler.Callback {    @Override    public boolean handleMessage(Message message) {        if (MSG_COMPLETE == message.what || MSG_EXCEPTION == message.what) {            EngineJob job = (EngineJob) message.obj;            if (MSG_COMPLETE == message.what) {                job.handleResultOnMainThread();            } else {                job.handleExceptionOnMainThread();            }            return true;        }        return false;    }}

之前提到的，在onResourceReady使用Handler发送消息时，把EnginJob也一起发送过来了，所以在上述第5行代码，可以通过message.obj得到EngineJob，然后执行到第7行代码，调用了EngineJob的handleResoultOnMainThread方法，我们来看看这个方法：

private void handleResultOnMainThread() {    if (isCancelled) {        resource.recycle();        return;    } else if (cbs.isEmpty()) {        throw new IllegalStateException("Received a resource without any callbacks to notify");    }    engineResource = engineResourceFactory.build(resource, isCacheable);    hasResource = true;    // Hold on to resource for duration of request so we don't recycle it in the middle of notifying if it    // synchronously released by one of the callbacks.    engineResource.acquire();    listener.onEngineJobComplete(key, engineResource);    for (ResourceCallback cb : cbs) {        if (!isInIgnoredCallbacks(cb)) {            engineResource.acquire();            cb.onResourceReady(engineResource);        }    }    // Our request is complete, so we can release the resource.    engineResource.release();}

这里关键代码是上述第19行代码，调用了cb的onResourceReady方法，cb是从ResourceCallback中循环出来的，那cb是什么呢？还记得前面分析是调用过cb的onSizeReady方法，没错cb就是GenericRequest对象，它实现了ResourceCallback接口。它是在Engine.load方法中调用EngineJob.addCallback把GenericRequest对象，加入到EngineJob的回调集合中的。
所以这里调用的是GenericRequest中的onResourceReady方法，代码如下：

public void onResourceReady(Resource<?> resource) {    if (resource == null) {        onException(new Exception("Expected to receive a Resource<R> with an object of " + transcodeClass                + " inside, but instead got null."));        return;    }    Object received = resource.get();    if (received == null || !transcodeClass.isAssignableFrom(received.getClass())) {        releaseResource(resource);        onException(new Exception("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.")        ));        return;    }    if (!canSetResource()) {        releaseResource(resource);        // We can't set the status to complete before asking canSetResource().        status = Status.COMPLETE;        return;    }    onResourceReady(resource, (R) received);}

关键的代码就是上述最后一行代码，调用了onResourceReady的重载方法，代码如下：

private void onResourceReady(Resource<?> resource, R result) {    // We must call isFirstReadyResource before setting status.    boolean isFirstResource = isFirstReadyResource();    status = Status.COMPLETE;    this.resource = resource;    if (requestListener == null || !requestListener.onResourceReady(result, model, target, loadedFromMemoryCache,            isFirstResource)) {        GlideAnimation<R> animation = animationFactory.build(loadedFromMemoryCache, isFirstResource);        target.onResourceReady(result, animation);    }    notifyLoadSuccess();    if (Log.isLoggable(TAG, Log.VERBOSE)) {        logV("Resource ready in " + LogTime.getElapsedMillis(startTime) + " size: "                + (resource.getSize() * TO_MEGABYTE) + " fromCache: " + loadedFromMemoryCache);    }}

这里调用了target的onResourceReady方法，target是什么呢？它其实是调用GenericRequest.obtaion来构造GenericeRequest对象时，传入的GlideDrawableImageViewTarget对象，所以我们继续看GlideDrawableImageViewTarget的onResourceReady方法：

public void onResourceReady(GlideDrawable resource, GlideAnimation<? super GlideDrawable> animation) {    if (!resource.isAnimated()) {        //TODO: Try to generalize this to other sizes/shapes.        // This is a dirty hack that tries to make loading square thumbnails and then square full images less costly        // by forcing both the smaller thumb and the larger version to have exactly the same intrinsic dimensions.        // If a drawable is replaced in an ImageView by another drawable with different intrinsic dimensions,        // the ImageView requests a layout. Scrolling rapidly while replacing thumbs with larger images triggers        // lots of these calls and causes significant amounts of jank.        float viewRatio = view.getWidth() / (float) view.getHeight();        float drawableRatio = resource.getIntrinsicWidth() / (float) resource.getIntrinsicHeight();        if (Math.abs(viewRatio - 1f) <= SQUARE_RATIO_MARGIN                && Math.abs(drawableRatio - 1f) <= SQUARE_RATIO_MARGIN) {            resource = new SquaringDrawable(resource, view.getWidth());        }    }    super.onResourceReady(resource, animation);    this.resource = resource;    resource.setLoopCount(maxLoopCount);    resource.start();}

这里其实就是调用了父类的ImageViewTarget的onResourceReady方法，代码如下：

@Overridepublic void onResourceReady(Z resource, GlideAnimation<? super Z> glideAnimation) {    if (glideAnimation == null || !glideAnimation.animate(resource, this)) {        setResource(resource);    }}

这里调用了子类GlideDrawableImageViewTarget的setResource方法：

protected void setResource(GlideDrawable resource) {    view.setImageDrawable(resource);}

终于，网络图片就显示到了ImageView上
到这里，Glide.with().load().into()正常加载网络图片的流程就分析完了
而EngineRunnable的run方法中，如果decode方法返回的图片资源为null，则会调用onLoadFailed方法，这个也是通过Handler发消息，然后在主线程中设置加载失败的图片资源，流程和onLoadComplete完全一样，就不展开分析了。

可知Glide加载图片的主要流程就是：

1. with：创建RequestManager，并根据传入参数，初始化好对应的生命周期
2. load：用于初始化好图片下载、图片解析、图片转换的各个对象，用于后续流程
3. into：在线程池中去执行EngineRunnale的run方法，用HttpURLConnection下载图片、用BitmapFactory.decodeStream完成解码、然后把Bitmap转换成可统一展示的GlideBitmapDrawable、最后通过Handler发消息，在主线程中给ImageView设置图片

再回到开始的问题：
1. Glide图片是用什么来下载的？HttpClient还是HttpURLConnection?亦或OKHttp?
答：Glide的图片是使用HttpURLConnectioin来下载的
2. Glide图片是通过怎么解码的？是我们通常使用的BitmapFactory.decodeXXX方法么？
答：Glide图片解码就是使用BitmapFactory.decodeStream方法解码的
3. Glide下载好图片以后，是怎么加载到ImageView上的？
答：Glide下载好图片以后，是使用Handler发消息，把图片设置到ImageView上
4. Glide怎么实现缓存的？是LruCache和DiskLruCache么？
5. Glide的线程是怎么管理的？几个核心线程？几个最大线程？有最大任务数的限制么？
6. Glide是怎么支持Gif图的？是通过Movie对象么？

至于4、5、6的问题，等下篇博客来一起探讨吧！强烈欢迎留言，一起讨论Glide的问题。