[移动开发]Glide源码分析之Glide的整体加载流程

??大家应该都听说过Glide图片加载库，或多或少都知道怎么去使用Glide去加载一张图片。Glide对于使用者来说是非常友好的一个库。那么今天我们就来学习Glide的源码，网上也有很有优秀的博客讲解Glide的源码的，现在我们一起来学习Glide的源码。这个优秀的框架是怎么帮助我们实现图片的加载和显示的。很多人看源码都不知道从哪里下手。这篇博客也分享一下我平时是怎么看源码的。这是基于Glide：4.10版本的源码分析

??首先我们平时是怎么使用Glide的？

Glide.with(context).load(url).into(iv);

这就是平时使用Glide的代码，那么看源码也很简单，就直接从这一段代码开始看，这段代码有三个部分，这三个部分分别是with，load和into。我们这个分析源码也一步一步分析这三个步骤。下面就来看看with，load，into分别做了什么。

Glide.with(context)

//Glide#with(表示某个类的某个方法)
//注意这里返回值是RequestManager，为什么要注意这个，因为后面的load是基于这个返回值去调用的
  @NonNull
  public static RequestManager with(@NonNull Context context) {
    return getRetriever(context).get(context);
  }

我们点进去Glide的源码看一下，看with这个函数，它有很多重载函数，但是他们里面都有一个相同的步骤就是调用getRetriever(context).get(context)。

那么接下来继续跟下去，因为通过getRetriever(context).get(context)我们并不知道里面是什么，看源码的话，就是要知道这里面究竟做了什么。这个方法有两个调用，首先先看getRetriever()

Glide#getRetriever

// Glide#getRetriever
  @NonNull
  private static RequestManagerRetriever getRetriever(@Nullable Context context) {
    //做一下判空，真正有用的是下面那句
    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).");
    //执行Glide.get(context).getRequestManagerRetriever()
    return Glide.get(context).getRequestManagerRetriever();
  }

这个方法也有两个调用，他里面真正重要的是 Glide.get(context)。因为getRequestManagerRetriever()只是返回一个RequestManagerRetriever而已。所以接下来我们要重点关注了就是Glide.get(context)

Glide#get(context)

  @NonNull
  public static Glide get(@NonNull Context context) {
  //这里使用的是双重检查模式的单例模式去创建一个Glide的单例，所以接下来我们需要知道的就是怎么去创建Glide，以及这个过程中间做了什么
    if (glide == null) {
    //通过反射找到GeneratedAppGlideModuleImpl 类，如果能找到，就说明自定义了GlideModule，那么就需要实现自己的自定义功能。但是这个对于我们的影响并不大，我们可以忽略这个参数，因为我们分析源码整体流程Glide.with(context).load(url).into(iv);是没有使用到这一部分的
      GeneratedAppGlideModule annotationGeneratedModule =
          getAnnotationGeneratedGlideModules(context.getApplicationContext());
      synchronized (Glide.class) {
        if (glide == null) {
          checkAndInitializeGlide(context, annotationGeneratedModule);
        }
      }
    }

    return glide;
  }
  
  @GuardedBy("Glide.class")
  private static void checkAndInitializeGlide(
      @NonNull Context context, @Nullable GeneratedAppGlideModule generatedAppGlideModule) {

    if (isInitializing) {
      throw new IllegalStateException(
          "You cannot call Glide.get() in registerComponents(),"
              + " use the provided Glide instance instead");
    }
    isInitializing = true;
    initializeGlide(context, generatedAppGlideModule);
    isInitializing = false;
  }
  

  @GuardedBy("Glide.class")
  private static void initializeGlide(
      @NonNull Context context, @Nullable GeneratedAppGlideModule generatedAppGlideModule) {
    initializeGlide(context, new GlideBuilder(), generatedAppGlideModule);
  }
  
/**
  *这个方法代码看起来很多，但是我们只需要关注对我们有用的代码逻辑即可，
  *有人问了什么是有用的代码逻辑？现在我们回想一下我们跟进这一部分的源码的目的是什么？
  *是创建Glide单例对不对？所以我们重点关注这一块就好了。其他的代码逻辑是配置一些注解之后Glide的逻辑，所以目前我们不用管这部分逻辑，但是我还是会注释每一部分是做什么的
  */
    private static void initializeGlide(
      @NonNull Context context,
      @NonNull GlideBuilder builder,
      @Nullable GeneratedAppGlideModule annotationGeneratedModule) {
    Context applicationContext = context.getApplicationContext();
    List<com.bumptech.glide.module.GlideModule> manifestModules = Collections.emptyList();
    if (annotationGeneratedModule == null || annotationGeneratedModule.isManifestParsingEnabled()) {
    // 从AndroidManifest.xml 获取自定义的GlideModule（这是另外一种自定义GlideModule的方式）
      manifestModules = new ManifestParser(applicationContext).parse();
    }
// 根据Impl的黑名单，剔除manifest中的GlideModule类
    if (annotationGeneratedModule != null
        && !annotationGeneratedModule.getExcludedModuleClasses().isEmpty()) {
      Set<Class<?>> excludedModuleClasses = annotationGeneratedModule.getExcludedModuleClasses();
      Iterator<com.bumptech.glide.module.GlideModule> iterator = manifestModules.iterator();
      while (iterator.hasNext()) {
        com.bumptech.glide.module.GlideModule current = iterator.next();
        if (!excludedModuleClasses.contains(current.getClass())) {
          continue;
        }
        if (Log.isLoggable(TAG, Log.DEBUG)) {
          Log.d(TAG, "AppGlideModule excludes manifest GlideModule: " + current);
        }
        iterator.remove();
      }
    }

    if (Log.isLoggable(TAG, Log.DEBUG)) {
      for (com.bumptech.glide.module.GlideModule glideModule : manifestModules) {
        Log.d(TAG, "Discovered GlideModule from manifest: " + glideModule.getClass());
      }
    }
// 获取工厂，用于创建RequestManager（该工厂用于，如果with（）参数传递的是application）
    RequestManagerRetriever.RequestManagerFactory factory =
        annotationGeneratedModule != null
            ? annotationGeneratedModule.getRequestManagerFactory()
            : null;
    builder.setRequestManagerFactory(factory);
     //执行用户在 manifest 中配置的 GlideModule 接口中的方法
    for (com.bumptech.glide.module.GlideModule module : manifestModules) {
      module.applyOptions(applicationContext, builder);
    }
    //执行使用注解配置的GlideModule 接口中的方法
    if (annotationGeneratedModule != null) {
      annotationGeneratedModule.applyOptions(applicationContext, builder);
    }
    //创建Glide
    Glide glide = builder.build(applicationContext);
      //下面registerComponents 方法的执行，需要传递Registry对象，而该对象是在创建Glide 的时候，被赋值，并设置一系列的参数
        //执行用户在 manifest 中配置的 GlideModule 接口中的registerComponents 方法
    for (com.bumptech.glide.module.GlideModule module : manifestModules) {
      try {
        module.registerComponents(applicationContext, glide, glide.registry);
      } catch (AbstractMethodError e) {
        throw new IllegalStateException(
            "Attempting to register a Glide v3 module. If you see this, you or one of your"
                + " dependencies may be including Glide v3 even though you're using Glide v4."
                + " You'll need to find and remove (or update) the offending dependency."
                + " The v3 module name is: "
                + module.getClass().getName(),
            e);
      }
    }
     //执行 使用注解配置的GlideModule 接口中的registerComponents 方法
    if (annotationGeneratedModule != null) {
      annotationGeneratedModule.registerComponents(applicationContext, glide, glide.registry);
    }
    applicationContext.registerComponentCallbacks(glide);
     //向单例赋值
    Glide.glide = glide;
  }

如果只用Glide.with(context).load(url).into(iv);其实上面的initializeGlide方法可以简化成如下：

Glide#initializeGlide（简化）

    private static void initializeGlide(
      @NonNull Context context,
      @NonNull GlideBuilder builder,
      @Nullable GeneratedAppGlideModule annotationGeneratedModule) {
    Context applicationContext = context.getApplicationContext();
    //创建Glide
    Glide glide = builder.build(applicationContext);
    applicationContext.registerComponentCallbacks(glide);
     //向单例赋值
    Glide.glide = glide;
  }

所以接下来的目的就清晰了就是 builder.build(applicationContext)是如何创建glide的。builder是在initializeGlide(context, new GlideBuilder(), generatedAppGlideModule)的时候，自己创建的一个GlideBuilder

GlideBuilder#build

//GlideBuilder#build
  Glide build(@NonNull Context context) {
     //源执行器允许在其线程上进行网络操作,也就是用于网络操作获取资源的
    if (sourceExecutor == null) {
      sourceExecutor = GlideExecutor.newSourceExecutor();
    }
	//磁盘缓存执行器,不允许对其线程进行网络操作
    if (diskCacheExecutor == null) {
      diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();
    }
	//动画执行器,不允许在其线程上进行网络操作
    if (animationExecutor == null) {
      animationExecutor = GlideExecutor.newAnimationExecutor();
    }
	//根据当前机器参数计算需要设置的缓存大小
    if (memorySizeCalculator == null) {
      memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();
    }

    if (connectivityMonitorFactory == null) {
      connectivityMonitorFactory = new DefaultConnectivityMonitorFactory();
    }
    //创建 Bitmap 池，用于回收LruCache缓存的图片，把图片回收到bitmapPool中，这样下次再创建图片时，可复用该内存，避免连续创建回收内存，造成的内存抖动
    if (bitmapPool == null) {
      int size = memorySizeCalculator.getBitmapPoolSize();
      if (size > 0) {
        bitmapPool = new LruBitmapPool(size);
      } else {
        bitmapPool = new BitmapPoolAdapter();
      }
    }
	//一个固定大小的数组池，它使用 LRU 策略驱逐数组，以使池保持在最大字节大小以下。
    if (arrayPool == null) {
      arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());
    }
	//创建内存缓存
    if (memoryCache == null) {
      memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
    }
	//创建磁盘缓存
    if (diskCacheFactory == null) {
      diskCacheFactory = new InternalCacheDiskCacheFactory(context);
    }
//创建Engine，真正处理request的类，例如发起网络请求图片，从磁盘读取图片等。
    if (engine == null) {
      engine =
          new Engine(
              memoryCache,
              diskCacheFactory,
              diskCacheExecutor,
              sourceExecutor,
              GlideExecutor.newUnlimitedSourceExecutor(),
              animationExecutor,
              isActiveResourceRetentionAllowed);
    }

    if (defaultRequestListeners == null) {
      defaultRequestListeners = Collections.emptyList();
    } else {
      defaultRequestListeners = Collections.unmodifiableList(defaultRequestListeners);
    }
 //创建RequestManagerRetriever 上面分析的getRetriever() 返回的就是该对象
    RequestManagerRetriever requestManagerRetriever =
        new RequestManagerRetriever(requestManagerFactory);
	//创建Glide
    return new Glide(
        context,
        engine,
        memoryCache,
        bitmapPool,
        arrayPool,
        requestManagerRetriever,
        connectivityMonitorFactory,
        logLevel,
        defaultRequestOptionsFactory,
        defaultTransitionOptions,
        defaultRequestListeners,
        isLoggingRequestOriginsEnabled,
        isImageDecoderEnabledForBitmaps);
  }

现在就到了Glide的构造函数了，整一个Glide的构造方法代码很多，这里会精简一下代码，然后介绍各个部分的作用

Glide#Glide

  Glide(
      @NonNull Context context,
      @NonNull Engine engine,
      @NonNull MemoryCache memoryCache,
      @NonNull BitmapPool bitmapPool,
      @NonNull ArrayPool arrayPool,
      @NonNull RequestManagerRetriever requestManagerRetriever,
      @NonNull ConnectivityMonitorFactory connectivityMonitorFactory,
      int logLevel,
      @NonNull RequestOptionsFactory defaultRequestOptionsFactory,
      @NonNull Map<Class<?>, TransitionOptions<?, ?>> defaultTransitionOptions,
      @NonNull List<RequestListener<Object>> defaultRequestListeners,
      boolean isLoggingRequestOriginsEnabled,
      boolean isImageDecoderEnabledForBitmaps) {
    this.engine = engine;
    this.bitmapPool = bitmapPool;
    this.arrayPool = arrayPool;
    this.memoryCache = memoryCache;
    this.requestManagerRetriever = requestManagerRetriever;
    this.connectivityMonitorFactory = connectivityMonitorFactory;
    this.defaultRequestOptionsFactory = defaultRequestOptionsFactory;

    final Resources resources = context.getResources();

    registry = new Registry();
    registry.register(new DefaultImageHeaderParser());
     //...
	//这里省略一些代码，下面是创建需要加入register的类，register类很重要，后面分析很多关键代码都会用到register，这里要有一个印象
      
      
    ContentResolver contentResolver = context.getContentResolver();

	//添加各种Encoder（把数据存为File）、ResourceDecoder（把数据从类型A转为类型B）
    //ModelLoaderFactory（用于创建ModelLoader，它用于将任意复杂的数据模型转换为可由 DataFetcher 获取模型所代表的资源数据的具体数据类型。用来加载资源的。 

	//这里省略大量调用register的各种append()与register()方法，添加各种register
      registry
        .append(...)
        .register(...)
        ...
	//该工厂用于生产ImageViewTarget，最终通过ImageViewTarget对象把图片addView到界面上 
    ImageViewTargetFactory imageViewTargetFactory = new ImageViewTargetFactory();
      //创建GlideContext
    glideContext =
        new GlideContext(
            context,
            arrayPool,
            registry,
            imageViewTargetFactory,
            defaultRequestOptionsFactory,
            defaultTransitionOptions,
            defaultRequestListeners,
            engine,
            isLoggingRequestOriginsEnabled,
            logLevel);
  }

下面讲解一下Registry 对象，调用append，register 方法的作用。首先设置一些参数。这些参数，主要作用就是对后面的图片解析、加载。

看一下Register的构造函数

Registry#Registry

//  Registry#Registry()
public Registry() {
    this.modelLoaderRegistry = new ModelLoaderRegistry(throwableListPool);
    this.encoderRegistry = new EncoderRegistry();
    this.decoderRegistry = new ResourceDecoderRegistry();
    this.resourceEncoderRegistry = new ResourceEncoderRegistry();
    this.dataRewinderRegistry = new DataRewinderRegistry();
    this.transcoderRegistry = new TranscoderRegistry();
    this.imageHeaderParserRegistry = new ImageHeaderParserRegistry();
    setResourceDecoderBucketPriorityList(
        Arrays.asList(BUCKET_GIF, BUCKET_BITMAP, BUCKET_BITMAP_DRAWABLE));
  }

this.modelLoaderRegistry是一个重要的成员变量，它里面有 ModelLoaderFactory，而ModelLoaderFactory它是用来创建**ModelLoader**的。这个ModelLoader很重要，所以大家要对他有一定的印象。那么ModelLoader是做什么的呢？

ModelLoader

作用：**一个工厂接口，用于将任意复杂的数据模型转换为可由 DataFetcher 用于获取模型所代表的资源数据的具体数据类型。**可以翻译为加载器。

该接口有两个目标： 1. 将特定模型转换为可解码为资源的数据类型。 2. 允许模型与视图的维度相结合以获取特定大小的资源。这样是为了节省空间。就是可以根据ImageView的大小加载图片

Glide 初始化时会注册很多个 ModelLoader ，除了在创建Glide时 通过registry 注册的，还会注册那些用户在 manifest 中配置的 ModelLoader。
那么我们来看看modelLoader里面有什么功能

//ModelLoader里面的方法
//buildLoadData 方法构建一个 LoadData 实例，除了包含 Model 之外还有宽高以及 Option，加载图片时可以根据需要的宽高以及其他设置做到按需加载。
@Nullable
LoadData<Data> buildLoadData(@NonNull Model model, int width, int height,
                                 @NonNull Options options);

//如果给定模型是此加载器可能加载的可识别类型，则返回 true。
boolean handles(@NonNull Model model);

LoadData是ModelLoader的内部类 ，主要作用就是装了三个东西：

• 用于识别资源唯一性的 Key;
• 缓存相关的备用 Key 列表
• DataFetcher

其中 DataFetcher最重要，加载资源的根源就在这里，例如发起网络请求等等，都在这个里面。

来看回Register的构造函数里面还有一些参数

this.decoderRegistry = new ResourceDecoderRegistry();//这个是用于解码
this.resourceEncoderRegistry = new ResourceEncoderRegistry();//这个是用于编码

decoderRegistry 保存的是ResourceDecoder对象

ResourceDecoder与ResourceEecoder

ResourceDecoder的作用是将ModelLoader加载出来的数据，进行解码，解码成Bitmap，或者BitmapDrawable之类的。Glide中常用的Decoder有两个，其他都是将这两个Decoder进行包装，它们分别是ByteBufferBitmapDecoder和StreamBitmapDecoder。ResourceEncoder的作用正好相反。

DataRewinder

this.dataRewinderRegistry = new DataRewinderRegistry();

dataRewinderRegistry 中保存的是DataRewinder

Rewinder担任的是ModelLoader到ResourceDecoder的桥梁的角色，DecodeJob将ModelLoader获得的数据，构造出DataRewinder，然后使用Rewinder将数据传给ResourceDecoder进行解码。

Encoder

this.encoderRegistry = new EncoderRegistry();

encoderRegistry 中保存的是 Encoder对象。Encoder的作用是将数据转换成文件，用来配合Glide硬盘缓存。所以Encoder的相关类，都是转为File类型的。

好，这个Registry的知识点，大家要多看一遍，不并且理清楚他们之间的关系，不然后面讲解会一脸懵逼，不知道哪个类是做什么的。

到这里Register的创建也讲解完了，也就是Glide的创建也讲解完了。那么现在我们应该回到哪一步？很多人看到这已经蒙圈了，接下来的下一步做什么自己不知道了，因为我们看源码的时候很容易跟着跟着就忘记自己一开始是为了看哪个方法而进去的了，这时候会一直回退啊回退。但是如果有博客给你参考一下有不一样了，因为博客整体下来是一个链式的形式，我们可以更加清晰的知道我们下一步做啥，废话说多了。

我们回到Glide.with(context)方法里面

  @NonNull
  public static RequestManager with(@NonNull Context context) {
    return getRetriever(context).get(context);
  }

这里面我们是不是只看了getRetriever(context)里面的代码逻辑，也就是说，还有一部分没有看，既然我们要看Glide.with(context)我们就看完它。

RequestManagerRetriever#get()

  @NonNull
  public RequestManager get(@NonNull 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
          // Only unwrap a ContextWrapper if the baseContext has a non-null application context.
          // Context#createPackageContext may return a Context without an Application instance,
          // in which case a ContextWrapper may be used to attach one.
          && ((ContextWrapper) context).getBaseContext().getApplicationContext() != null) {
        return get(((ContextWrapper) context).getBaseContext());
      }
    }

    return getApplicationManager(context);
  }

从这里可以知道get()有很多重载函数，看一下这里的逻辑，这里判断了如果当前线程是后台线程，那么就直接调用getApplicationManager(context)，然后返回一个RequestManager

RequestManagerRetriever#getApplicationManager（后台线程）

  @NonNull
  private RequestManager getApplicationManager(@NonNull Context context) {
    if (applicationManager == null) {
      synchronized (this) {
        if (applicationManager == null) {
          Glide glide = Glide.get(context.getApplicationContext());
          applicationManager =
              factory.build(
                  glide,
                  new ApplicationLifecycle(),
                  new EmptyRequestManagerTreeNode(),
                  context.getApplicationContext());
        }
      }
    }

    return applicationManager;
  }

如果是前台线程会做什么，他们最终会调用RequestManagerRetriever的get重载函数

public RequestManager get(@NonNull View view) 
public RequestManager get(@NonNull Activity activity) 
public RequestManager get(@NonNull Fragment fragment) 
public RequestManager get(@NonNull FragmentActivity activity) 

get(View)和get(Context)会根据情况调用get(Fragment)或get(FragmentActivity)。其中get(View)为了找到一个合适的Fragment或fallback Activity，内部操作比较多，开销比较大，不要轻易使用。

RequestManagerRetriever#supportFragmentGet

get(Fragment)和get(FragmentActivity)方法都会调用supportFragmentGet方法，只是传入参数不同：

//get(@NonNull FragmentActivity activity) 
FragmentManager fm = activity.getSupportFragmentManager();
supportFragmentGet(activity, fm, /*parentHint=*/ null, isActivityVisible(activity));

// Fragment fragment
FragmentManager fm = fragment.getChildFragmentManager();
supportFragmentGet(fragment.getActivity(), fm, fragment, fragment.isVisible());

注意：Glide会使用一个加载目标所在的宿主Activity或Fragment的子Fragment来安全保存一个RequestManager，而RequestManager被Glide用来开始、停止、管理Glide请求。

而supportFragmentGet就是创建/获取这个SupportRequestManagerFragment，并返回其持有的RequestManager的方法。

@NonNull
private RequestManager supportFragmentGet(
    @NonNull Context context,
    @NonNull FragmentManager fm,
    @Nullable Fragment parentHint,
    boolean isParentVisible) {
  // 获取一个SupportRequestManagerFragment
  SupportRequestManagerFragment current =
      getSupportRequestManagerFragment(fm, parentHint, isParentVisible);
  // 获取里面的RequestManager对象
  RequestManager requestManager = current.getRequestManager();
  // 若没有，则创建一个
  if (requestManager == null) {
    // TODO(b/27524013): Factor out this Glide.get() call.
    Glide glide = Glide.get(context);
    // 
    requestManager =
        factory.build(
            glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
    // 设置到SupportRequestManagerFragment里面，下次就不需要创建了
    current.setRequestManager(requestManager);
  }
  return requestManager;
}

// 看看Fragment怎么才能高效
@NonNull
private SupportRequestManagerFragment getSupportRequestManagerFragment(
    @NonNull final FragmentManager fm, @Nullable Fragment parentHint, boolean isParentVisible) {      
  // 已经添加过了，可以直接返回
  SupportRequestManagerFragment current =
      (SupportRequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
  if (current == null) {
    // 从map中获取，取到也可以返回了
    current = pendingSupportRequestManagerFragments.get(fm);
    if (current == null) {
      // 都没有，那么就创建一个，此时lifecycle默认为ActivityFragmentLifecycle
      current = new SupportRequestManagerFragment();
      // 对于fragment来说，此方法会以Activity为host创建另外一个SupportRequestManagerFragment
      // 作为rootRequestManagerFragment
      // 并会将current加入到rootRequestManagerFragment的childRequestManagerFragments中
      // 在RequestManager递归管理请求时会使用到
      current.setParentFragmentHint(parentHint);
      // 如果当前页面是可见的，那么调用其lifecycle的onStart方法
      if (isParentVisible) {
        current.getGlideLifecycle().onStart();
      }
      // 将刚创建的fragment缓存起来
      pendingSupportRequestManagerFragments.put(fm, current);
      // 将fragment添加到页面中
      fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
      // 以fm为key从pendingSupportRequestManagerFragments中删除
      handler.obtainMessage(ID_REMOVE_SUPPORT_FRAGMENT_MANAGER, fm).sendToTarget();
    }
  }
  return current;
}

到这里RequestManager就创建完成了。现在还有一个get(Activity)的重载函数没有分析。这个函数最终调用逻辑和get(Fragment)差不多，只不过他在中间创建的Fragment是RequestManagerFragment。其余的逻辑都是一样的了。所以整一个Glide.with的过程也就分析完成了。其实他里面主要做的一些事情就是初始化一些配置，并且创建一些类，比如Glide的创建，Register的创建，RequestManager的创建。接下来我们用一张图来总结Glide.with的流程：如下

好了，到这里第一部分的内容已经讲解完了，在讲解第二部分的内容的时候。我们先思考一个问题，如果要显示一张图片需要几个步骤？我个人认为需要以下步骤

• 获取资源
• 编解码资源
• 将图片显示

这其中获取资源是不是还可以分本地资源，网络资源，是不是从缓存获取等等？那么回过头来看一下Glide.with做了什么?以上步骤，他一步也没有做。它仅仅是做了一些初始化的工作而已，所以我们离分析完Gilde源码还有一大段路。不是我打击大家的学习信心，因为Glide的源码确实比较多。那么接下来就开始第二部分的讲解吧。

RequestManager.load

RequestManager的load方法也有很多重载函数，他们都调用了asDrawable()方法，然后再调用对应的load方法

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

RequestManager#asDrawable

  public RequestBuilder<Drawable> asDrawable() {
    return as(Drawable.class);//调用as方法，返回RequestBuilder对象
  }
  public <ResourceType> RequestBuilder<ResourceType> as(
      @NonNull Class<ResourceType> resourceClass) {
    return new RequestBuilder<>(glide, this, resourceClass, context);//创建RequestBuilder对象
  }

RequestBuilder#RequestBuilder()

在RequestBuilder的构造器方法方法中将Drawable.class这样的入参保存到了transcodeClass变量中：

@SuppressLint("CheckResult")
@SuppressWarnings("PMD.ConstructorCallsOverridableMethod")
protected RequestBuilder(
    @NonNull Glide glide,
    RequestManager requestManager,
    Class<TranscodeType> transcodeClass,
    Context context) {
  this.glide = glide;
  this.requestManager = requestManager;
  this.transcodeClass = transcodeClass;
  this.context = context;
  this.transitionOptions = requestManager.getDefaultTransitionOptions(transcodeClass);
  this.glideContext = glide.getGlideContext();

  initRequestListeners(requestManager.getDefaultRequestListeners());
  apply(requestManager.getDefaultRequestOptions());
}

到这里，asDrawable()的流程就分析完毕了，返回的是一个RequestBuilder，然后再调用RequestBuilder的load方法

RequestBuilder#load

  public RequestBuilder<TranscodeType> load(@Nullable String string) {
    return loadGeneric(string);
  }
   private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
    this.model = model;
    isModelSet = true;
    return this;
  }

我们发现这里也没有做什么其他操作，只是将isModelSe设置为true而已。所以第二部分分析也完了，这里就两个重要的事情，一个是创建看RequestBuilder

一个是将RequestBuilder中的isModelSet设置为true。由于这个第二部分比较简单，所以在这里，就不画流程图了，大家应该也能看得懂。Glide源码讲到这里，还是没有讲解到怎么获取资源。所以接下来第三部分RequestBuilder.into也就是Glide最核心的部分了。这一部分的内容比前面两节多很多，希望大家耐心看完。因为它里面做了三件事，也就是我们上面提到的三件事。

• 获取资源
• 编解码资源
• 将图片显示

所以into如果要分步骤看的话，也可以按照三面的三大步骤来看。

RequestBuilder.into

首先看into(ImageView)函数

public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
    Util.assertMainThread();
    Preconditions.checkNotNull(view);

    BaseRequestOptions<?> requestOptions = this;
    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.
     // 根据ImageView 的ScaleType 类型，进行参数设置，注意这里是clone 一个新的对象，在新对象上操作的。为什么要克隆一个新的对象？当使用此RequestOptions加载到一个View，然后加载到另外一个目标时，不要保留基于上一个View的scale type所产生的transformation。
      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),//注意这个transcodeClass，如果我们用的是string作为load的参数，这里传的是Drawable.class
        /*targetListener=*/ null,
        requestOptions,
        Executors.mainThreadExecutor());
  }

到这里很多人又开始疑惑了，我到底是去看into这个重载函数，还是先看glideContext.buildImageViewTarget，这种情况的先，哪个先执行看哪个。很明显这里是glideContext.buildImageViewTarget先执行，所以我们优先看一下这里面做了什么。

GlideContext#buildImageViewTarget

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

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)");
    }
  }

Glide内部只维护了两种target，一种是BitmapImageViewTarget，另一种则是DrawableImageViewTarget，由于我们前面使用的是load(String)，这里最终返回的是DrawableImageViewTarget。这里需要稍微留意一下，因为最终显示资源的那一步决定我们去DrawableImageViewTarget中看还是BitmapImageViewTarget中看。

RequestBuilder#into

接下来我们重新回到into的重载函数里面

  private <Y extends Target<TranscodeType>> Y into(
      @NonNull Y target,
      @Nullable RequestListener<TranscodeType> targetListener,
      BaseRequestOptions<?> options,
      Executor callbackExecutor) {
    Preconditions.checkNotNull(target);
      //这里之前讲过，isModelSet设置了为true
    if (!isModelSet) {
      throw new IllegalArgumentException("You must call #load() before calling #into()");
    }
	// 创建请求，用于显示图片。图片有可能是从缓存中，也有可能是从网络获取
    Request request = buildRequest(target, targetListener, options, callbackExecutor);
     // 这里会判断需不需要重新开始任务
      // 如果当前request和target上之前的request previous相等
      // 且设置了忽略内存缓存或previous还没有完成
      // 那么会进入if分支，无需进行一些相关设置，这是一个很好的优化
    Request previous = target.getRequest();
    if (request.isEquivalentTo(previous)
        && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {
         // 如果正在运行，就不管它；如果已经失败了，就重新开始
      if (!Preconditions.checkNotNull(previous).isRunning()) {
        
        previous.begin();
      }
      return target;
    }
	// 如果不能复用previous
  	// 先清除target上之前的Request
    requestManager.clear(target);
     // 将Request作为tag设置到view中
    target.setRequest(request);
     //真正开始网络图片的加载
    requestManager.track(target, request);

    return target;
  }

到这里很多人开始问了，这里这么多代码逻辑，我们应该怎么去看源码？首先还是之前的原则，哪一个开始就先看哪一个。先看怎么创建Request，以及这个Request的类型是什么，然后我们才能去看下一步是做什么。

RequestBuilder#buildRequest

下面这段代码有点长，因为我把整一个创建Request的调用链放在了一段代码里面，是为了大家更加方便的阅读，至于每一段代码做了什么，我会在通过注释的方式写明。

  private Request buildRequest(
      Target<TranscodeType> target,
      @Nullable RequestListener<TranscodeType> targetListener,
      BaseRequestOptions<?> requestOptions,
      Executor callbackExecutor) {
    return buildRequestRecursive(
        /*requestLock=*/ new Object(),
        target,
        targetListener,
        /*parentCoordinator=*/ null,
        transitionOptions,
        requestOptions.getPriority(),
        requestOptions.getOverrideWidth(),
        requestOptions.getOverrideHeight(),
        requestOptions,
        callbackExecutor);
  }

  private Request buildRequestRecursive(
      Object requestLock,
      Target<TranscodeType> target,
      @Nullable RequestListener<TranscodeType> targetListener,
      @Nullable RequestCoordinator parentCoordinator,
      TransitionOptions<?, ? super TranscodeType> transitionOptions,
      Priority priority,
      int overrideWidth,
      int overrideHeight,
      BaseRequestOptions<?> requestOptions,
      Executor callbackExecutor) {

    // Build the ErrorRequestCoordinator first if necessary so we can update parentCoordinator.
    ErrorRequestCoordinator errorRequestCoordinator = null;
      //判断是否设置了，发生错误时，显示的图片
    if (errorBuilder != null) {
      errorRequestCoordinator = new ErrorRequestCoordinator(requestLock, parentCoordinator);
      parentCoordinator = errorRequestCoordinator;
    }
//创建缩略图和原图的Request
    Request mainRequest =
        buildThumbnailRequestRecursive(
            requestLock,
            target,
            targetListener,
            parentCoordinator,
            transitionOptions,
            priority,
            overrideWidth,
            overrideHeight,
            requestOptions,
            callbackExecutor);

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

    int errorOverrideWidth = errorBuilder.getOverrideWidth();
    int errorOverrideHeight = errorBuilder.getOverrideHeight();
    if (Util.isValidDimensions(overrideWidth, overrideHeight) && !errorBuilder.isValidOverride()) {
      errorOverrideWidth = requestOptions.getOverrideWidth();
      errorOverrideHeight = requestOptions.getOverrideHeight();
    }
  //创建错误时图片的内容
    Request errorRequest =
        errorBuilder.buildRequestRecursive(
            requestLock,
            target,
            targetListener,
            errorRequestCoordinator,
            errorBuilder.transitionOptions,
            errorBuilder.getPriority(),
            errorOverrideWidth,
            errorOverrideHeight,
            errorBuilder,
            callbackExecutor);
      //把这两个请求，都传进errorRequestCoordinator中   
    errorRequestCoordinator.setRequests(mainRequest, errorRequest);
    return errorRequestCoordinator;
     //这里我们不需要关注设置错误的请求，这里我列举出来只是为了说明代码是做了什么，真正要关注的是buildThumbnailRequestRecursive这个方法。
  }

//这个方法很长，我把不需要关注的代码省略一部分，只需要关注obtainRequest这个方法，因为这个方法才是创建request并返回的方法
  private Request buildThumbnailRequestRecursive(
      Object requestLock,
      Target<TranscodeType> target,
      RequestListener<TranscodeType> targetListener,
      @Nullable RequestCoordinator parentCoordinator,
      TransitionOptions<?, ? super TranscodeType> transitionOptions,
      Priority priority,
      int overrideWidth,
      int overrideHeight,
      BaseRequestOptions<?> requestOptions,
      Executor callbackExecutor) {
    if (thumbnailBuilder != null) {
      //省略代码
      
    } else if (thumbSizeMultiplier != null) {
 	//省略代码
    } else {
      // Base case: no thumbnail.
      return obtainRequest(
          requestLock,
          target,
          targetListener,
          requestOptions,
          parentCoordinator,
          transitionOptions,
          priority,
          overrideWidth,
          overrideHeight,
          callbackExecutor);
    }
  }

  private Request obtainRequest(
      Object requestLock,
      Target<TranscodeType> target,
      RequestListener<TranscodeType> targetListener,
      BaseRequestOptions<?> requestOptions,
      RequestCoordinator requestCoordinator,
      TransitionOptions<?, ? super TranscodeType> transitionOptions,
      Priority priority,
      int overrideWidth,
      int overrideHeight,
      Executor callbackExecutor) {
      //可以看到，这里返回的是一个SingleRequest，他里面是直接new了一个SingleRequest。到这里就创建了一个SingleRequest并返回。这里需要我们留意一下我们request的类型，方便后面回调的时候看
    return SingleRequest.obtain(
        context,
        glideContext,
        requestLock,
        model,
        transcodeClass,
        requestOptions,
        overrideWidth,
        overrideHeight,
        priority,
        target,
        targetListener,
        requestListeners,
        requestCoordinator,
        glideContext.getEngine(),
        transitionOptions.getTransitionFactory(),
        callbackExecutor);
  }

现在SingleRequest创建完了，那么下一步应该看哪里？下一步是不是回到into方法里面？因为我们into方法还没看完，只是看了into中的buildRequest方法而已，然而他里面还有其他的方法没有看。创建了Request之后，就要执行Request，而执行Request的代码是在requestManager.track(target, request);中的。接下来我们要看的就是requestManager.track(target, request);

RequestManager#track

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

在这里面，targetTracker成员变量在声明的时候直接初始化为TargetTracker类的无参数实例，该类的作用是保存所有的Target并向它们转发生命周期事件；requestTracker在RequestManager的构造器中传入了new RequestTracker()，该类的作用管理所有状态的请求。

RequestTracker#runRequest

  public void runRequest(@NonNull Request request) {
    requests.add(request);
     // //填充目标（ImageView）所在的activity Fragment stop后，isPaused就是true,这里默认是false，所以会先执行request.begin()
    if (!isPaused) {
      request.begin();
    } else {
      request.clear();
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        Log.v(TAG, "Paused, delaying request");
      }
      pendingRequests.add(request);
    }
  }

还记得我们上面讲解怎么创建Request吗？返回的Request的类型其实是SingleRequest。所以这里我们要看SingleRequest的begin()方法了

SingleRequest#begin

  public void begin() {
    synchronized (requestLock) {
      assertNotCallingCallbacks();
      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;
         //如果model（就是我们传的url）为空，回调加载失败
        onLoadFailed(new GlideException("Received null model"), logLevel);
        return;
      }

      if (status == Status.RUNNING) {
        throw new IllegalArgumentException("Cannot restart a running request");
      }

      // If we're restarted after we're complete (usually via something like a notifyDataSetChanged
      // that starts an identical request into the same Target or View), we can simply use the
      // resource and size we retrieved the last time around and skip obtaining a new size, starting
      // a new load etc. This does mean that users who want to restart a load because they expect
      // that the view size has changed will need to explicitly clear the View or Target before
      // starting the new load.
      if (status == Status.COMPLETE) {
         // 如果我们在请求完成后想重新开始加载，那么就会返回已经加载好的资源
  		// 如果由于view尺寸的改变，我们的确需要重新来加载，此时我们需要明确地清除View或Target
        onResourceReady(resource, DataSource.MEMORY_CACHE);
        return;
      }

      // Restarts for requests that are neither complete nor running can be treated as new requests
      // and can run again from the beginning.

      status = Status.WAITING_FOR_SIZE;
       //glide 会根据显示图片的宽高进行缓存，所以这里需要获得View的宽高，overrideWidth，overrideHeight默认为-1
        //所以第一次会到else分支，获取View的宽高
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
        onSizeReady(overrideWidth, overrideHeight);
      } else {
          //第一次执行的时候，肯定是会执行这句话的，到这里很多人看源码的时候就蒙圈的，因为不知道这个target是什么，其实我们上面分析过。在buildImageViewTarget的时候，这里返回的是一个DrawableImageViewTarget。所以可以进去DrawableImageViewTarget这个类里面看，最终会在他的父类ViewTarget里面找到这个getSize()方法，然后ViewTarget中的getSize()方法最终也会回调到onSizeReady()这个方法里面，最终我们要看的是onSizeReady方法
        target.getSize(this);
      }

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

SingleRequest#onSizeReady

public void onSizeReady(int width, int height) {
    stateVerifier.throwIfRecycled();
    synchronized (requestLock) {
      if (IS_VERBOSE_LOGGABLE) {
        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 (IS_VERBOSE_LOGGABLE) {
        logV("finished setup for calling load in " + LogTime.getElapsedMillis(startTime));
      }
       //不知道大家还有没有印象这里的Engine我们前面讲解过，在GlideBuilder#build这一小节中，我们创建了一个Engine，并且配置了各种缓存啥的，没有印象的可以回头看一下那一段代码
      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,
              callbackExecutor);

      // This is a hack that's only useful for testing right now where loads complete synchronously
      // even though under any executor running on any thread but the main thread, the load would
      // have completed asynchronously.
      if (status != Status.RUNNING) {
        loadStatus = null;
      }
      if (IS_VERBOSE_LOGGABLE) {
        logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime));
      }
    }
  }

最终这里调用的是engine的load方法去进行网络请求

Engine#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,
      boolean isScaleOnlyOrNoTransform,
      Options options,
      boolean isMemoryCacheable,
      boolean useUnlimitedSourceExecutorPool,
      boolean useAnimationPool,
      boolean onlyRetrieveFromCache,
      ResourceCallback cb,
      Executor callbackExecutor) {
    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
    //生成缓存key，以后就根据这个key，在缓存中查找
    EngineKey key =
        keyFactory.buildKey(
            model,
            signature,
            width,
            height,
            transformations,
            resourceClass,
            transcodeClass,
            options);

    EngineResource<?> memoryResource;
    synchronized (this) {
        //这里看方法名就能看出，就是从内存中拿资源，这里面就涉及到了glide的缓存，这里没必要深究，之后我会专门出一篇关于Glide缓存的博客去讲解Glide的缓存原理及过程
      memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);
		//如果没有缓存，那么就进行下一步也就是waitForExistingOrStartNewJob
      if (memoryResource == null) {
        return waitForExistingOrStartNewJob(
            glideContext,
            model,
            signature,
            width,
            height,
            resourceClass,
            transcodeClass,
            priority,
            diskCacheStrategy,
            transformations,
            isTransformationRequired,
            isScaleOnlyOrNoTransform,
            options,
            isMemoryCacheable,
            useUnlimitedSourceExecutorPool,
            useAnimationPool,
            onlyRetrieveFromCache,
            cb,
            callbackExecutor,
            key,
            startTime);
      }
    }

    // Avoid calling back while holding the engine lock, doing so makes it easier for callers to
    // deadlock.
    cb.onResourceReady(memoryResource, DataSource.MEMORY_CACHE);
    return null;
  }

Engine#waitForExistingOrStartNewJob

  private <R> LoadStatus waitForExistingOrStartNewJob(
      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,
      Executor callbackExecutor,
      EngineKey key,
      long startTime) {
 //如果缓存中找不到，那么这个任务，会现在磁盘缓存中查找，因为磁盘读取耗时较大，所以放在任务线程中
    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      current.addCallback(cb, callbackExecutor);
      if (VERBOSE_IS_LOGGABLE) {
        logWithTimeAndKey("Added to existing load", startTime, key);
      }
      return new LoadStatus(cb, current);
    }
// 构建出一个EngineJob
    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内部维护的HashMap中
    jobs.put(key, engineJob);
 	// 注册ResourceCallback接口，就是在成功获取图片后，需要显示到ImageView 上的回调，这个接口回调到SingleRequest中
    engineJob.addCallback(cb, callbackExecutor);
   //开始执行
    engineJob.start(decodeJob);

    if (VERBOSE_IS_LOGGABLE) {
      logWithTimeAndKey("Started new load", startTime, key);
    }
    return new LoadStatus(cb, engineJob);
  }

到这里我们应该往哪一部分走呢，其实很明显了，engineJob.start这的命名已经告诉我们要开始了。所以我们点击进去看一下这方法。

EngineJob#start

  public synchronized void start(DecodeJob<R> decodeJob) {
      //这里有两段代码。老规矩，哪一个开始我们就开始
    this.decodeJob = decodeJob;
      //若能从磁盘缓存获取数据，就使用diskCacheExecutor
        //否则在根据其他的条件判断使用哪个Executor
    GlideExecutor executor =
        decodeJob.willDecodeFromCache() ? diskCacheExecutor : getActiveSourceExecutor();
    executor.execute(decodeJob);
  }

DecodeJob#willDecodeFromCache

boolean willDecodeFromCache() {
    Stage firstStage = getNextStage(Stage.INITIALIZE);
    return firstStage == Stage.RESOURCE_CACHE || firstStage == Stage.DATA_CACHE;
  }

private Stage getNextStage(Stage current) {
    switch (current) {
      case INITIALIZE:
            //当前是初始阶段，则看磁盘缓存策略，是否可以在磁盘中获取资源缓存（也就是解析后的缓存）
        return diskCacheStrategy.decodeCachedResource() 
            ? Stage.RESOURCE_CACHE
            : getNextStage(Stage.RESOURCE_CACHE);
      case RESOURCE_CACHE:
            //当前是资源缓存，看下一步能不能从磁盘缓存中获取源数据缓存
        return diskCacheStrategy.decodeCachedData()
            ? Stage.DATA_CACHE
            : getNextStage(Stage.DATA_CACHE);
      case DATA_CACHE:
        // Skip loading from source if the user opted to only retrieve the resource from cache.
        return onlyRetrieveFromCache ? Stage.FINISHED : Stage.SOURCE;
      case SOURCE:
      case FINISHED:
        return Stage.FINISHED;
      default:
        throw new IllegalArgumentException("Unrecognized stage: " + current);
    }
  }

然后执行 executor.execute(decodeJob);这段代码最终执行的是decodeJob里面的run方法，所以接下来我们要分析的是decodeJob的run方法。run方法没什么好讲的，他里面就是调用了runWrapped方法，所以直接看runWrapped方法就好。到这里，我们还没有开始有网络请求，我们目前在做的工作都还只是网络请求前的一些准备工作。好了接着继续看，下面这一段，我任务是是整一个Glide加载流程最难读懂的地方了，这里希望大家认真仔细阅读接下来的这段代码。

DecodeJob#runWrapped

private void runWrapped() {
    //runReason在初始换的时候被赋值为RunReason.INITIALIZE，也就是，第一次会在case:INITIALIZE分支
    switch (runReason) {
        case INITIALIZE:
            //获取下一阶段的状态,这里返回的是Stage.RESOURCE_CACHE
            stage = getNextStage(Stage.INITIALIZE);
			//根据下一阶段状态，判断具体有哪个Generator类执行，这里返回的是ResourceCacheGenerator
            currentGenerator = getNextGenerator();
            runGenerators();
            break;
        case SWITCH_TO_SOURCE_SERVICE:
            runGenerators();
            break;
        case DECODE_DATA:
            decodeFromRetrievedData();
            break;
        default:
            throw new IllegalStateException("Unrecognized run reason: " + runReason);
    }
}
private Stage getNextStage(Stage current) {
    switch (current) {
        case INITIALIZE:
            return diskCacheStrategy.decodeCachedResource()
                ? Stage.RESOURCE_CACHE
                : getNextStage(Stage.RESOURCE_CACHE);
        case RESOURCE_CACHE:
            return diskCacheStrategy.decodeCachedData()
                ? Stage.DATA_CACHE
                : getNextStage(Stage.DATA_CACHE);
        case DATA_CACHE:
            // Skip loading from source if the user opted to only retrieve the resource from cache.
            return onlyRetrieveFromCache ? Stage.FINISHED : Stage.SOURCE;
        case SOURCE:
        case FINISHED:
            return Stage.FINISHED;
        default:
            throw new IllegalArgumentException("Unrecognized stage: " + current);
    }
}
private DataFetcherGenerator getNextGenerator() {
    switch (stage) {
        case RESOURCE_CACHE:
            return new ResourceCacheGenerator(decodeHelper, this);
        case DATA_CACHE:
            return new DataCacheGenerator(decodeHelper, this);
        case SOURCE:
            return new SourceGenerator(decodeHelper, this);
        case FINISHED:
            return null;
        default:
            throw new IllegalStateException("Unrecognized stage: " + stage);
    }
}

综合以上代码，可以知道，getNextStage()返回的状态是RESOURCE_CACHE，所以getNextGenerator()得到的是ResourceCacheGenerator，然后去执行了runGenerators()方法

DecodeJob#runGenerators

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;
        }
    }
    // We've run out of stages and generators, give up.
    if ((stage == Stage.FINISHED || isCancelled) && !isStarted) {
        notifyFailed();
    }

    // Otherwise a generator started a new load and we expect to be called back in
    // onDataFetcherReady.
}

在之前，我们分析过currentGenerator的类型是ResourceCacheGenerator，所以接下来的代码就是ResourceCacheGenerator里面的startNext()方法了

ResourceCacheGenerator#startNext

整体来说这里面的代码比较复杂，而且调用的层次会很深，所以我们这里先跟着代码一步一步走，然后最后整体来看，这段代码做了什么。

 public boolean startNext() {
     //首先这里调用了getCacheKeys(),这里返回的不是空，而是一个GlideUrl结果的列表
    List<Key> sourceIds = helper.getCacheKeys();//注意这段代码会将key保存下来，供下面的一些操作使用
    if (sourceIds.isEmpty()) {
      return false;
    }
     // 获得了三个可以到达的registeredResourceClasses
 	// GifDrawable、Bitmap、BitmapDrawable
    List<Class<?>> resourceClasses = helper.getRegisteredResourceClasses();
    if (resourceClasses.isEmpty()) {
      if (File.class.equals(helper.getTranscodeClass())) {
        return false;
      }
      throw new IllegalStateException(
          "Failed to find any load path from "
              + helper.getModelClass()
              + " to "
              + helper.getTranscodeClass());
    }
    while (modelLoaders == null || !hasNextModelLoader()) {
      resourceClassIndex++;
      if (resourceClassIndex >= resourceClasses.size()) {
        sourceIdIndex++;
        if (sourceIdIndex >= sourceIds.size()) {
            //如果是第一次请求，那么就会在这里返回，后面的就不会去执行了
          return false;
        }
        resourceClassIndex = 0;
      }

      Key sourceId = sourceIds.get(sourceIdIndex);
      Class<?> resourceClass = resourceClasses.get(resourceClassIndex);
      Transformation<?> transformation = helper.getTransformation(resourceClass);
      // PMD.AvoidInstantiatingObjectsInLoops Each iteration is comparatively expensive anyway,
      // we only run until the first one succeeds, the loop runs for only a limited
      // number of iterations on the order of 10-20 in the worst case.
      currentKey =
          new ResourceCacheKey( // NOPMD AvoidInstantiatingObjectsInLoops
              helper.getArrayPool(),
              sourceId,
              helper.getSignature(),
              helper.getWidth(),
              helper.getHeight(),
              transformation,
              resourceClass,
              helper.getOptions());
      cacheFile = helper.getDiskCache().get(currentKey);
      if (cacheFile != null) {
        sourceKey = sourceId;
        modelLoaders = helper.getModelLoaders(cacheFile);
        modelLoaderIndex = 0;
      }
    }

    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);
      loadData =
          modelLoader.buildLoadData(
              cacheFile, helper.getWidth(), helper.getHeight(), helper.getOptions());
      if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {
        started = true;
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
  }

所以说这里第一次ResourceCacheGenerator的startNext()返回的是false，回到上一步也就是DecodeJob#runGenerators中，那么就进入的while循环，然后他又通过getNextGenerator去获取了其他的Generator，这一次获取到的是DataCacheGenerator，所以接下来要调用的就是DataCacheGenerator#startNext方法了

DataCacheGenerator#startNext

public boolean startNext() {
    while (modelLoaders == null || !hasNextModelLoader()) {
      sourceIdIndex++;
      if (sourceIdIndex >= cacheKeys.size()) {
        return false;
      }

      Key sourceId = cacheKeys.get(sourceIdIndex);
      // PMD.AvoidInstantiatingObjectsInLoops The loop iterates a limited number of times
      // and the actions it performs are much more expensive than a single allocation.
      @SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")
      Key originalKey = new DataCacheKey(sourceId, helper.getSignature());
      cacheFile = helper.getDiskCache().get(originalKey);
      if (cacheFile != null) {
        this.sourceKey = sourceId;
        modelLoaders = helper.getModelLoaders(cacheFile);
        modelLoaderIndex = 0;
      }
    }

    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);
      loadData =
          modelLoader.buildLoadData(
              cacheFile, helper.getWidth(), helper.getHeight(), helper.getOptions());
      if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {
        started = true;
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
  }

这里的代码其实就是去缓存里面去寻找文件，如果能找到就直接返回了，那么第一次的话，肯定是找不到的，所以我们直接看最后的SourceGenerator的startNext方法吧

SourceGenerator#startNext

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()) {
        //helper.getLoadData() 获取所有符合条件的ModelLoader，这些ModelLoader 包括默认的和自定义的
           // 这里的符合条件，也就是ModelLoader 中的handles函数是否返回true，再说直白点，就是判断在load()传入的对象类型，是否可以被ModelLoader所处理
        loadData = helper.getLoadData().get(loadDataListIndex++);
        if (loadData != null
            && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
                || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
            started = true;
            //通过LoadData对象内部的 fetcher ，来进行实际的请求操作（例如发起网络请求）
            loadData.fetcher.loadData(helper.getPriority(), this);
        }
    }
    return started;
}

到这里，发现在这里呢还是没有进行一个数据的请求，数据的请求也就是在loadData.fetcher.loadData();这中去进行的，要了解这段里面的代码，我们首先要知道loadData的类型和fetcher的类型，这里分析起来就比较难了，因为它是在ResourceCacheGenerator#startNext里面去做的。这里我们就不详细分析了。因为要弄清楚这些是怎么来的，还得去Glide的构建函数说起，这样就太不利于我们一个整体流程分析的分析了。这里的loadData是MultiModelLoader里面得到的，而他里面有loadData，loadData里面的fetcher类型其实是HttpUrlFetcher 。所以接下来我们要看的地方是HttpUrlFetcher 里面的loadData方法。

HttpUrlFetcher #loadData

@Override
public void loadData(
    @NonNull Priority priority, @NonNull DataCallback<? super InputStream> callback) {
    long startTime = LogTime.getLogTime();
    try {
        // 通过loadDataWithRedirects去请求数据，请求回来的数据，通过callback回调到对应的地方
        InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
        callback.onDataReady(result);
    } catch (IOException e) {
        if (Log.isLoggable(TAG, Log.DEBUG)) {
            Log.d(TAG, "Failed to load data for url", e);
        }
        callback.onLoadFailed(e);
    } finally {
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            Log.v(TAG, "Finished http url fetcher fetch in " + LogTime.getElapsedMillis(startTime));
        }
    }
}
// Glide真正进行网络请求的地方，可以看出Glide使用的是HttpURLConnection来进行网络的请求，这一部分没什么好讲的了，现在就是有数据了。
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();
    // Set the stream so that it's closed in cleanup to avoid resource leaks. See #2352.
    stream = urlConnection.getInputStream();
    if (isCancelled) {
        return null;
    }
    final int statusCode = urlConnection.getResponseCode();
    if (isHttpOk(statusCode)) {
        return getStreamForSuccessfulRequest(urlConnection);
    } else if (isHttpRedirect(statusCode)) {
        String redirectUrlString = urlConnection.getHeaderField("Location");
        if (TextUtils.isEmpty(redirectUrlString)) {
            throw new HttpException("Received empty or null redirect url");
        }
        URL redirectUrl = new URL(url, redirectUrlString);
        // Closing the stream specifically is required to avoid leaking ResponseBodys in addition
        // to disconnecting the url connection below. See #2352.
        cleanup();
        return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
    } else if (statusCode == INVALID_STATUS_CODE) {
        throw new HttpException(statusCode);
    } else {
        throw new HttpException(urlConnection.getResponseMessage(), statusCode);
    }
}

到这里我们终于获取到我们的数据了。可以说，以上就是我们获取数据的一个环节了，接下来有数据之后，我们肯定还是需要对数据进行处理的，所以，接下来的环节就是处理数据的环节了。

首先看loadData.fetcher.loadData(helper.getPriority(), this); 可以看到传入this，this就是callback.onDataReady(result); 语句中的callback， 是 SourceGenerator 的类型。其实就是接口 DataCallback，接下来就看看该接口在SourceGenerator中的实现。看到这里，我们可以说是完成了整一个Glide的请求数据部分了，接下来就是要弄明白，请求回来的数据经过怎样的处理，然后显示到imageView上。现在开始，需要我们一步步’回去‘了，什么意思？就是我们看整一个流程，是一个来，一个回的流程，获取数据这一部分，是一步一步深入的过程，那么得到数据之后，那么肯定就需要我们一步步回去了，看其他框架的源码也是这么一个过程。要记住一点，我们深入的目的是什么，达到了目的之后，需要怎么做。正如那一句话讲的：不要忘记我们出发的目的。

而且思考一个问题，我们获取到对应的数据之后，就能直接显示图片了吗？肯定是不可以的，肯定还是要经过一些列的处理之后，才能将数据转换成我们需要的数据，并经行最终的显示。所以接下来我们要做的就是看Glide是怎么将数据转换成我们需要的数据源，并显示的。

SourceGenerator#onDataReady

@Override
public void onDataReady(Object data) {
    DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
    if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
        dataToCache = data;
        // We might be being called back on someone else's thread. Before doing anything, we should
        // reschedule to get back onto Glide's thread.
        cb.reschedule();
    } else {
        cb.onDataFetcherReady(
            loadData.sourceKey,
            data,
            loadData.fetcher,
            loadData.fetcher.getDataSource(),
            originalKey);
    }
}

我们解读一下onDataReady里面的代码。首先，获取DiskCacheStrategy判断能不能被缓存，这里的判断代码在SourceGenerator.startNext()中出现过，显然是可以的。然后将data保存到dataToCache，并调用cb.reschedule()。
我们在前面分析过，该方法的作用就是将DecodeJob提交到Glide的source线程池中。然后执行DecodeJob.run()方法，经过runWrapped()、 runGenerators()方法后，又回到了SourceGenerator.startNext()方法。

在方法的开头，会判断dataToCache是否为空，此时显然不为空，所以会调用cacheData(Object)方法进行data的缓存处理。缓存完毕后，会为该缓存文件生成一个SourceCacheGenerator。然后在startNext()方法中会直接调用该变量进行加载。

SourceGenerator#startNext

public boolean startNext() {
    //现在是第二次执行到这里
    if (dataToCache != null) {
        Object data = dataToCache;
        dataToCache = null;
        cacheData(data);
    }

    if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
        return true;
    }
    //省略代码
}

private void cacheData(Object dataToCache) {
    long startTime = LogTime.getLogTime();
    try {
        Encoder<Object> encoder = helper.getSourceEncoder(dataToCache);
        DataCacheWriter<Object> writer =
            new DataCacheWriter<>(encoder, dataToCache, helper.getOptions());
        originalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());
        helper.getDiskCache().put(originalKey, writer);

    } finally {
        loadData.fetcher.cleanup();
    }

    sourceCacheGenerator =
        new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);
}

由于在构造DataCacheGenerator时，指定了FetcherReadyCallback为自己，所以DataCacheGenerator加载结果会由SourceGenerator转发给DecodeJob。这里的回调过程是怎么样的呢？如下，

DataCacheGenerator#startNext

->HttpUrlFetcher #loadData

->DataCacheGenerator#onDataReady

->SourceGenerator#onDataFetcherReady
 //这里面就是处理回调的一些过程没什么好讲的，因为很多人看到这里之后不知道下文是怎么来的，这里我把各个回调的过程，以及是怎么回调回来的列一下

这里经过一些回调之后，最终会回调到SourceGenerator的onDataFetcherReady，而这里面调用的是DecodeJob的onDataFetcherReady方法

所以接下来看一下这个方法

DecodeJob#onDataFetcherReady

@Override
public void onDataFetcherReady(
    Key sourceKey, Object data, DataFetcher<?> fetcher, DataSource dataSource, Key attemptedKey) {
    this.currentSourceKey = sourceKey;
    this.currentData = data;
    this.currentFetcher = fetcher;
    this.currentDataSource = dataSource;
    this.currentAttemptingKey = attemptedKey;
    //onDataFetcherReady方法会保存传入的参数，然后确认执行线程后调用`decodeFromRetrievedData()`方法进行解码。
    if (Thread.currentThread() != currentThread) {
        runReason = RunReason.DECODE_DATA;
        callback.reschedule(this);
    } else {
        GlideTrace.beginSection("DecodeJob.decodeFromRetrievedData");
        try {
            decodeFromRetrievedData();
        } finally {
            GlideTrace.endSection();
        }
    }
}

private void decodeFromRetrievedData() {
    //...
        Resource<R> resource = null;
    try {
        //通过decodeFromData去得到resource
        resource = decodeFromData(currentFetcher, currentData, currentDataSource);
    } catch (GlideException e) {
        e.setLoggingDetails(currentAttemptingKey, currentDataSource);
        throwables.add(e);
    }
    if (resource != null) {
        //得到resource之后，调用notifyEncodeAndRelease，这里需要留意一下，因为最终会通过这里将我们得到的resource设置到imageView上
        notifyEncodeAndRelease(resource, currentDataSource);
    } else {
        runGenerators();
    }
}

private <Data> Resource<R> decodeFromData(
    DataFetcher<?> fetcher, Data data, DataSource dataSource) throws GlideException {
    try {
        if (data == null) {
            return null;
        }
        long startTime = LogTime.getLogTime();
        Resource<R> result = decodeFromFetcher(data, dataSource);
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logWithTimeAndKey("Decoded result " + result, startTime);
        }
        return result;
    } finally {
        fetcher.cleanup();
    }
}

private <Data> Resource<R> decodeFromFetcher(Data data, DataSource dataSource)
    throws GlideException {
    LoadPath<Data, ?, R> path = decodeHelper.getLoadPath((Class<Data>) data.getClass());
    return runLoadPath(data, dataSource, path);
}

private <Data, ResourceType> Resource<R> runLoadPath(
    Data data, DataSource dataSource, LoadPath<Data, ResourceType, R> path)
    throws GlideException {
    Options options = getOptionsWithHardwareConfig(dataSource);
    //DataRewinder 之前我们提及过
    DataRewinder<Data> rewinder = glideContext.getRegistry().getRewinder(data);
    try {
        // ResourceType in DecodeCallback below is required for compilation to work with gradle.
        return path.load(
            rewinder, options, width, height, new DecodeCallback<ResourceType>(dataSource));
    } finally {
        rewinder.cleanup();
    }
}

以上这些代码流程放在一起，因为这里面只是保证了一个流程的完整性，代码没什么好讲的，都是一步步的调用。但是有一个地方要注意以下，那就是DataRewinder，这是一个将数据流里面的指针重新指向开头的类，在调用ResourceDecoder对data进行编码时会尝试很多个编码器，所以每一次尝试后都需要重置索引。在Glide初始化的时候默认注入了ByteBufferRewinder和InputStreamRewinder这两个类的工厂。这样就为ByteBuffer和InputStream的重定向提供了实现。还有就是DecodeCallback，这里面其实回调最终还是要回调到DecodeJob对应的代码里面。

LoadPath#load

public Resource<Transcode> load(
    DataRewinder<Data> rewinder,
    @NonNull Options options,
    int width,
    int height,
    DecodePath.DecodeCallback<ResourceType> decodeCallback)
    throws GlideException {
    List<Throwable> throwables = Preconditions.checkNotNull(listPool.acquire());
    try {
        return loadWithExceptionList(rewinder, options, width, height, decodeCallback, throwables);
    } finally {
        listPool.release(throwables);
    }
}

private Resource<Transcode> loadWithExceptionList(
    DataRewinder<Data> rewinder,
    @NonNull Options options,
    int width,
    int height,
    DecodePath.DecodeCallback<ResourceType> decodeCallback,
    List<Throwable> exceptions)
    throws GlideException {
    Resource<Transcode> result = null;
    //对于每条DecodePath，都调用其decode方法，直到有一个DecodePath可以decode出资源。那么我们继续看看DecodePath.decode方法：
    for (int i = 0, size = decodePaths.size(); i < size; i++) {
        DecodePath<Data, ResourceType, Transcode> path = decodePaths.get(i);
        try {
            result = path.decode(rewinder, width, height, options, decodeCallback);
        } catch (GlideException e) {
            exceptions.add(e);
        }
        if (result != null) {
            break;
        }
    }

DecodePath#decode

public Resource<Transcode> decode(
    DataRewinder<DataType> rewinder,
    int width,
    int height,
    @NonNull Options options,
    DecodeCallback<ResourceType> callback)
    throws GlideException {
    Resource<ResourceType> decoded = decodeResource(rewinder, width, height, options);
    Resource<ResourceType> transformed = callback.onResourceDecoded(decoded);
    return transcoder.transcode(transformed, options);
}

这里面只要是三步：

1. 使用ResourceDecoderList进行decode
2. 将decoded的资源进行transform
3. 将transformed的资源进行transcode

DecodePath#decodeResource

@NonNull
private Resource<ResourceType> decodeResource(
    DataRewinder<DataType> rewinder, int width, int height, @NonNull Options options)
    throws GlideException {
    List<Throwable> exceptions = Preconditions.checkNotNull(listPool.acquire());
    try {
        return decodeResourceWithList(rewinder, width, height, options, exceptions);
    } finally {
        listPool.release(exceptions);
    }
}

private Resource<ResourceType> decodeResourceWithList(
    DataRewinder<DataType> rewinder,
    int width,
    int height,
    @NonNull Options options,
    List<Throwable> exceptions)
    throws GlideException {
    Resource<ResourceType> result = null;
    //noinspection ForLoopReplaceableByForEach to improve perf
    for (int i = 0, size = decoders.size(); i < size; i++) {
        ResourceDecoder<DataType, ResourceType> decoder = decoders.get(i);
        try {
            // rewinder是ByteBufferRewind
     		 // data为ByteBuffer
            DataType data = rewinder.rewindAndGet();
            // ByteBufferBitmapDecoder内部会调用Downsampler的hanldes方法
      		// 它对任意的InputStream和ByteBuffer都返回true
            if (decoder.handles(data, options)) {
                data = rewinder.rewindAndGet();
                // 开始解码 decoder是ByteBufferBitmapDecoder
                result = decoder.decode(data, width, height, options);
            }

        } catch (IOException | RuntimeException | OutOfMemoryError e) {
            if (Log.isLoggable(TAG, Log.VERBOSE)) {
                Log.v(TAG, "Failed to decode data for " + decoder, e);
            }
            exceptions.add(e);
        }

        if (result != null) {
            break;
        }
    }

    if (result == null) {
        throw new GlideException(failureMessage, new ArrayList<>(exceptions));
    }
    return result;
}

ByteBufferBitmapDecoder#decode()

@Override
public Resource<Bitmap> decode(
    @NonNull ByteBuffer source, int width, int height, @NonNull Options options)
    throws IOException {
    //先将ByteBuffer转换成InputStream，然后在调用`Downsampler.decode`方法进行解码。
    InputStream is = ByteBufferUtil.toStream(source);
    //downsampler主要是对流进行解码，旋转，压缩，圆角等处理,这里执行完毕之后，就会得到一个BitmapResource对象。然后就一直往上返回，返回到DecodePath.decode方法中。
    return downsampler.decode(is, width, height, options);
}

接下来要执行的就是 callback.onResourceDecoded(decoded);这里调用的是DecodeJob里面的方法

DecodeJob#onResourceDecoded

<Z> Resource<Z> onResourceDecoded(DataSource dataSource, @NonNull Resource<Z> decoded) {
    @SuppressWarnings("unchecked")
    Class<Z> resourceSubClass = (Class<Z>) decoded.get().getClass();
    Transformation<Z> appliedTransformation = null;
    Resource<Z> transformed = decoded;
    if (dataSource != DataSource.RESOURCE_DISK_CACHE) {
        appliedTransformation = decodeHelper.getTransformation(resourceSubClass);
        transformed = appliedTransformation.transform(glideContext, decoded, width, height);
    }
    // TODO: Make this the responsibility of the Transformation.
    if (!decoded.equals(transformed)) {
        decoded.recycle();
    }

    final EncodeStrategy encodeStrategy;
    final ResourceEncoder<Z> encoder;
    if (decodeHelper.isResourceEncoderAvailable(transformed)) {
        // encoder就是BitmapEncoder
        encoder = decodeHelper.getResultEncoder(transformed);
        encodeStrategy = encoder.getEncodeStrategy(options);
    } else {
        encoder = null;
        encodeStrategy = EncodeStrategy.NONE;
    }

    Resource<Z> result = transformed;
    boolean isFromAlternateCacheKey = !decodeHelper.isSourceKey(currentSourceKey);
    if (diskCacheStrategy.isResourceCacheable(
        isFromAlternateCacheKey, dataSource, encodeStrategy)) {
        if (encoder == null) {
            throw new Registry.NoResultEncoderAvailableException(transformed.get().getClass());
        }
        final Key key;
        switch (encodeStrategy) {
            case SOURCE:
                key = new DataCacheKey(currentSourceKey, signature);
                break;
            case TRANSFORMED:
                key =
                    new ResourceCacheKey(
                    decodeHelper.getArrayPool(),
                    currentSourceKey,
                    signature,
                    width,
                    height,
                    appliedTransformation,
                    resourceSubClass,
                    options);
                break;
            default:
                throw new IllegalArgumentException("Unknown strategy: " + encodeStrategy);
        }

        LockedResource<Z> lockedResult = LockedResource.obtain(transformed);
        deferredEncodeManager.init(key, encoder, lockedResult);
        result = lockedResult;
    }
    return result;
}

这一段代码执行完成之后，就回到了回到上面三步的第三步了transformed了，这里的这里的transcoder就是BitmapDrawableTranscoder，该方法返回了一个LazyBitmapDrawableResource。然后接下来怎么走？到这里很多人又迷糊了，现在我们得到了我们想要的资源了，那接下来肯定就是要将这个资源显示出来了。哪一些代码会是显示呢？其实上面我们已经提到过了，在decodeFromRetrievedData中，还有一个方法没有分析，notifyEncodeAndRelease这个方法就是去完成显示的功能的。

DecodeJob#notifyEncodeAndRelease

private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {
      // resource是BitmapResource类型，实现了Initializable接口
    if (resource instanceof Initializable) {
        // initialize方法调用了bitmap.prepareToDraw()
        ((Initializable) resource).initialize();
    }

    Resource<R> result = resource;
    LockedResource<R> lockedResource = null;
    if (deferredEncodeManager.hasResourceToEncode()) {
        lockedResource = LockedResource.obtain(resource);
        result = lockedResource;
    }
	// 资源已经就绪，进行回调，这里面最终会回调到EngineJob的onResourceReady，然后onResourceReady里面调用了notifyCallbacksOfResult
    notifyComplete(result, dataSource);

    stage = Stage.ENCODE;
    try {
        if (deferredEncodeManager.hasResourceToEncode()) {
            deferredEncodeManager.encode(diskCacheProvider, options);
        }
    } finally {
        if (lockedResource != null) {
            lockedResource.unlock();
        }
    }
    // Call onEncodeComplete outside the finally block so that it's not called if the encode process
    // throws.
    onEncodeComplete();
}

EngineJob#notifyCallbacksOfResult

void notifyCallbacksOfResult() {
    ResourceCallbacksAndExecutors copy;
    Key localKey;
    EngineResource<?> localResource;
    synchronized (this) {
        stateVerifier.throwIfRecycled();
        if (isCancelled) {
          
            resource.recycle();
            release();
            return;
        } else if (cbs.isEmpty()) {
            throw new IllegalStateException("Received a resource without any callbacks to notify");
        } else if (hasResource) {
            throw new IllegalStateException("Already have resource");
        }
        engineResource = engineResourceFactory.build(resource, isCacheable, key, resourceListener);
        copy = cbs.copy();
        incrementPendingCallbacks(copy.size() + 1);

        localKey = key;
        localResource = engineResource;
    }
    // 这里的ResourceCallbackAndExecutor就是前面创建EngineJob和DecodeJob
  // 并在执行DecodeJob之前添加的回调
  // entry.executor就是Glide.with.load.into中出现的Executors.mainThreadExecutor()
  // entry.cb就是SingleRequest
    engineJobListener.onEngineJobComplete(this, localKey, localResource);
    for (final ResourceCallbackAndExecutor entry : copy) {
        entry.executor.execute(new CallResourceReady(entry.cb));
    }
    decrementPendingCallbacks();
}

这里，我们需要注意的是CallResourceReady，这是EngineJob的一个内部类，看到这里，我们应该知道这是要就是要去CallResourceReady里面的run方法了

CallResourceReady#run

public void run() {
    // Make sure we always acquire the request lock, then the EngineJob lock to avoid deadlock
    // (b/136032534).
    synchronized (cb.getLock()) {
        synchronized (EngineJob.this) {
            if (cbs.contains(cb)) {
                // Acquire for this particular callback.
                engineResource.acquire();
                callCallbackOnResourceReady(cb);
                removeCallback(cb);
            }
            decrementPendingCallbacks();
        }
    }
}

EngineJob#callCallbackOnResourceReady

void callCallbackOnResourceReady(ResourceCallback cb) {
    try {
        //这里面调用的就是SingleRequest的onResourceReady，他里面会调用它的重载方法onResourceReady(Resource<R> resource, R result, DataSource dataSource)
        cb.onResourceReady(engineResource, dataSource);
    } catch (Throwable t) {
        throw new CallbackException(t);
    }
}

SingleRequest#onResourceReady

注意，这里我们看的是它的重载方法

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;
	//...
    isCallingCallbacks = true;
    try {
        boolean anyListenerHandledUpdatingTarget = false;
         // 尝试调用各个listener的onResourceReady回调进行处理
        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 函数是在buildTarget时创建的  ，buildRequest把target传递进Request中,这个
            target.onResourceReady(result, animation);
        }
    } finally {
        isCallingCallbacks = false;
    }

    notifyLoadSuccess();
}

ImageViewTarget # onResourceReady

@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) {
    //这是一个抽象的方法，会根据不同的实现去调用，我们看一下
    setResource(resource);
    maybeUpdateAnimatable(resource);
}

//BitmapImageViewTarget
protected void setResource(Bitmap resource) {
  view.setImageBitmap(resource);
}

//DrawableImageViewTarget
protected void setResource(@Nullable Drawable resource) {
view.setImageDrawable(resource);
}

到这里整一个Glide的加载流程就全部讲解完毕了，这个流程一看下来确实很长，也花费了我不少时间和心思。毕竟这一篇博客实在是太长了，很少有人能耐心看下去。但是看下去的人肯定对Glide的加载流程有一个很深的映像了。分析整一个流程的时候，我们是忽略了一些细节的，比如说缓存那一块，比如说bitmap优化处理那一块。因为这一些对整一个流程影响不大，所以，这篇博客就先暂时忽略了。Glide的缓存是很重要的一个知识点，所以之后可能还考虑单独出一篇关于Glide缓存的博客。

到这里正文的内容基本也就结束了，但是还是请读者思考几个问题

1. 整一个Glide的流程大体是怎么样的？
2. 如果给你设计一个图片加载库，哪一些流程是必备的，又有哪一些地方是可以优化的？
3. 通过阅读这一篇博客，你收获了什么？