轉載請標明出處：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"/>

而在Glide4中，提供另外一個配置的模式，那就是註解，並且不再繼承GlideModule，而是繼承AppGlideModule和LibraryGlideModule，分別對應Application和Library，使用@GlideModule註解進行標記。而Glide3.x中的配置方式已經建議放棄使用。

getAnnotationGeneratedGlideModules(context.getApplicationContext());便是獲取Glide註解自動生產的一個Glide的Module配置器，叫做：

GeneratedAppGlideModuleImpl

然後將其作為引數最終傳遞到initializeGlide方法。

 

initializeGlide方法：

 

上面這一段的意思就是：從manifest中解析到我們自定義的GlideModule類，如果判斷與註解生成的類重複，那麼就可以去掉。

annotationGeneratedModule.isManifestParsingEnabled()

判斷是否還支援Glide 3x的在AndroidMenifest.xml中進行指定的方式，預設是返回true，說明現在還是支援的。

 

接著以上程式碼，Glide將逐個呼叫剩下的GlideModule，並回調applyOptions和registerComponents介面，這時，使用者配置的GlideModule就會被呼叫，同時使用者設定的引數也就被配置到Glide中。

 

原始碼中獲取的通過註解生成的GlideModule只有一個，這也說明了我們只能通過註解配置一次。   三、構建Glide Glide glide = builder.build(applicationContext);

 

 

  build方法裡面是對glide的各種配置，比如上面的：

1、載入源資料的執行緒池

2、載入磁碟快取中資料的執行緒池（不能用來載入url網路資料）

3、動畫載入請求器

4、記憶體計算器

5、網路狀態檢測器

6、bitmap快取池（避免不斷不斷建立與回收bitmap導致記憶體抖動）

7、陣列資源快取池 8、記憶體快取，快取完成載入和顯示的圖片資料資源 9、本地磁碟快取，預設儲存在app內部私密目錄   然後建立圖片載入引擎。

 

最後再將上面的快取池，引擎等作為引數，構建一個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的生命週期進行同步

其它的過載方法類推。

 

   

&n