Glide源碼解析一，初始化
- 2020 年 3 月 5 日
- 筆記
轉載請標明出處：https:////www.cnblogs.com/tangZH/p/12409849.html
Glide作為一個強大的圖片載入框架，已經被android官方使用，所以，明白Glide的載入流程以及原理對加深我們對glide的理解是很重要的。
本文基於glide 4.11
Glide.with(this).load("").into(new ImageView(this));
我們從這一句入手，先看看Glide的初始化過程，也就是Glide.with(this)這個方法。
一、單例實例化
可以看到裡面有多個重載方法，最常用的是這個，這些方法最終返回的是RequestManager 。
都一致調用了getRetriever(…).get(view)。
我們看一下getRetriever(…)裡面做了什麼。
getRequestManagerRetriever()返回的是一個RequestManagerRetriever，我們主要看的是Glide.get(context)
可以看到Glide.get(context)裡面進行了初始化的操作，它是我們熟悉的單例模式。最終會調用
二、GlideModule配置載入
上面的get方法中，我們需要注意這一句：
GeneratedAppGlideModule annotationGeneratedModule = getAnnotationGeneratedGlideModules(context.getApplicationContext());
點進去可以看到關鍵部分的程式碼為
Glide提供給我們自定義載入組件的方式，在Glide 3x中，我們首先會定義一個繼承於GlideModule的類，然後在項目的AndroidMenifest.xml中進行指定：
<meta-data android:name="com.test.GlideConfiguration" android:value="GlideModule"/>
getAnnotationGeneratedGlideModules(context.getApplicationContext());便是獲取Glide註解自動生產的一個Glide的Module配置器，叫做：
GeneratedAppGlideModuleImpl
然後將其作為參數最終傳遞到initializeGlide方法。
initializeGlide方法：
上面這一段的意思就是：從manifest中解析到我們自定義的GlideModule類，如果判斷與註解生成的類重複，那麼就可以去掉。
annotationGeneratedModule.isManifestParsingEnabled()
判斷是否還支援Glide 3x的在AndroidMenifest.xml中進行指定的方式，默認是返回true，說明現在還是支援的。
build方法裡面是對glide的各種配置，比如上面的：
1、載入源數據的執行緒池
2、載入磁碟快取中數據的執行緒池（不能用來載入url網路數據）
3、動畫載入請求器
4、記憶體計算器
5、網路狀態檢測器
6、bitmap快取池（避免不斷不斷創建與回收bitmap導致記憶體抖動）
7、數組資源快取池
最後再將上面的快取池，引擎等作為參數，構建一個Glide
這個構造函數非常長，我們只挑一些重點的來講，其它的可以類推：
1、創建各種decoder，也就是解碼器，比如：
ByteBufferGifDecoder byteBufferGifDecoder = new ByteBufferGifDecoder(context, imageHeaderParsers, bitmapPool, arrayPool);
將ByteBuffer解碼為GifDrawable。
ResourceDrawableDecoder resourceDrawableDecoder = new ResourceDrawableDecoder(context);
將資源uri解碼為Drawable
2、創建各種factory，即模型裝換器，比如：
ResourceLoader.StreamFactory resourceLoaderStreamFactory = new ResourceLoader.StreamFactory(resources);
將Android資源ID轉換為Uri，在載入成為InputStream
ResourceLoader.UriFactory resourceLoaderUriFactory = new ResourceLoader.UriFactory(resources);
將資源ID轉換為Uri
3、創建各種Transcoder，即轉碼器，比如
BitmapBytesTranscoder bitmapBytesTranscoder = new BitmapBytesTranscoder();
將Bitmap轉碼為Byte arrays
GifDrawableBytesTranscoder gifDrawableBytesTranscoder = new GifDrawableBytesTranscoder();
將將GifDrawable轉碼為Byte arrays
4、創建各種encoder，即編碼器，比如：
BitmapEncoder bitmapEncoder = new BitmapEncoder(arrayPool);
將Bitmap數據快取為File
5、註冊：
如上面，註冊將Byte數據快取為File的編碼器，註冊將InputStream快取為File的編碼器。將ByteBuffer解碼為Bitmap的解碼器，將inputStreams解碼為Bitmap的編碼器。
四、生命周期管理。
getRetriever(activity).get(activity);中的getRetriever(activity)方法講解完了，接下來講get方法，大家就能知道glide是怎麼監聽圖片的生命周期的。
同樣的，get方法也有多個重載方法，方法裡面檢測，如果是運行在後台執行緒，那都會調用下面這個方法：
因為不是運行在主執行緒，所以最終也都會調用：
getApplicationManager(context)，創建一個RequestManager，生命周期與application的一樣。
而如果不是運行在後台執行緒的話，那麼重載方法裡面的參數不同，執行的方法也就不同，我且看這一個：
public RequestManager get(@NonNull Activity activity)
傳遞的參數是activity，那麼生命周期應該與Activity一樣。
我們點進去fragmentGet方法：
可以看到它首先獲取RequestManagerFragment，這其實就是一個fragment，然後獲取與之綁定的RequestManager，如果獲取不到就說明還沒綁定，那麼就去構建一個RequestManager，然後與RequestManagerFragment進行綁定。而在構建RequestManager的時候，傳進去了一個current.getGlideLifecycle()，這個是Glide的生命周期，可以看出生命周期的管理是在RequestManager中的。那怎麼實現與activity的生命周期同步呢？
接下來就要看看getRequestManagerFragment(fm, parentHint, isParentVisible);這個方法做了什麼。
首先通過tag去找activity中有沒有存在對應的fragment，找不到的話就去pendingRequestManagerFragments 這個map中看有沒有，還沒有的話就去初始化一個RequestManagerFragment。
再將fragment添加到activity中。
pendingRequestManagerFragments的作用：
pendingRequestManagerFragments是為了防止重複添加fragment。因為add方法來添加fragment並不會立即執行，而是被加入任務隊列中。它有相關的生命周期是非同步進行的，所以如果add之後立馬又在相同fragment或者activity環境中調用get方法，那麼就很有可能又創建一個新的RequestManagerFragment，所以用pendingRequestManagerFragments在add任務完成前攔截其他的添加操作，在完成後發送消息移除。
if (isParentVisible) { current.getGlideLifecycle().onStart(); }
如果父布局可見，也就是activity可見，那麼開始生命周期的start回調。
在RequestManagerFragment裡面可以看到，fragment的生命周期進行回調的時候就會調用glide自定義的生命周期lifecycle的相應方法。
也就是說glide是通過往activity中添加fragment，然後監聽fragment的生命周期來控制glide的生命周期進行同步
其它的重載方法類推。
