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(...)里面做了什么，

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

其它的多載方法類推，

標籤：Android

上一篇：Android基于TCP協議的Socket通信簡單實體

下一篇：16.Android-activity生命周期與啟動模式