Glide v4 源码解析（六）

这样在我们rebuild代码后，会生成一个 GeneratedAppGlideModuleImpl 类，然后Glide初始化的时候会反射实例化该类，并调用该类的 isManifestParsingEnabled 、 applyOptions 、 registerComponents 方法。
上面的代码中，这三个方法都有默认实现，所以这里的 MyAppGlideModule 也可以这样：

yorek.demoandtest.glide.MyGlideModule 代码如下：

由于现在已经是Glide v4的时代了，所以 GlideModule 已经被标记为 @Deprecated ，顺便接口 RegistersComponents 、 AppliesOptions 也被标记为 @Deprecated 了。且 AppGlideModule 中的 isManifestParsingEnabled 方法就是控制Glide是否需要从 AndroidManifest 中解析 GlideModule 。

在上面的 initializeGlide 方法没有什么难度，注意一下 @GlideModule 注解修饰的类的优先级高于meta-data的配置的类。

下面贴一下反射构造 GeneratedAppGlideModuleImpl 对象的 getAnnotationGeneratedGlideModules() 方法和从 AndroidManifest 中解析meta-data的 ManifestParser 对象：

上面两段代码都很简单，不做过多赘述。
Glide的创建发生在 applyOptions 之后， registerComponents 之后。也好理解，因为 applyOptions 是更改配置，肯定是初始化时就要确定的；而 registerComponents 针对的运行时的功能扩展，而且需要调用 Glide 对象的方法，所以在Glide创建之后调用。

在 initializeGlide 方法的第54行中调用了 builder.build(applicationContext) 方法创建了 Glide 对象。我们看看 GlideBuilder.build 方法：

可以看到， build 方法基本对每一个参数都进行了 null 判断，如果为 null 则使用默认的参数。那么，这些参数什么时候不为空呢？当在 AppliesOptions 接口的实现（也就是各种GlideModule）中通过传入参数 GlideBuilder 来设置后，这里build时就不会为null了。

比如，我们可以在 MyAppGlideModule 中调用 GlideBuilder.setDiskCache 来使 diskCacheFactory 为我们指定的值，下面的代码可以将Glide磁盘缓存位置换到externalCacheDir中。

在AndroidManifest文件中配置好 MyGlideModule 之后，我们先rebuild一下，看一下生成的 GeneratedAppGlideModuleImpl 文件：

代码很简单，属于 AppGlideModule 的三个方法基本都是调用的 MyAppGlideModule 的三个方法。在此基础上，每个 LibraryGlideModule 的 registerComponents 方法都会在 GeneratedAppGlideModuleImpl.registerComponents 方法中被调用。

另外，我们关注一下最后两个方法，这两个方法都是基类 GeneratedAppGlideModule 额外提供了的，代码如下所示：

此时rebuild之后，生成的 GeneratedAppGlideModuleImpl 文件的相关方法如下：

然后在Glide初始化的时候，在方法返回结果set里面的GlideModule将会从集合中移除。

这里为 RequestOptions 扩展了 miniThumb 方法，为 RequestManager 扩展了 asGifTest 方法。所以我们可以这样使用：

注意这里使用的不再是 Glide ，而是 GlideApp 。 GlideApp 是专门用来处理这种扩展API的。

在Glide初始化的时候，会将 GeneratedAppGlideModuleImpl.getRequestManagerFactory() 方法返回的 GeneratedRequestManagerFactory 作为 requestManagerFactory 参数，这样创建 RequestManager 时都会调用 GeneratedRequestManagerFactory.build 方法生成 GlideRequests 。

GlideRequests 继承至 RequestManager ，里面包含了 @GlideType 注解修饰的API：

GlideRequests.java

GlideRequest 则继承至 RequestBuilder ，包含了 @GlideOption 提供的API：

GlideRequest.java

此外，如果需要使用到 RequestOptions ，要使用Generated API生成的 GlideOptions 。

总的来说，如果想使用Generated API，注意一下三个类的关系

• RequestManager -> GlideRequests
• RequestBuilder -> GlideRequest
• RequestOptions -> GlideOptions

OK，理论知识到这为止，下面的两节为 AppGlideModule 的两个方法的应用。

ExternalPreferredCacheDiskCacheFactory 是 ExternalCacheDiskCacheFactory 的替代类。 ExternalCacheDiskCacheFactory 的存储路径为 ${getExternalCacheDir()}/image_manager_disk_cache 。而 ExternalPreferredCacheDiskCacheFactory 的改进在于，如果外置存储不可用，会fallback到内置存储。

我们卸载app后重新运行，并加载图片，然后可以在 ${getExternalCacheDir()}/image_manager_disk_cache 目录下找到缓存的图片了。

sync之后，我们看看 OkHttp3 的library是怎么实现的吧。

根据我们的经验，首先肯定找里面的 @GlideModule 修饰的类，而且应该是一个 LibraryGlideModule 类，library里面文件只有几个，我们一找就找到了 OkHttpLibraryGlideModule 类：

OkHttpLibraryGlideModule.java

BTW，里面还有一个实现了 com.bumptech.glide.module.GlideModule 接口的废弃类 OkHttpGlideModule ：

这个类我们不需要关心，因为使用了上面的 OkHttpLibraryGlideModule ，而且我们也无需在 AndroidManifest.xml 中配置，自然也用不到这个类。

回到 OkHttpLibraryGlideModule 类中，我们看到 registerComponents 方法的实现：

对于此项，Glide的默认配置为：

所以我们可以理解为，原本交给 HttpGlideUrlLoader.Factory() 处理的任务会交给 OkHttpUrlLoader.Factory() 处理。

OkHttpUrlLoader.buildLoadData 方法会返回一个fetcher为 OkHttpStreamFetcher 的 LoadData 。当需要进行加载的时候，会调用fetcher的 loadData 方法：

OkHttpStreamFetcher.java

OkHttpStreamFetcher 的实现比 HttpUrlFetcher 简单多了，而且看起来也没有什么难度。

现在我们清除缓存后重新运行一下，可以在控制台看到请求的log：