Glide源碼解析一，初始化

轉載請標明出處：https:////www.cnblogs.com/tangZH/p/12409849.html

更多精彩文章：http://77blogs.com/?p=269

 

Glide作為一個強大的圖片加載框架，已經被android官方使用，所以，明白Glide的加載流程以及原理對加深我們對glide的理解是很重要的。

本文基於glide 4.11

Glide.with(this).load("").into(new ImageView(this));

 

我們從這一句入手，先看看Glide的初始化過程，也就是Glide.with(this)這個方法。

一、單例實例化

 

 

可以看到里面有多個重載方法，最常用的是這個，這些方法最終返回的是RequestManager 。

都一致調用了getRetriever(...).get(view)。

 

我們看一下getRetriever(...)里面做了什么。

 如果是在ftragment中調用，要注意fragment還沒有attach之前，不能調用getActivity，否則會返回null

 

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

其它的重載方法類推。

 

總體流程圖：