在Android開發(fā)過程中，加載圖片是日常開發(fā)中最普通的操作了，市面上也有很多的優(yōu)秀圖片處理框架，如開源組織Square出品的Picasso，Android Universal Image Loader，Glide等，但是到現(xiàn)在最常用的，強大的開源框架是Glide.也是Google官網(wǎng)推薦使用的圖片處理框架。所以在這里對Glide進行分析。
本系列分為幾個步驟進行解析：從Glide最簡單的使用來看：
? ? ? ? ? ? ? ? ? ? ?Glide.with(this).load(R.drawable.ic_launcher_background).into(ivPic);
我分為三個步驟：
第一步：with()------------------------->?生命周期管理，空白的Fragment管理
第二步：load()-------------------------> 構(gòu)建出RequestBuilder對象等(后面文章再細(xì)講)
第三步：into()------------------------->1.運行隊列，等待隊列 ? 2.活動緩存，內(nèi)存緩存 3.網(wǎng)絡(luò)模型(后面文章再細(xì)講)
因為這三個方法我覺得是Glide的精髓部分，就是這三個方法構(gòu)成了整個加載圖片的體系，用戶使用起來，可能覺得很簡單，但是在方法背后是有成堆的代碼去維護它，解析這個框架的確是有難度的。
本文目錄:
1.Glide的使用。
2.Glide的with()源碼分析。
3.仿照源碼手寫一個Glide的with()調(diào)用流程。
4.總結(jié)。
一.Glide的使用：
第一步：引入(app?module)
第二步：在代碼中使用
第三步：顯示的效果:
以上幾步是Glide最簡單也是最重要的應(yīng)用，這里就不多說了。
二.Glide的with()源碼分析：
在這里要抓住主線：with主要是感知生命周期，按照正常流程來說，我們使用一次Glide就得釋放一次Glide的內(nèi)存：
這個操作給用戶來說是存在不確定性因素的，所以在這里進行感知生命周期，自己去完成一系列的操作。
Glide是怎么監(jiān)聽生命周期的呢？
簡述：一個Activity有onStart()方法和onStop等生命周期方法，然后Glide搞了一個空白的Fragment進去，當(dāng)執(zhí)行onStrat的時候或者onStop都會被感知。RequestManager 會接收到onStart和onStop的請求。去通知Glide的其他類。比如ImageViewTarget .當(dāng)Glide進行請求的時候，用戶把頁面銷毀了，則在ImageViewTarget通過onStop就可以把所有正在請求的任務(wù)全部停止了。
從with進入：會跳轉(zhuǎn)到Glide類，記住with里的參數(shù)如果是從Actiivty進入的就是Activity的環(huán)境(具體分析是從哪里進入的，則對應(yīng)相應(yīng)的環(huán)境)。：
可以看到有多個重載的方法，參數(shù)對應(yīng)不同的環(huán)境
我們選擇一個看：with(Context)
發(fā)現(xiàn)不管中間經(jīng)歷了什么最后一定是返回RequestManager。
從getRetriever()進入：
發(fā)現(xiàn)它返回的是RequestManagerRetriever。（調(diào)用RequestManagerRetriever的get方法去返回RequestManager）
從get()進入：跳轉(zhuǎn)到RequestManagerRetriever類，我覺得它是管理RequestManager的類
在這里引入一個作用域的問題，其實這個作用域在上面已經(jīng)講到過了。分析上面一段代碼 ：?
第114行：判斷是否在主線程中，并且上下文環(huán)境如果是Application則直接跳到124行。
第124行進入：
可以發(fā)現(xiàn)沒有添加任何的fragment,在這里可以得出一個結(jié)論：如果不是在主線程中，并且上下問環(huán)境如果是Application就不用感知生命周期了，也就不需要添加空白的Fragment了。
如果是從主線程中進入，并且上下文環(huán)境不是Application,則我們選一行進行分析，其他一致，比如傳入的環(huán)境是FragmentActivity則進入：
第115行：照樣進行判斷如果是子線程，則走上面一樣的方法，不是進入else
上面代碼可以看到增加了一個fragement.證實上述驗證是正確的。
總結(jié)：1.子線程 Application作用域不會搞空白的Fragment
? ? ? ? ? ? 2.主線程 非Application作用域會弄一個空白的Fragment監(jiān)聽
接下來我們要進入那個空白的Fragment進行分析，因為要看一下它是怎么感知生命周期的
上述代碼可以看到SupportRequestManagerFragment就是空白的Fragment，這里可能對應(yīng)的包不一樣，空白的Fragment也就不一樣，但是總體的流程代碼是一樣的，所以這里只分析這個SupportRequestManagerFragment。
進入SupportRequestManagerFragment：會發(fā)現(xiàn)沒有任何的ui只有這幾個重要的回調(diào)：lifecycle其實就是ActivityFragmentLifecycle的實例，先記住。
到這里會發(fā)現(xiàn)都是通過lifecycle發(fā)送通知的。
不得不去分析一下lifecycle ：是一個接口：?
它由以下類進行調(diào)用，很清晰的發(fā)現(xiàn)，是activity/fragment的就給ActivityFragmentLifecycle 是application或者子線程就給ApplicationLifecycle
在上面的分析中有一個這樣的截圖：
看畫紅線的地方這是子線程或者上下文環(huán)境是Application進入的：
發(fā)現(xiàn)它只是在注冊的時候會啟動onStart()方法，但是注銷確沒做任何事，這是因為它是跟著app的生命周期進行活動的。只要app啟動了，就會走onStart()方法，app銷毀了，則Glide的自然也就銷毀了。
來看看ActivityFragmentLifecycle：這是面向某個頁面的生命周期：
在removeListener 和?addListener中 ?發(fā)現(xiàn)還有一個接口，我們都是操作這個接口LifecycleListener：
現(xiàn)在可以連起來了：
在空白的fragemnt感知到onStart()或者相關(guān)生命周期后：lifecycle實際上就是：ActivityFragmentLifecycle
會調(diào)用到ActivityFragmentLifecycle的onStart();這個onStart()并不是接口的onStart()，而是代碼寫的onStart();?
隨后會對LifecycleListener的onStart()進行調(diào)用.主要是遍歷這個集合();
而前面提到要返回的RequestManager實現(xiàn)了這個接口的LifecycleListener，所以調(diào)用后會給通知到RequestManager，RequestManager再繼續(xù)向有關(guān)方法發(fā)送相關(guān)業(yè)務(wù)的指令。
RequestManager大概源碼精簡了的：
流程總結(jié)：
1.空白Fragment感知到Activity的生命周期變化后，會進行調(diào)用ActivityFragmentLifecycle的onStart()方法，
2.進而會調(diào)用Set<LifecycleListener> 這個集合：遍歷調(diào)用LifecycleListener 的相關(guān)三個方法
3.通知RequestManager去通知相關(guān)類(比如ImageViewTarget）做相關(guān)業(yè)務(wù)。
至此with()的大概流程操作至此結(jié)束。
三.仿照源碼手寫一個Glide的with()調(diào)用流程。
1.首先先寫完Glide(仿照):?
2.RequestManagerRetriever:
3.RequestManager
4.Lifecycle?
5.LifecycleListener
6.ActivityFragmentLifecycle
7.ApplicationLifecycle
8.SupportRequestManagerFragment
代碼至此完成，調(diào)用查看打?。?/b>
當(dāng)進入頁面的時候:
當(dāng)退出頁面的時候:
對于為什么先執(zhí)行onStop的問題：
可以看到注冊之后，isStarted,isDestroyed都是false.
四.總結(jié)
Glide的源碼非常龐大，所以要分析源碼，把握住主線即可，看每個方法的主要功能是什么，比如with主要是跟生命周期的問題。那就圍繞著這個問題去分析，流程打通，就可以了。
