一 、with()
1、Glide 直接調(diào)用 with 方法，說(shuō)明此with方法是靜態(tài)的； Glide類(lèi)源碼中，對(duì)于with方法的重載種類(lèi)，有五種;Context 、Activity 、FragmentActivity android.app.Fragment 、 android.app.Fragment。其實(shí)每一個(gè)with方法的重載的代碼都非常簡(jiǎn)單，都是先 調(diào)用都是先調(diào)用RequestManagerRetriever的靜態(tài)get()方法得到一個(gè)RequestManagerRetriever對(duì)象，這個(gè)靜 態(tài)get()方法就是一個(gè)單例實(shí)現(xiàn)，沒(méi)什么需要解釋的。然后再調(diào)用RequestManagerRetriever的實(shí)例get()方法 ，去獲取RequestManager對(duì)象。 現(xiàn)在主要講activity的. 調(diào)用 with 方法 的時(shí)候，返回了一個(gè)RequestManager，而RequestManager 是通過(guò) RequestManagerRetriver 來(lái)獲得的。附上源碼：
????????public tatic RequestManager with(Activity activity) {?
?????????????RequestManagerRetriever retriever =RequestManagerRetriever.get();
? ? ? ? ? ? ? ? ?return retriever.get(activity);?
?????????}
2、對(duì)于RequestManagerRetriver這個(gè)類(lèi)，在這個(gè)類(lèi)當(dāng)中，我們還是主要看 activity的get()方法。 附上源碼：?
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
public RequestManager get(Activity activity) { if (Util.isOnBackgroundThread() ||?
????Build.VERSION.SDK_INT= Build.VERSION_CODES.JELLY_BEAN_MR1 &&
????activity.isDestroyed()) {
????throw new IllegalArgumentException("You cannot start a load for a destroyed
????activity");
????}
}
@TargetApi(Build.VERSION_CODES.HONEYCOMB)
????RequestManager fragmentGet(Context context, android.app.FragmentManager fm) {
????????RequestManagerFragment current = getRequestManagerFragment(fm);
????????RequestManager requestManager = current.getRequestManager();
????????if (requestManager == null) {
????????equestManager = new RequestManager(context, current.getLifecycle(), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?current.getRequestManagerTreeNode());
????????current.setRequestManager(requestManager);
????????}
? ? ?return requestManager;
}
根據(jù)此段源碼，我們可以分析出 如果你當(dāng)前是處于后臺(tái)或者 android phone版本小于3.0，那么就直接走傳入Applcation對(duì)象的get()方法；else這塊我們可以看出，assertNotDestroyed()這個(gè)方法主要是對(duì)當(dāng)前的activity進(jìn)行一次是否存在的判斷，而后則創(chuàng)建了一個(gè)自定義且沒(méi)有界面的Fragment，那么這里為什么要添加一個(gè)隱藏的Fragment呢？因?yàn)镚lide需要知道加載的生命周期。很簡(jiǎn)單的一個(gè)道理，如果你在某個(gè)Activity上正在加載著一張圖片，結(jié)果圖片還沒(méi)加載出來(lái)，Activity就被用戶關(guān)掉了，那么圖片還應(yīng)該繼續(xù)加載嗎？當(dāng)然不應(yīng)該。可是Glide并沒(méi)有辦法知道Activity的生命周期，于是Glide就使用了添加隱藏Fragment的這種小技巧，因?yàn)镕ragment的生命周期和Activity是同步的，如果Activity被銷(xiāo)毀了，F(xiàn)ragment是可以監(jiān)聽(tīng)到的，這樣Glide就可以捕獲這個(gè)事件并停止圖片加載了。
調(diào)用getApplicationManager()方法來(lái)獲取一個(gè)RequestManager對(duì)象。其實(shí)這是最簡(jiǎn)單的一種情況，因?yàn)锳pplication對(duì)象的生命周期即應(yīng)用程序的生命周期，因此Glide并不需要做什么特殊的處理，它自動(dòng)就是和應(yīng)用程序的生命周期是同步的，如果應(yīng)用程序關(guān)閉的話，Glide的加載也會(huì)同時(shí)終止。(此處源碼進(jìn)行省略，有想了解的請(qǐng)自行下載源碼)
這里額外再提一句，如果我們是在非主線程當(dāng)中使用的Glide，那么不管你是傳入的Activity還是Fragment，都會(huì)被強(qiáng)制當(dāng)成Application來(lái)處理。不過(guò)其實(shí)這就屬于是在分析代碼的細(xì)節(jié)了，本篇文章我們將會(huì)把目光主要放在Glide的主線工作流程上面，后面不會(huì)過(guò)多去分析這些細(xì)節(jié)方面的內(nèi)容。
總體來(lái)說(shuō)，第一個(gè)with()方法的源碼還是比較好理解的。其實(shí)就是為了得到一個(gè)RequestManager對(duì)象而已，然后Glide會(huì)根據(jù)我們傳入with()方法的參數(shù)來(lái)確定圖片加載的生命周期，并沒(méi)有什么特別復(fù)雜的邏輯。
