先說前面分析的 Glide 的 with 方法，返回的是 RequestManager 對(duì)象，但實(shí)際上經(jīng)過 GlideApp 的包裝，被轉(zhuǎn)型成了 GlideReuqests 對(duì)象。

public static RequestManager with(@NonNull FragmentActivity activity) {
    return getRetriever(activity).get(activity);
}
public static GlideRequests with(@NonNull FragmentActivity activity) {
    return (GlideRequests) Glide.with(activity);
}

GlideRequests 繼承自 RequestManager，是通過 APT 生成的類，這里面包括了我們通過注解擴(kuò)展出的功能方法，但默認(rèn)沒有擴(kuò)展的情況下，其實(shí)它就等價(jià)于 RequestManager。

這樣子的話就明確了 load 方法是 GlideRequests 提供的，

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

通過調(diào)用父類的方法，將返回結(jié)果轉(zhuǎn)型為 GlideRequest<Drawable>。

public RequestBuilder<Drawable> load(@Nullable String string) {
    return asDrawable().load(string);
}
public RequestBuilder<Drawable> asDrawable() {
    return as(Drawable.class);
}
public <ResourceType> RequestBuilder<ResourceType> as(Class<ResourceType> resourceClass) {
    return new RequestBuilder<>(glide, this, resourceClass, context);
}

調(diào)用 asDrawable 方法來獲取一個(gè) RequestBuilder 對(duì)象，RequestBuilder 是個(gè)泛型類，支持多種資源類型，例如 File, Bitmap, Gif，在這里是通過 as-xxx 方法表現(xiàn)的，但最終都會(huì)通過 as 這個(gè)泛型方法來實(shí)現(xiàn)。

這個(gè)泛型方法的泛型命名為 ResourceType，其實(shí)和我們平時(shí)用的 T，K，V 這種一樣，只不過這種更明顯知道用意（這點(diǎn)是我們寫泛型方法，泛型類的時(shí)候可以借鑒的）。

protected RequestBuilder(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());
}

逐行看下，

glide 就是 Glide 對(duì)象，requestManager 就是 RequestManager 對(duì)象。

transcodeClass 這里就以 Drawable.class 類對(duì)象為例，對(duì)應(yīng)的 TranscodeType 就是這個(gè)泛型類定義的泛型。

context 就是 Activity 對(duì)象。這里要區(qū)分一下 Glide 對(duì)象里也有 context 屬性，它是通過 getApplicationContext 方法獲取的，RequestManager 對(duì)象里的 context 屬性是 Activity 類型，所以這里的 context 就是 Activity 類型。

transitionOptions 是通過 RequestManager 對(duì)象獲取到的一個(gè)默認(rèn)形變選項(xiàng)？經(jīng)過簡單的層層分析，這個(gè)來源是通過 GlideBuilder 進(jìn)行配置的，在默認(rèn)情況下這會(huì)是初始化對(duì)象。

glideContext 定義為 Glide 的全局上下文，繼承自 ContextWrapper，看這內(nèi)容還挺多，這里知道它比較重要就行。

initRequestListeners 方法要做的事情同 transitionOptions，默認(rèn)情況下也是一個(gè)初始化對(duì)象。

最后一行代碼的調(diào)用是為了配置 RequestOptions，這個(gè)值依然是通過 RequestManager，在 GlideContext 里是通過工廠方法創(chuàng)建返回給 RequestManager 對(duì)象的，而這個(gè)工廠對(duì)象的實(shí)現(xiàn)是在 Glide 對(duì)象的創(chuàng)建過程中賦值的，因?yàn)槭?Builder 模式，在沒有配置的情況下，可以看下 GlideBuilder 里有沒有默認(rèn)初始值，果然在 GlideBuilder 里有默認(rèn)的實(shí)現(xiàn)，

private RequestOptionsFactory defaultRequestOptionsFactory =
    new RequestOptionsFactory() {
      @NonNull
      @Override
      public RequestOptions build() {
        return new RequestOptions();
      }
};

這樣一來，RequestBuilder<Drawable> 對(duì)象就有了，同 GlideApp, Glide 的關(guān)系一樣，RequestBuilder 和 GlideRequest 也是這么一對(duì)。

所以 load 方法就最終返回了 GlideRequest<Drawable> 對(duì)象。

對(duì)比 Picasso，Glide 的這兩個(gè)方法調(diào)用邏輯和 Picasso 大體上有些類似。

//獲取到了 Picasso 對(duì)象
Picasso.get();
//Picasso 對(duì)象調(diào)用獲取到 RequestCreator
Picasso.load(url);

//創(chuàng)建 Glide 對(duì)象，并獲取到了 RequestManager(GlideRequests) 對(duì)象
GlideApp.with();
//GlideRequests(RequestManager) 對(duì)象調(diào)用獲取到 GlideRequest
GlideRequests.load();

圖片請(qǐng)求加載過程可以認(rèn)為有這么幾步，1. 創(chuàng)建外觀類（Picasso, Glide 類）對(duì)象，2. 創(chuàng)建請(qǐng)求管理者，3. 創(chuàng)建請(qǐng)求并發(fā)起請(qǐng)求，4. 處理結(jié)果。對(duì)比 Picasso 和 Glide，雖然類似，但還是有區(qū)別，總體來看，Picasso 的前兩步更像是 Glide 的第一步，即 創(chuàng)建請(qǐng)求管理者，Picasso 的第三步會(huì)創(chuàng)建請(qǐng)求并發(fā)起，而 Glide 則將創(chuàng)建請(qǐng)求和發(fā)起請(qǐng)求做了拆分，創(chuàng)建請(qǐng)求 對(duì)應(yīng)著 Glide 的第二步。