Glide源碼解析一，初始化

轉載請標明出處：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導致記憶體抖動）

最後再將上面的緩存池，引擎等作為參數，構建一個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是怎麼監聽圖片的生命周期的。

因為不是運行在主線程，所以最終也都會調用：

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的生命周期進行同步

其它的重載方法類推。