先說前面分析的 Glide 的 with 方法蕾额，返回的是 RequestManager 對象，但實際上經(jīng)過 GlideApp 的包裝酷勺，被轉型成了 GlideReuqests 對象单料。
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 生成的類握础，這里面包括了我們通過注解擴展出的功能方法辐董，但默認沒有擴展的情況下，其實它就等價于 RequestManager禀综。
這樣子的話就明確了 load 方法是 GlideRequests 提供的简烘，
public GlideRequest<Drawable> load(@Nullable String string) {
return (GlideRequest<Drawable>) super.load(string);
}
通過調(diào)用父類的方法苔严，將返回結果轉型為 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 方法來獲取一個 RequestBuilder 對象孤澎，RequestBuilder 是個泛型類届氢，支持多種資源類型，例如 File, Bitmap, Gif亥至，在這里是通過 as-xxx 方法表現(xiàn)的悼沈，但最終都會通過 as 這個泛型方法來實現(xiàn)。
這個泛型方法的泛型命名為 ResourceType姐扮，其實和我們平時用的 T絮供，K，V 這種一樣茶敏，只不過這種更明顯知道用意（這點是我們寫泛型方法壤靶，泛型類的時候可以借鑒的）。
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 對象贮乳，requestManager 就是 RequestManager 對象。
transcodeClass 這里就以 Drawable.class 類對象為例恬惯，對應的 TranscodeType 就是這個泛型類定義的泛型向拆。
context 就是 Activity 對象。這里要區(qū)分一下 Glide 對象里也有 context 屬性酪耳，它是通過 getApplicationContext 方法獲取的浓恳，RequestManager 對象里的 context 屬性是 Activity 類型，所以這里的 context 就是 Activity 類型碗暗。
transitionOptions 是通過 RequestManager 對象獲取到的一個默認形變選項颈将？經(jīng)過簡單的層層分析，這個來源是通過 GlideBuilder 進行配置的言疗，在默認情況下這會是初始化對象晴圾。
glideContext 定義為 Glide 的全局上下文，繼承自 ContextWrapper噪奄，看這內(nèi)容還挺多死姚，這里知道它比較重要就行。
initRequestListeners 方法要做的事情同 transitionOptions勤篮，默認情況下也是一個初始化對象知允。
最后一行代碼的調(diào)用是為了配置 RequestOptions，這個值依然是通過 RequestManager叙谨，在 GlideContext 里是通過工廠方法創(chuàng)建返回給 RequestManager 對象的，而這個工廠對象的實現(xiàn)是在 Glide 對象的創(chuàng)建過程中賦值的保屯，因為是 Builder 模式手负，在沒有配置的情況下涤垫，可以看下 GlideBuilder 里有沒有默認初始值，果然在 GlideBuilder 里有默認的實現(xiàn)竟终，
private RequestOptionsFactory defaultRequestOptionsFactory =
new RequestOptionsFactory() {
@NonNull
@Override
public RequestOptions build() {
return new RequestOptions();
}
};
這樣一來蝠猬，RequestBuilder<Drawable> 對象就有了，同 GlideApp, Glide 的關系一樣统捶，RequestBuilder 和 GlideRequest 也是這么一對榆芦。
所以 load 方法就最終返回了 GlideRequest<Drawable> 對象。
對比 Picasso喘鸟，Glide 的這兩個方法調(diào)用邏輯和 Picasso 大體上有些類似匆绣。
//獲取到了 Picasso 對象
Picasso.get();
//Picasso 對象調(diào)用獲取到 RequestCreator
Picasso.load(url);
//創(chuàng)建 Glide 對象，并獲取到了 RequestManager(GlideRequests) 對象
GlideApp.with();
//GlideRequests(RequestManager) 對象調(diào)用獲取到 GlideRequest
GlideRequests.load();
圖片請求加載過程可以認為有這么幾步什黑，1. 創(chuàng)建外觀類（Picasso, Glide 類）對象崎淳，2. 創(chuàng)建請求管理者，3. 創(chuàng)建請求并發(fā)起請求愕把，4. 處理結果拣凹。對比 Picasso 和 Glide，雖然類似恨豁，但還是有區(qū)別嚣镜，總體來看，Picasso 的前兩步更像是 Glide 的第一步橘蜜，即 創(chuàng)建請求管理者菊匿，Picasso 的第三步會創(chuàng)建請求并發(fā)起，而 Glide 則將創(chuàng)建請求和發(fā)起請求做了拆分扮匠，創(chuàng)建請求 對應著 Glide 的第二步捧请。
