Glide 4.9 源碼分析（一） —— 一次完整加載流程

前言

若想把握 Glide 圖片加載的精髓, 首先要理清 Glide 圖片加載的一次流程

// 這裏即是與 Glide 3+ 的不一樣
RequestOptions options = new RequestOptions()
        .placeholder(R.drawable.loading);
// 它須要一個
Glide.with(this)
     .load(url)
     .apply(options)
     .into(imageView);
複製代碼

好的, 能夠看到 Glide 的使用方式極爲簡單, 但每每越是簡單的背後, 越是隱藏了複雜的實現, 接下來咱們就一步一步的分析 Glide 4.9 的一次加載流程

一. Glide.with

public class Glide implements ComponentCallbacks2 {
    
  public static RequestManager with(@NonNull Context context) {
    // 1. 調用了 getRetriever 獲取一個 RequestManagerRetriever
    // 2. 調用了 RequestManagerRetriever.get 獲取一個 RequestManager 描述一個圖片加載請求的管理者
    return getRetriever(context).get(context);
  }
    
  private static RequestManagerRetriever getRetriever(@Nullable Context context) {
    // 1.1 調用了 Glide.get 獲取 Glide 對象
    // 1.2 經過 Glide 對象獲取一個 RequestManagerRetriever
    // 這個 Retriever 用來獲取一個 RequestManager 對象, 能夠參考 Android Framework 源碼中的 SystemRetriever
    return Glide.get(context).getRequestManagerRetriever();
  }
}
複製代碼

好的, 能夠看到 Glide.with 操做, 主要作了兩件事情

• 經過 Glide.getRetriever 獲取一個 RequestManagerRetriever 對象, 它描述爲請求管理的獲取器
  • 調用 Glide.get 獲取 Glide 對象
  • 調用 Glide.getRequestManagerRetriever, 獲取 RequestManagerRetriever 對象
• 調用 getRequestManagerRetriever.get 獲取一個 RequestManager

接下來咱們一步一步的看, 首先是獲取 RequestManagerRetriever

一) 獲取 RequestManagerRetriever

從上面的分析可只, RequestManagerRetriever 是經過 Glide.getRequestManagerRetriever 獲取到的, 所以須要先獲取 Glide 對象的實例, 所以咱們先看看這個 Glide 是如何構造的

public class Glide implements ComponentCallbacks2 {
    
  private static volatile Glide glide;

  public static Glide get(@NonNull Context context) {
    if (glide == null) {
      synchronized (Glide.class) {
        if (glide == null) {
          checkAndInitializeGlide(context);
        }
      }
    }
    return glide;
  }
  
  private static volatile boolean isInitializing;
  
  private static void checkAndInitializeGlide(@NonNull Context context) {
    if (isInitializing) {
      // 拋出二次初始的異常
    }
    isInitializing = true;
    // 進行初始化操做
    initializeGlide(context);
    isInitializing = false;
  }
  
  private static void initializeGlide(@NonNull Context context) {
    // 建立了一個 GlideBuilder() 實例傳入 initializeGlide, 很顯然是爲了初始化 Glide 對象
    // 接下來咱們就看看它是如何初始化 Glide 的
    initializeGlide(context, new GlideBuilder());
  }

  private static void initializeGlide(@NonNull Context context, @NonNull GlideBuilder builder) {
    Context applicationContext = context.getApplicationContext();
    // 1. 獲取 @GlideModule 註解驅動生成的 GeneratedAppGlideModuleImpl 和 GeneratedAppGlideModuleFactory 類
    GeneratedAppGlideModule annotationGeneratedModule = getAnnotationGeneratedGlideModules();
    ......
    // 2. 嘗試從註解生成的 annotationGeneratedModule 中獲取 RequestManager 的構造工廠對象
    RequestManagerRetriever.RequestManagerFactory factory = annotationGeneratedModule != null
            ? annotationGeneratedModule.getRequestManagerFactory() : null;
    // 3. 向 Glide 的 Builder 中添加這個請求管理器的構造工廠
    builder.setRequestManagerFactory(factory);
    ......
    // 4. 構建 Glide 的實體對象
    Glide glide = builder.build(applicationContext);
    ......
    // 5. 向 Application 中註冊一個組件的回調, 用於檢測系統 Config 改變和內存佔用量低的信號
    applicationContext.registerComponentCallbacks(glide);
    // 保存在靜態的成員變量中
    Glide.glide = glide;
  }
}
複製代碼

好的, 能夠看到 initializeGlide 中, 首先找尋 @GlideModule 註解生成類, 這裏省略了它的實現, 而後將一個 RequestManagerFactory 添加到 GlideBuilder 內部, 以後便構建了一個 Glide 的對象

咱們主要關注一下 Glide 對象建立的過程

public final class GlideBuilder {
  // 管理線程池的引擎
  private Engine engine;
  // 1. 線程池
  private GlideExecutor sourceExecutor;
  private GlideExecutor diskCacheExecutor;
  private GlideExecutor animationExecutor;
  // 2. 內存的緩存策略
  private MemorySizeCalculator memorySizeCalculator;
  private MemoryCache memoryCache;
  // 3. 享元複用池
  private BitmapPool bitmapPool;
  private ArrayPool arrayPool;
  // 4. 磁盤緩存和請求構建工廠
  private DiskCache.Factory diskCacheFactory;
  private RequestManagerFactory requestManagerFactory;
 
  @NonNull
  Glide build(@NonNull Context context) {
    // 1.1 網絡操做使用線程池
    if (sourceExecutor == null) {
      sourceExecutor = GlideExecutor.newSourceExecutor();
    }
    // 1.2 磁盤緩存使用的線程池
    if (diskCacheExecutor == null) {
      diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();
    }
    // 1.3 執行動畫的線程池
    if (animationExecutor == null) {
      animationExecutor = GlideExecutor.newAnimationExecutor();
    }
    // 2.1 描述一個內存的計算器, 智能加載圖片的大小, 判斷其須要的內存空間
    if (memorySizeCalculator == null) {
      memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();
    }
    // 2.2 資源緩存
    if (memoryCache == null) {
      memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
    }
    // 3.1 Bitmap 複用池
    if (bitmapPool == null) {
      int size = memorySizeCalculator.getBitmapPoolSize();
      if (size > 0) {
        bitmapPool = new LruBitmapPool(size);
      } else {
        bitmapPool = new BitmapPoolAdapter();
      }
    }
    // 3.2 數組 複用池
    if (arrayPool == null) {
      arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());
    }
    // 4.1 磁盤緩存的工廠
    if (diskCacheFactory == null) {
      diskCacheFactory = new InternalCacheDiskCacheFactory(context);
    }
    // 4.2 new 了一個 RequestManagerRetriever 對象
    RequestManagerRetriever requestManagerRetriever =  new RequestManagerRetriever(requestManagerFactory);
    // 5. 構建了一個負責管理線程池與緩存的執行引擎
    if (engine == null) {
      engine =
          new Engine(
              memoryCache,
              diskCacheFactory,
              diskCacheExecutor,
              sourceExecutor,
              GlideExecutor.newUnlimitedSourceExecutor(),
              GlideExecutor.newAnimationExecutor(),
              isActiveResourceRetentionAllowed);
    }
    ......
    // 6. 建立了 Glide 對象
    return new Glide(
        context,
        engine,
        memoryCache,
        bitmapPool,
        arrayPool,
        requestManagerRetriever,
        connectivityMonitorFactory,
        logLevel,
        defaultRequestOptions.lock(),
        defaultTransitionOptions,
        defaultRequestListeners,
        ......);
  }
    
}

public class Glide implements ComponentCallbacks2 {
    
  private final Registry registry;

  Glide(......) {
    // 6.1 將 Builder 中的線程池, 緩存池等保存
    this.engine = engine;
    this.bitmapPool = bitmapPool;
    this.arrayPool = arrayPool;
    this.memoryCache = memoryCache;
    this.requestManagerRetriever = requestManagerRetriever;
    this.connectivityMonitorFactory = connectivityMonitorFactory;
    // 6.2 使用 registry 註冊 Glide 須要的 Encoder 與 Decoder
    DecodeFormat decodeFormat = defaultRequestOptions.getOptions().get(Downsampler.DECODE_FORMAT);
    bitmapPreFiller = new BitmapPreFiller(memoryCache, bitmapPool, decodeFormat);
    final Resources resources = context.getResources();
    registry = new Registry();
    registry.register(new DefaultImageHeaderParser());    
    ......
    // 6.3 構建一個 Glide 的上下文
    glideContext =
        new GlideContext(
            context,
            arrayPool,
            registry,
            imageViewTargetFactory,
            defaultRequestOptions,
            defaultTransitionOptions,
            defaultRequestListeners,
            engine,
            isLoggingRequestOriginsEnabled,
            logLevel);
}
複製代碼

好的, 能夠看到 Glide 對象的構建過程異常的複雜, 筆者調整了部分的數據, 它們的流程以下

• 構建線程池
  • 根據不一樣的任務特性, 構建了不一樣的線程池
• 構建內存緩存策略
  • 內存計算器
  • LRU 算法
• 構建對象複用池
• 構建工廠類
  • 建立了一個 RequestManagerRetriever 對象
• 構建 Glide 執行引擎
  • 用於組織線程池和緩存
• 建立 Glide 對象
  • 將 GlideBuilder 中的數據導入
  • 構建一個 registry, 註冊了衆多的編解碼器
  • 構建了一個 GlideContext 對象, 描述其數據資源的上下文

從 Glide 構造的流程中, 能夠看到它主要有五個核心部分, 線程池, 內存緩存策略, 對象複用策略和圖片音視頻的編解碼

在建立 GlideBuilder.build 中, 咱們看到了它 new 了一個 RequestManagerRetriever 對象而且傳遞到了 Glide 對象內部, 因而經過 Glide.getRequestManagerRetriever 就能夠很方便的獲取到 RequestManagerRetriever 這個對象了

獲取到了 RequestManagerRetriever 實例後, 接下來就能夠經過 RequestManagerRetriever.get() 方法獲取 RequestManager 對象了

二) 獲取 RequestManager

public class RequestManagerRetriever implements Handler.Callback {

  public RequestManager get(@NonNull Context context) {
    if (context == null) {
      throw new IllegalArgumentException("You cannot start a load on a null Context");
    } else if (Util.isOnMainThread() && !(context instanceof Application)) {
      // 1. 若在主線程 而且 Context 不爲 Application
      if (context instanceof FragmentActivity) {
        return get((FragmentActivity) context);
      } else if (context instanceof Activity) {
        return get((Activity) context);
      } else if (context instanceof ContextWrapper) {
        // 不斷的查找其 BaseContext, 判斷是否可以與 FragmentActivity/Activity 等目標匹配
        return get(((ContextWrapper) context).getBaseContext());
      }
    } 
    // 2. 若不在 MainThread 或 context 爲 Application 的類型, 則使用 ApplicationManager
    return getApplicationManager(context);
  }
}
複製代碼

能夠看到 RequestManagerRetriever.get 方法會判斷 Context 的類型

• 若在主線程而且不爲 Application 類型的 Context 則找尋其依賴的 Activity
• 若非主線程或爲 Application 類型的 Context, 則使用 ApplicationManager

爲何要優先找到 Activity 呢, 這麼作是何用意呢?, 咱們帶着問題去看看參數爲 Activity 的 get 的重載方法

1. 獲取 Activity 的 RequestManager

public class RequestManagerRetriever implements Handler.Callback { 
    
  public RequestManager get(@NonNull Activity activity) {
    if (Util.isOnBackgroundThread()) {
      // 若非主線程, 直接獲取 Application 類型的 RequestManager
      return get(activity.getApplicationContext());
    } else {
      // 不可在 activity 銷燬時執行加載
      assertNotDestroyed(activity);
      // 獲取其 FragmentManager
      android.app.FragmentManager fm = activity.getFragmentManager();
      return fragmentGet(
          activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
    }
  }
  
  private RequestManager fragmentGet(@NonNull Context context,
      @NonNull android.app.FragmentManager fm,
      @Nullable android.app.Fragment parentHint,
      boolean isParentVisible) {
    // 1. 從 Activity 中獲取一個 RequestManagerFragment, 用於監管 Activity 的聲明週期
    RequestManagerFragment current = getRequestManagerFragment(fm, parentHint, isParentVisible);
    // 2. 獲取 Fragment 中保存的當前頁面的請求管理器 
    RequestManager requestManager = current.getRequestManager();
    // 3. 不存在則建立一個請求管理器保存在 RequestManagerFragment 中
    if (requestManager == null) {
      Glide glide = Glide.get(context);
      requestManager = factory.build(glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
      current.setRequestManager(requestManager);
    }
    // 返回這個請求管理器
    return requestManager;
  }
  
  // 描述一個即將被 FragmentManager 添加的 RequestManagerFragment 緩存
  final Map<android.app.FragmentManager, RequestManagerFragment> pendingRequestManagerFragments =
      new HashMap<>();

  private RequestManagerFragment getRequestManagerFragment(
      @NonNull final android.app.FragmentManager fm,
      @Nullable android.app.Fragment parentHint,
      boolean isParentVisible) {
    // 2.1 嘗試從 FragmentManager 中獲取這個 Fragment
    RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
    // 2.2 不存在則添加一個
    if (current == null) {
      // 2.3 從 pendingRequestManagerFragments 緩存中獲取一個
      current = pendingRequestManagerFragments.get(fm);
      if (current == null) {
        // 2.3.1 建立並更新到緩存
        current = new RequestManagerFragment();
        ......
        // 2.3.2 添加到等待被添加的緩存中
        // 由於添加到 FragmentManager 有延遲, 用這種方式防止同一時間建立了兩個 RequestManagerFragment 對象添加到 Activity 中
        pendingRequestManagerFragments.put(fm, current);
        // 2.3.3 添加到 FragmentManager 中
        fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
        // 2.3.4 添加到 FragmentManager 成功, 經過 Handler 移除這個緩存
        handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
      }
    }
    return current;
  }  
}
複製代碼

好的, 能夠看到 RequestManagerRetriever 的 get 方法主要是在 Activity 頁面中添加一個 RequestManagerFragment 實例, 以便用於監聽 Activity 的生命週期, 而後給這個 Fragment 注入一個 RequestManager, 其處理的細節代碼中也註釋的比較詳細

• 其中有個很是引人注目的細節, 考慮到將 FragmentManger 添加 Fragment 有延遲, 爲了防止同一時間建立了兩個 RequestManagerFragment 添加到 FragmentManager, 所以它使用了 pendingRequestManagerFragments 進行緩存

2. 獲取 Application 的 RequestManager

public class RequestManagerRetriever implements Handler.Callback { 
  
  private volatile RequestManager applicationManager;
  private final RequestManagerFactory factory;
    
  private RequestManager getApplicationManager(@NonNull Context context) {
    // Either an application context or we're on a background thread. if (applicationManager == null) { synchronized (this) { if (applicationManager == null) { Glide glide = Glide.get(context.getApplicationContext()); applicationManager = factory.build(glide, new ApplicationLifecycle(), new EmptyRequestManagerTreeNode(), context.getApplicationContext()); } } } return applicationManager; } } 複製代碼

很簡單構建了一個單例的 RequestManager, 用於處理全部的 context 類型的請求

三) 回顧

至此 Glide.with 操做就完成了, 簡單的回顧一下 with 方法

• 構建 Glide 實例
• 獲取 RequestManagerRetriever 對象
• 構建 RequestManager 對象
  • 若能夠綁定 Activity, 則爲 Activity 添加一個 RequestManagerFragment, 其內部含有 ReqeustManager 對象, 以便後續直接根據 Activity 的生命週期管控 Glide 請求的處理
  • 若非可綁定 Activity, 則獲取一個單例的 applicationManager 專門用於處理這類請求

好的, Glide.with 方法主要是爲 Context 構建其對應的請求管理者, 接下來咱們看看這個 RequestManager.load 方法

二. RequestManager.load

咱們使用最熟悉的加載網絡圖片來分析這個 RequestManager.load 方法

public class RequestManager implements LifecycleListener,
    ModelTypes<RequestBuilder<Drawable>> {
        
  public RequestBuilder<Drawable> load(@Nullable String string) {
    // 1. 調用 asDrawable 建立一個目標爲 Drawable 的圖片加載請求
    // 2. 調用 load 將要加載的資源傳入
    return asDrawable().load(string);
  }
  
  public RequestBuilder<Drawable> asDrawable() {
    return as(Drawable.class);
  }
    
  public <ResourceType> RequestBuilder<ResourceType> as(
      @NonNull Class<ResourceType> resourceClass) {
    return new RequestBuilder<>(glide, this, resourceClass, context);
  }
          
}
複製代碼

好的, 能夠看到 RequestManager.load 方法先調用了 asDrawable 構建一個 RequestBuilder, 描述一個目標資源爲 Drawable 的圖片加載請求

而後調用了 RequestBuilder.load 方法將加載的數據源傳入, 咱們看看這個 load 方法作了什麼

public class RequestBuilder<TranscodeType> extends BaseRequestOptions<RequestBuilder<TranscodeType>>
    implements Cloneable, ModelTypes<RequestBuilder<TranscodeType>> {
        
  public RequestBuilder<TranscodeType> load(@Nullable String string) {
    return loadGeneric(string);
  }
  
  // 描述加載的數據源
  @Nullable private Object model;
  // 描述這個請求是否已經添加了加載的數據源
  private boolean isModelSet;
  
  private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
    this.model = model;
    isModelSet = true;
    return this;
  }

}
複製代碼

好的, 能夠看到走到這裏, RequestBuilder 就構建好了, 接下來就等待執行這個請求了, 咱們看看它的 RequestBuilder 的 into 方法

三. RequestBuilder.into

public class RequestBuilder<TranscodeType> extends BaseRequestOptions<RequestBuilder<TranscodeType>>
    implements Cloneable, ModelTypes<RequestBuilder<TranscodeType>> {
    
  public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
    ......
    // 1. 根據 view 的 scaleType 重構 RequestOptions
    BaseRequestOptions<?> requestOptions = this;// RequestBuilder 直接繼承了 BaseRequestOptions
    if (!requestOptions.isTransformationSet() && requestOptions.isTransformationAllowed() && view.getScaleType() != null) { 
      switch (view.getScaleType()) {
        case CENTER_CROP:
          // 1.1 克隆原 RequestOptions, 配置一個 CenterCrop 的縮放選項
          requestOptions = requestOptions.clone().optionalCenterCrop();
          break;
        ......
      }
    }
    // 2. 調用 into 方法, 建立而且執行請求
    return into(
        glideContext.buildImageViewTarget(view, transcodeClass),
        /*targetListener=*/ null,
        requestOptions,
        Executors.mainThreadExecutor());
  }

}
複製代碼

好的, 能夠看到 into 方法中

• 第一步是根據 ImageView 的 ScaleType 來配置 Options 選項
• 第二步調用了重載方法 into 執行後續構建請求操做

咱們以 CenterCrop 舉例, 看看它如何配置縮放效果

一) 配置 Options

public abstract class BaseRequestOptions<T extends BaseRequestOptions<T>> implements Cloneable { 
    
  public T optionalCenterCrop() {
    // 1. 調用了 optionalTransform
    // DownsampleStrategy 描述降採樣壓縮的策略
    // CenterCrop 描述圖像變化方式
    return optionalTransform(DownsampleStrategy.CENTER_OUTSIDE, new CenterCrop());
  }
  
  final T optionalTransform(@NonNull DownsampleStrategy downsampleStrategy,
      @NonNull Transformation<Bitmap> transformation) {
    ......
    // 2. 將降採樣壓縮策略添加到 options 中
    downsample(downsampleStrategy);
    // 3. 將圖像變化方式添加到 transformations 中
    return transform(transformation, /*isRequired=*/ false);
  }
  
  public T downsample(@NonNull DownsampleStrategy strategy) {
    // 2.1 調用了 set, 將降採樣策略保存到 options 中
    return set(DownsampleStrategy.OPTION, Preconditions.checkNotNull(strategy));
  }
  
  private Options options = new Options();
 
  public <Y> T set(@NonNull Option<Y> option, @NonNull Y value) {
    ...
    // 2.2 添加到 options 緩存中
    options.set(option, value);
    return selfOrThrowIfLocked();
  }
    
  T transform(@NonNull Transformation<Bitmap> transformation, boolean isRequired) {
    // 3.1 調用了 transform 的重載方法, 將這個圖像變化的方式做用到多種資源類型上
    DrawableTransformation drawableTransformation = new DrawableTransformation(transformation, isRequired);
    transform(Bitmap.class, transformation, isRequired);// Bitmap 類型的資源
    transform(Drawable.class, drawableTransformation, isRequired);// Drawable類型的
    ......
    return selfOrThrowIfLocked();
  }
  
  private Map<Class<?>, Transformation<?>> transformations = new CachedHashCodeArrayMap<>();

  <Y> T transform(@NonNull Class<Y> resourceClass, @NonNull Transformation<Y> transformation, boolean isRequired) {
    // 3.2 添加到了 transformations 緩存中
    transformations.put(resourceClass, transformation);
    return selfOrThrowIfLocked();
  }
}
複製代碼

好的, 能夠看到配置縮放選項的操做除了添加了圖像變化操做, 還設定了採樣方式, 分別保存在 transformations 和 options 中

接下來咱們看看請求的構建

二) 構建 Request 請求

public class RequestBuilder<TranscodeType> extends BaseRequestOptions<RequestBuilder<TranscodeType>>
    implements Cloneable, ModelTypes<RequestBuilder<TranscodeType>> {
    
  public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
    ......
    // 2. 調用 into 方法, 建立一個 ViewTarget 對象
    return into(
        // 2.1 調用 GlideContext.buildImageViewTarget 構建一個 ViewTarget
        glideContext.buildImageViewTarget(view, transcodeClass),
        /*targetListener=*/ null,
        requestOptions,
        Executors.mainThreadExecutor());
  }
        
}
複製代碼

能夠看到在調用重載方法 into 以前, 顯示調用了 GlideContext.buildImageViewTarget 構建了一個 ViewTarget

咱們知道 GlideContext 是在 Glide 對象構造時一併建立的, 它是 Context 的裝飾者對象, 在 Application 類型的 Context 中, 添加了 Glide 相關的數據, 咱們先看看它是如何構建 ViewTarget 的

public class GlideContext extends ContextWrapper {
  
  private final ImageViewTargetFactory imageViewTargetFactory;

  public <X> ViewTarget<ImageView, X> buildImageViewTarget(
      @NonNull ImageView imageView, @NonNull Class<X> transcodeClass) {
    // 調用工廠類來建立一個 imageView 的 ViewTarget
    return imageViewTargetFactory.buildTarget(imageView, transcodeClass);
  }
    
}

public class ImageViewTargetFactory {
  @NonNull
  @SuppressWarnings("unchecked")
  public <Z> ViewTarget<ImageView, Z> buildTarget(@NonNull ImageView view, @NonNull Class<Z> clazz) {
    // 根據目標編碼的類型來建立不一樣的 ViewTarget 對象, 由於咱們沒有 asBitmap, 所以這裏爲 Drawable
    if (Bitmap.class.equals(clazz)) {
      return (ViewTarget<ImageView, Z>) new BitmapImageViewTarget(view);
    } else if (Drawable.class.isAssignableFrom(clazz)) {
      return (ViewTarget<ImageView, Z>) new DrawableImageViewTarget(view);
    } else {
      ......
    }
  }
} 
複製代碼

好的能夠看到 GlideContext 中經過工廠類建立了 ImageView 的 ViewTarget 的, 它描述的是圖像處理結束以後, 最終要做用到的 View 目標

構建好了 ViewTarge, 接下來就能夠分析重載的 into 方法了, 看看它是如何構建請求的

public class RequestBuilder<TranscodeType> extends BaseRequestOptions<RequestBuilder<TranscodeType>>
    implements Cloneable, ModelTypes<RequestBuilder<TranscodeType>> {
  
  private <Y extends Target<TranscodeType>> Y into(@NonNull Y target, @Nullable RequestListener<TranscodeType> targetListener,
      BaseRequestOptions<?> options,  Executor callbackExecutor) {
    ......
    // 調用 buildRequest 構建了一個 Glide 請求
    Request request = buildRequest(target, targetListener, options, callbackExecutor);
    ......// 處理這個 ViewTarget 以前的請求與新請求的衝突
    // 給 ViewTarget 設置這個 Glide 請求
    target.setRequest(request);
    // 調用了請求 RequestManager.track 方法執行請求
    requestManager.track(target, request);
    return target;
  }
          
}
複製代碼

好的, 能夠看到調用了 buildRequest 構建了一個 Glide 的請求, 其構建過程也很是有意思, 最終最調用 SingleRequest.obtain 構建一個 Request 的實例對象, 以後即是調用 RequestManager.track 將其分發並執行了

回顧

回顧一下上面的內容, RequestBuilder.into 方法作的事情很是之多

• 根據 ImageView 構建採樣壓縮和圖像變化的策略保存在 Options 和 Transform 中
• 構建 ViewTarget, 描述這個請求要做用的 View 對象
• 構建 Request 請求並執行

四. 獲取數據源

能夠看到請求的分發, 是交由 RequestManager 執行的, 正好與它的命名相符, 起到了管理請求的做用, 接下來咱們看看它的 track 方法是如何分發這個 Request 請求的

public class RequestManager implements LifecycleListener,
    ModelTypes<RequestBuilder<Drawable>> {
  
  private final RequestTracker requestTracker;
    
  synchronized void track(@NonNull Target<?> target, @NonNull Request request) {
    ......
    // 1. 執行請求
    requestTracker.runRequest(request);
  }
            
}

public class RequestTracker {
    
  private final Set<Request> requests =
      Collections.newSetFromMap(new WeakHashMap<Request, Boolean>());
  private final List<Request> pendingRequests = new ArrayList<>();
  
  public void runRequest(@NonNull Request request) {
    requests.add(request);
    if (!isPaused) {
      // 2. 調用 request.begin 執行任務
      request.begin();
    } else {
      ......
    }
  }
  
}

public final class SingleRequest<R> implements Request,
    SizeReadyCallback,
    ResourceCallback,
    FactoryPools.Poolable {
  
  public synchronized void begin() {
    ......
    if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
      // 3. 表示尺寸準備好了
      onSizeReady(overrideWidth, overrideHeight);
    } else {
      ......
    }
    ......
  }
  
  private Engine engine;
  private int width;
  private int height;
  
  public synchronized void onSizeReady(int width, int height) {
    ......
    // 4. 調用了 Engine.load 方法構建任務
    loadStatus = engine.load(......);
    ......
  }
          
}
複製代碼

好的, 能夠看到最終調用到了 onSizeReady 去構建可執行任務, 接下來咱們就分析這一過程

一) 任務的構建

public class Engine implements EngineJobListener,
    MemoryCache.ResourceRemovedListener,
    EngineResource.ResourceListener {
  
  private final Jobs jobs;

  public synchronized <R> LoadStatus load(...) {
    // 1. 根據傳入的參數, 構建這個請求的 key
    EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);
    // 2. 從緩存中查找 key 對應的資源
    // 2.1 嘗試從 ActiveResources 緩存中查找這個 key 的緩存
    EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
      // 若緩存存在, 則直接回調 onResourceReady 處理後續操做
      cb.onResourceReady(active, DataSource.MEMORY_CACHE);
      .......
      return null;
    }
    // 2.2 嘗試從 LruResourceCache 中找尋這個資源 
    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
    if (cached != null) {
      // 回調 onResourceReady 處理後續操做
      cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
      return null;
    }
    // 3. 從緩存中查找 key 對應的任務
    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      // 3.1 走到這裏說明這個任務已經正在執行了, 無需再次構建執行
      current.addCallback(cb, callbackExecutor);
      ......
      // 返回加載狀態便可
      return new LoadStatus(cb, current);
    }
    // 3.2 走到這裏, 說明是一個新的任務
    // 3.2.1 則構建一個新的引擎任務
    EngineJob<R> engineJob = engineJobFactory.build(
            key,
            isMemoryCacheable,
            useUnlimitedSourceExecutorPool,
            useAnimationPool,
            onlyRetrieveFromCache);
    // 3.2.2 構建解碼任務
    DecodeJob<R> decodeJob = decodeJobFactory.build(......, engineJob);
    // 3.2.3 添加到任務緩存
    jobs.put(key, engineJob);
    ......
    // 3.2.4 執行任務
    engineJob.start(decodeJob);
    ......
  }
    
}
複製代碼

好的, 能夠看到 Engine.load 中的事情很是的重要

• 構建這個請求的 key
• 從緩存中查找 key 對應的資源, 若存在直接回 onResourceReady 表示資源準備好了
  • 從 ActiveResources 緩存中查找
  • 從 LruResourceCache 緩存中查找
• 從緩存中查找 key 對應的任務
  • 若存在則說明無需再次獲取資源
  • 構建新的任務
    • 構建引擎任務 EngineJob
    • 引擎的任務爲解碼任務 DecodeJob
    • 將任務添加到緩存, 防止屢次構建
    • 執行任務

好的, 能夠看到內存緩存的處理是在 Engine 中進行的, 若兩個內存緩存都沒有命中, 則會構建任務並執行, 接下來咱們看看任務的執行過程

二) 任務的執行

class EngineJob<R> implements DecodeJob.Callback<R>,
    Poolable {
    
  private final GlideExecutor diskCacheExecutor;  
  private DecodeJob<R> decodeJob;

  public synchronized void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
    // 獲取線程池
    GlideExecutor executor = decodeJob.willDecodeFromCache()
        ? diskCacheExecutor : getActiveSourceExecutor();
    // 執行任務
    executor.execute(decodeJob);
  }
  
}

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
    Runnable,
    Comparable<DecodeJob<?>>,
    Poolable {
    
  @Override      
  public void run() {
     try {
      ......
      // 調用了 runWrapped
      runWrapped();
    } catch (CallbackException e) {
      ......
    }
  }        
  
  private void runWrapped() {
    switch (runReason) {
      case INITIALIZE:
        // 1. 獲取任務的場景
        stage = getNextStage(Stage.INITIALIZE);
        // 2. 獲取這個場景的執行者
        currentGenerator = getNextGenerator();
        // 3. 執行者執行任務
        runGenerators();
        break;
      ......
    }
  }
  
  private Stage getNextStage(Stage current) {
    switch (current) {
      case INITIALIZE:
        // 1.1 若咱們配置的緩存策略容許從 資源緩存 中讀數據, 則返回 Stage.RESOURCE_CACHE
        return diskCacheStrategy.decodeCachedResource()
            ? Stage.RESOURCE_CACHE : getNextStage(Stage.RESOURCE_CACHE);
      case RESOURCE_CACHE:
        // 1.2 若咱們配置的緩存策略容許從 源數據緩存中讀數據, 則返回 Stage.DATA_CACHE
        return diskCacheStrategy.decodeCachedData()
            ? Stage.DATA_CACHE : getNextStage(Stage.DATA_CACHE);
      case DATA_CACHE:
        // 1.3 若只能容許從緩存中獲取數據, 則直接 FINISH, 不然返回 Stage.SOURCE, 意爲加載一個新的資源
        return onlyRetrieveFromCache ? Stage.FINISHED : Stage.SOURCE;
      case SOURCE:
      case FINISHED:
        return Stage.FINISHED;
      default:
        throw new IllegalArgumentException("Unrecognized stage: " + current);
    }
  }
  
  private DataFetcherGenerator getNextGenerator() {
    switch (stage) {
      case RESOURCE_CACHE:
        // 資源磁盤緩存的執行者
        return new ResourceCacheGenerator(decodeHelper, this);
      case DATA_CACHE:
        // 源數據磁盤緩存的執行者
        return new DataCacheGenerator(decodeHelper, this);
      case SOURCE:
        // 無緩存, 獲取數據的源的執行者
        return new SourceGenerator(decodeHelper, this);
      case FINISHED:
        return null;
      default:
        throw new IllegalStateException("Unrecognized stage: " + stage);
    }
  }
  
  private void runGenerators() {
    ......
    boolean isStarted = false;
    // 調用 DataFetcherGenerator.startNext() 執行了請求操做
    while (!isCancelled && currentGenerator != null
        && !(isStarted = currentGenerator.startNext())) {
      // 若
      stage = getNextStage(stage);
      currentGenerator = getNextGenerator();
      if (stage == Stage.SOURCE) {
        reschedule();
        return;
      }
    }
    ......
  }
  
}
複製代碼

DecodeJob 任務執行時, 它根據不一樣的場景, 獲取不一樣的場景執行器, 而後調用了它們的 startNext 方法加載請求任務的數據, 其映射表爲

場景	場景描述	場景執行器
Stage.RESOURCE_CACHE	從磁盤中緩存的資源中獲取數據	ResourceCacheGenerator
Stage.DATA_CACHE	從磁盤中緩存的源數據中獲取數據	DataCacheGenerator
Stage.SOURCE	從新請求數據	SourceGenerator

咱們知道在 Engine 中, 嘗試從內存緩存中獲取資源, 而 DecodeJob 則是嘗試從磁盤緩存中獲取資源, 咱們這裏主要查看 SourceGenerator.startNext 是如何加載請求任務的數據的

三) 獲取源數據

class SourceGenerator implements DataFetcherGenerator,
    DataFetcher.DataCallback<Object>,
    DataFetcherGenerator.FetcherReadyCallback {
  
  private final DecodeHelper<?> helper;
  
  public boolean startNext() {
    ......
    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      // 1. 從 DecodeHelper 的數據加載集合中, 獲取一個數據加載器
      loadData = helper.getLoadData().get(loadDataListIndex++);
      if (loadData != null
          && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
          || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
        started = true;
        // 2. 使用加載器中 fetcher 執行數據加載
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
  }
  
}
複製代碼

好的, SourceGenerator 主要有兩步

• 調用 DecodeHelper.getLoadData 獲取當前請求的數據加載器
• 調用加載器中的 fetcher.loadData 真正的執行數據加載

1. 獲取數據加載器

final class DecodeHelper<Transcode> {
    
  private final List<LoadData<?>> loadData = new ArrayList<>();
  private GlideContext glideContext;
  private Object model;
  private boolean isLoadDataSet;    
  
  List<LoadData<?>> getLoadData() {
    if (!isLoadDataSet) {
      isLoadDataSet = true;
      loadData.clear();
      // 1. 從 Glide 註冊的 register 中獲取請求 model 加載器
      List<ModelLoader<Object, ?>> modelLoaders = glideContext.getRegistry().getModelLoaders(model);
      // 遍歷每個 modelLoaders 
      for (int i = 0, size = modelLoaders.size(); i < size; i++) {
        // 2. 經過 modelLoaders 構建 loadData
        ModelLoader<Object, ?> modelLoader = modelLoaders.get(i);
        LoadData<?> current = modelLoader.buildLoadData(model, width, height, options);
        if (current != null) {
          // 添加到緩存
          loadData.add(current);
        }
      }
    }
    return loadData;
  }  
    
}
複製代碼

它會找到一個 ModelLoader 的實現類, 經過這個實現類的 handles 方法, 判斷是否能夠加載這個 model
這裏咱們的 model 以網絡的 URL 資源舉例, 它的實現類爲 HttpGlideUrlLoader 咱們看看它如何構建一個 LoadData 對象的

public class HttpGlideUrlLoader implements ModelLoader<GlideUrl, InputStream> {
  
  @Nullable private final ModelCache<GlideUrl, GlideUrl> modelCache;
  
  @Override
  public LoadData<InputStream> buildLoadData(@NonNull GlideUrl model, int width, int height,
      @NonNull Options options) {  
    GlideUrl url = model;
    .....
    int timeout = options.get(TIMEOUT);
    // 建立了一個 LoadData 對象, 而且實例化了一個 HttpUrlFetcher 給它
    return new LoadData<>(url, new HttpUrlFetcher(url, timeout));
  }
    
}
複製代碼

好的, 能夠看到對於 URL 的加載, 其 fetcher 爲一個 HttpUrlFetcher 的實例, 接下來咱們看看數據加載的流程

2. 執行數據加載

獲取到了數據加載器以後, SourceGenerator 的 startNext 中便會調用其 fetcher 的 loadData 執行數據的加載了, 咱們結下來便分析一下這個過程

public class HttpUrlFetcher implements DataFetcher<InputStream> {
    
  public void loadData(@NonNull Priority priority,
      @NonNull DataCallback<? super InputStream> callback) {
    long startTime = LogTime.getLogTime();
    try {
      // 獲取網絡圖片, 內部使用了 HttpConnection 實現, 僅僅作了重定向的處理
      InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
      // 將 inputStream 回調出去
      callback.onDataReady(result);
    } catch (IOException e) {
      ......
      callback.onLoadFailed(e);
    } finally {
      ......
    }
  }
    
}
複製代碼

好的, 數據加載的過程也是很簡單的, HttpUrlFetcher 它使用了 HttpConnection 發起了網絡請求, 獲取了數據流, 至此數據資源的獲取就已經完成了, 後面要作的即是最重要的數據處理了, 它經過回調的方式將 InputStream 扔了出去, 最終會回溯到 DecodeJob 的 onDataFetcherReady 這個方法中

四) 流程回顧

走到這裏, 一個請求的數據源獲取就已經完成, 還剩下對數據源的處理操做, 一次 Glide 數據加載就完成了, 咱們先回顧一下此次加載的流程圖

• 優先從 memoryCache 中獲取
  • ActiveResource
  • LruResourceCache
• 次優先從 diskCache 中獲取
  • Resource 資源緩存
  • Data 源數據緩存
• 執行新的加載任務獲取源數據
  • 經過 SourceGenerator 獲取數據
  • 經過 HttpUrlFetcher 獲取網絡數據流

五. 數據源的處理

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
    Runnable,
    Comparable<DecodeJob<?>>,
    Poolable {

  private Key currentSourceKey;
  private Object currentData;
  private DataSource currentDataSource;
  private DataFetcher<?> currentFetcher;
  
  @Override
  public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,
      DataSource dataSource, Key attemptedKey) {
    this.currentSourceKey = sourceKey;  // 保存數據的 key
    this.currentData = data;            // 保存數據實體
    this.currentFetcher = fetcher;      // 保存數據的獲取器
    this.currentDataSource = dataSource;// 數據來源: url 爲 REMOTE 類型的枚舉, 表示從遠程獲取
    ......
    if (Thread.currentThread() != currentThread) {
      ......
    } else {
      try {
        // 調用 decodeFromRetrievedData 解析獲取的數據
        decodeFromRetrievedData();
      } finally {
        ......
      }
    }
  }
  
  private void decodeFromRetrievedData() {
    Resource<R> resource = null;
    try {
      // 1. 調用了 decodeFromData 獲取資源
      resource = decodeFromData(/*HttpUrlFetcher*/currentFetcher, /*InputStream*/currentData,/*REMOTE*/ currentDataSource);
    } catch (GlideException e) {
      ......
    }
    if (resource != null) {
      // 2. 通知外界資源獲取成功了
      notifyEncodeAndRelease(resource, currentDataSource);
    } else {
      ......
    }
  }
  
}
複製代碼

能夠看到對於獲取到的數據, 首先要將其解碼爲 Resource 類型的資源, 而後再將資源返回給上層

咱們先看看它是如何將數據解析成 Resource(非 Android 系統的 Resource) 資源的

一) 資源的獲取

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
    Runnable,
    Comparable<DecodeJob<?>>,
    Poolable {
  
  private <Data> Resource<R> decodeFromData(DataFetcher<?> fetcher, Data data,
      DataSource dataSource) throws GlideException {
    try {
      ......
      // 調用了 decodeFromFetcher
      Resource<R> result = decodeFromFetcher(data, dataSource);
      ......
      return result;
    } finally {
    }
  }
  
  private <Data> Resource<R> decodeFromFetcher(Data data, DataSource dataSource)
      throws GlideException {
    // 1. 獲取當前數據類的解析器 LoadPath
    LoadPath<Data, ?, R> path = decodeHelper.getLoadPath((Class<Data>) data.getClass());
    // 2. 經過解析器來解析來解析數據
    return runLoadPath(data, dataSource, path);
  }
  
  private <Data, ResourceType> Resource<R> runLoadPath(Data data, DataSource dataSource,
      LoadPath<Data, ResourceType, R> path) throws GlideException {
    Options options = getOptionsWithHardwareConfig(dataSource);
    // 2.1 根據數據類型獲取一個數據重造器, 獲取的數據爲 InputStream, 所以它是一個 InputStreamRewinder 的實例
    DataRewinder<Data> rewinder = glideContext.getRegistry().getRewinder(data);
    try {
      // 2.2 將解析資源的任務轉移到了 LoadPath.load 方法中
      return path.load( rewinder, options, width, height, new DecodeCallback<ResourceType>(dataSource));
    } finally {
      rewinder.cleanup();
    }
  }        
}
複製代碼

能夠看到爲了解析數據, 首先構建了一個 LoadPath, 而後建立了一個 InputStreamRewinder 類型的 DataRewinder, 最終將數據解析的操做到了 LoadPath.load 方法中

接下來看看這個LoadPath.load 作了哪些處理

public class LoadPath<Data, ResourceType, Transcode> {
 
 public Resource<Transcode> load(DataRewinder<Data> rewinder, @NonNull Options options, int width,
      int height, DecodePath.DecodeCallback<ResourceType> decodeCallback) throws GlideException {
    ......
    try {
      return loadWithExceptionList(rewinder, options, width, height, decodeCallback, throwables);
    } finally {
      ......
    }
  }

  private final List<? extends DecodePath<Data, ResourceType, Transcode>> decodePaths;
  
  private Resource<Transcode> loadWithExceptionList(DataRewinder<Data> rewinder,
      @NonNull Options options, int width, int height, DecodePath.DecodeCallback<ResourceType> decodeCallback,
      List<Throwable> exceptions) throws GlideException {
    Resource<Transcode> result = null;
    // 遍歷內部存儲的 DecodePath 集合, 經過他們來解析數據
    for (int i = 0, size = decodePaths.size(); i < size; i++) {
      DecodePath<Data, ResourceType, Transcode> path = decodePaths.get(i);
      try {
        // 調用 DecodePath.decode 真正進行數據的解析
        result = path.decode(rewinder, width, height, options, decodeCallback);
      } catch (GlideException e) {
        ......
      }
      ......
    }
    return result;
  }
      
}

public class DecodePath<DataType, ResourceType, Transcode> {
    
  public Resource<Transcode> decode(DataRewinder<DataType> rewinder, int width, int height,
      @NonNull Options options, DecodeCallback<ResourceType> callback) throws GlideException {
    // 1. 調用 decodeResource 將源數據解析成中間資源
    Resource<ResourceType> decoded = decodeResource(rewinder, width, height, options);
    // 2. 調用 DecodeCallback.onResourceDecoded 處理中間資源
    Resource<ResourceType> transformed = callback.onResourceDecoded(decoded);
    // 3. 調用 ResourceTranscoder.transcode 將中間資源轉爲目標資源
    return transcoder.transcode(transformed, options);
  }
  
  private Resource<ResourceType> decodeResource(DataRewinder<DataType> rewinder, int width,
      int height, @NonNull Options options) throws GlideException {
    try {
      // 1.1 調用了 decodeResourceWithList
      return decodeResourceWithList(rewinder, width, height, options, exceptions);
    } finally {
      ......
    }
  }

  @NonNull
  private Resource<ResourceType> decodeResourceWithList(DataRewinder<DataType> rewinder, int width,
      int height, @NonNull Options options, List<Throwable> exceptions) throws GlideException {
    Resource<ResourceType> result = null;
    for (int i = 0, size = decoders.size(); i < size; i++) {
      ResourceDecoder<DataType, ResourceType> decoder = decoders.get(i);
      try {
        DataType data = rewinder.rewindAndGet();
        if (decoder.handles(data, options)) {
          data = rewinder.rewindAndGet();
          // 1.2 調用 ResourceDecoder.decode 解析源數據
          result = decoder.decode(data, width, height, options);
        }
      } 
      ......
      if (result != null) {
        break;
      }
    }
    return result;
  }
    
}
複製代碼

能夠看到數據解析的任務最重是經過 DecodePath 來執行的, 它內部有三個操做

• 調用 decodeResource 將源數據解析成資源
  • 源數據: InputStream
  • 中間產物: Bitmap
• 調用 DecodeCallback.onResourceDecoded 處理資源
• 調用 ResourceTranscoder.transcode 將資源轉爲目標資源
  • 目標資源類型: Drawable

1. 解析源數據

由於本次流程的源數據爲 InputStream 所以它的解析器爲 StreamBitmapDecoder

public class StreamBitmapDecoder implements ResourceDecoder<InputStream, Bitmap> {

  private final Downsampler downsampler;
  
  public Resource<Bitmap> decode(@NonNull InputStream source, int width, int height,
      @NonNull Options options)
      throws IOException {
    ......
    try {
      // 根據請求配置的數據, 對數據流進行採樣壓縮, 獲取到一個 Resource<Bitmap>
      return downsampler.decode(invalidatingStream, width, height, options, callbacks);
    } finally {
      ......
    }
  }
    
}
複製代碼

能夠看到它內部經過 Downsampler.decode 方法對數據流進行採樣壓縮, 來獲取這個流的 Bitmap

• 這個採樣的策略就是咱們在構建 Request 時傳入的, 其採樣壓縮的細節, 並非咱們本次關注的重點

咱們看看獲取到了 Resource 以後, 如何處理這個資源

2. 資源的處理

能夠看到, 當咱們將源數據解析成對應的資源以後, 便會調用 DecodeCallback.onResourceDecoded 處理資源, 咱們看看它的處理過程

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
    Runnable,
    Comparable<DecodeJob<?>>,
    Poolable {
    
  private final class DecodeCallback<Z> implements DecodePath.DecodeCallback<Z> {

    @Override
    public Resource<Z> onResourceDecoded(@NonNull Resource<Z> decoded) {
      // 調用了外部類的 onResourceDecoded 方法
      return DecodeJob.this.onResourceDecoded(dataSource, decoded);
    }
    
  }
  
  private final DeferredEncodeManager<?> deferredEncodeManager = new DeferredEncodeManager<>();

  <Z> Resource<Z> onResourceDecoded(DataSource dataSource,
      @NonNull Resource<Z> decoded) {
    // 1. 獲取數據資源的類型
    Class<Z> resourceSubClass = (Class<Z>) decoded.get().getClass();
    Transformation<Z> appliedTransformation = null;
    Resource<Z> transformed = decoded;
    
    // 2. 若非從資源磁盤緩存中獲取的數據源, 則對資源進行 transformation 操做
    if (dataSource != DataSource.RESOURCE_DISK_CACHE) {
      appliedTransformation = decodeHelper.getTransformation(resourceSubClass);
      transformed = appliedTransformation.transform(glideContext, decoded, width, height);
    }
    ......
    // 3. 構建數據編碼的策略
    final EncodeStrategy encodeStrategy;
    final ResourceEncoder<Z> encoder;
    if (decodeHelper.isResourceEncoderAvailable(transformed)) {
      encoder = decodeHelper.getResultEncoder(transformed);
      encodeStrategy = encoder.getEncodeStrategy(options);
    } else {
      encoder = null;
      encodeStrategy = EncodeStrategy.NONE;
    }
    // 4. 根據編碼策略, 構建緩存的 key
    Resource<Z> result = transformed;
    boolean isFromAlternateCacheKey = !decodeHelper.isSourceKey(currentSourceKey);
    if (diskCacheStrategy.isResourceCacheable(isFromAlternateCacheKey, dataSource,
        encodeStrategy)) {
      ......
      final Key key;
      switch (encodeStrategy) {
        case SOURCE:
          // 源數據的 key
          key = new DataCacheKey(currentSourceKey, signature);
          break;
        case TRANSFORMED:
          // 資源數據的 key
          key =
              new ResourceCacheKey(......);
          break;
        default:
          throw new IllegalArgumentException("Unknown strategy: " + encodeStrategy);
      }
      // 5. 初始化編碼管理者, 用於提交內存緩存
      LockedResource<Z> lockedResult = LockedResource.obtain(transformed);
      deferredEncodeManager.init(key, encoder, lockedResult);
      result = lockedResult;
    }
    // 返回 transform 以後的 bitmap
    return result;
  }
        
}
複製代碼

能夠看到 onResourceDecoded 中, 主要是對中間資源作了以下的操做

• 對資源進行 transformed 操做
  • 將資源轉爲目標效果, 如在構建 request 時, 設置的 CenterCrop
• 構建磁盤緩存的 key

好的, 這個方法執行結束以後, 這個資源就與咱們指望的效果一致了, 接下來只須要將它轉爲目標格式就能夠展現了

3. 將數據轉爲目標格式

目標數據爲 Drawable, 所以它的轉換器爲 BitmapDrawableTranscoder

public class BitmapDrawableTranscoder implements ResourceTranscoder<Bitmap, BitmapDrawable> {

  private final Resources resources;

  @Nullable
  @Override
  public Resource<BitmapDrawable> transcode(@NonNull Resource<Bitmap> toTranscode,
      @NonNull Options options) {
    // 調用了 LazyBitmapDrawableResource.obtain 獲取 Resource<BitmapDrawable> 的實例對象
    return LazyBitmapDrawableResource.obtain(resources, toTranscode);
  }
  
}

public final class LazyBitmapDrawableResource implements Resource<BitmapDrawable>,
    Initializable {

  public static Resource<BitmapDrawable> obtain(
      @NonNull Resources resources, @Nullable Resource<Bitmap> bitmapResource) {
    ......
    // 建立了一個 LazyBitmapDrawableResource
    return new LazyBitmapDrawableResource(resources, bitmapResource);
  }
  
  private LazyBitmapDrawableResource(@NonNull Resources resources,
      @NonNull Resource<Bitmap> bitmapResource) {
    this.resources = Preconditions.checkNotNull(resources);
    this.bitmapResource = Preconditions.checkNotNull(bitmapResource);
  }
  
  public BitmapDrawable get() {
    // Get 方法反回了一個 BitmapDrawable 對象
    return new BitmapDrawable(resources, bitmapResource.get());
  }

}
複製代碼

好的, 轉化成目標數據也很是的簡單, 它將咱們解析到的 bitmap 存放到 LazyBitmapDrawableResource 內部, 而後外界經過 get 方法就能夠獲取到一個 BitmapDrawable 的對象了

4. 解碼轉換的結構圖

二) 數據的展現

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
    Runnable,
    Comparable<DecodeJob<?>>,
    Poolable {
    
  private void decodeFromRetrievedData() {
    Resource<R> resource = null;
    ......// 解析 inputStream 獲取資源 
    if (resource != null) {
      // 通知外界資源獲取成功了
      notifyEncodeAndRelease(resource, currentDataSource);
    } else {
      ......
    }
  }
  
  private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {
    ......
    // 1. 回調上層資源準備好了
    notifyComplete(result, dataSource);
    ......
    try {
      // 2. 將數據緩存到磁盤
      if (deferredEncodeManager.hasResourceToEncode()) {
        deferredEncodeManager.encode(diskCacheProvider, options);
      }
    } finally {
      ...
    }
  }
  
  private Callback<R> callback;
  
  private void notifyComplete(Resource<R> resource, DataSource dataSource) {
    ......
    // 1.1 從 DecodeJob 的構建中, 咱們知道這個 Callback 是一 EngineJob
    callback.onResourceReady(resource, dataSource);
  }
  
}
複製代碼

好的, 能夠看到 DecodeJob.decodeFromRetrievedData 中, 主要作了兩個操做

• 回調 EngineJob.onResourceReady 資源準備好了
• 將數據緩存到磁盤

磁盤緩存並不是咱們關注的終點, 這裏咱們看看 EngineJob.onResourceReady 中作了哪些處理

class EngineJob<R> implements DecodeJob.Callback<R>,
    Poolable {

  @Override
  public void onResourceReady(Resource<R> resource, DataSource dataSource) {
    synchronized (this) {
      this.resource = resource;
      this.dataSource = dataSource;
    }
    notifyCallbacksOfResult();
  } 
  
  void notifyCallbacksOfResult() {
    ResourceCallbacksAndExecutors copy;
    Key localKey;
    EngineResource<?> localResource;
    synchronized (this) {
      ......
      engineResource = engineResourceFactory.build(resource, isCacheable);
      hasResource = true;
      copy = cbs.copy();
      incrementPendingCallbacks(copy.size() + 1);

      localKey = key;
      localResource = engineResource;
    }
    // 1. 通知上層 Engine 任務完成了
    listener.onEngineJobComplete(this, localKey, localResource);
    // 2. 回調給 ImageViewTarget 展現資源
    for (final ResourceCallbackAndExecutor entry : copy) {
      entry.executor.execute(new CallResourceReady(entry.cb));
    }
  }
    
}

複製代碼

好的, EngineJob 中也是有兩步操做, 一個是通知上層任務完成了, 另外一個是回調給 ImageViewTarget 展現資源

咱們先看看上層作了什麼處理

public class Engine implements EngineJobListener,
    MemoryCache.ResourceRemovedListener,
    EngineResource.ResourceListener {
  
  public synchronized void onEngineJobComplete(
      EngineJob<?> engineJob, Key key, EngineResource<?> resource) {
    if (resource != null) {
      // 將加載好的資源添加到內存緩存
      if (resource.isCacheable()) {
        activeResources.activate(key, resource);
      }
    }
    ......
  }
     
}
複製代碼

咱們知道在請求發起前是 Engine 嘗試經過內存緩存讀, 結束以後再回到 Engine 添加內存緩存也不足爲奇了

接下來咱們看看 ImageViewTarget 展現資源的過程

public abstract class ImageViewTarget<Z> extends ViewTarget<ImageView, Z>
    implements Transition.ViewAdapter {

  public void onResourceReady(@NonNull Z resource, @Nullable Transition<? super Z> transition) {
    // 處理一些 transition 變化, 在構建 Request 時有分析過, 這裏不贅述其實現細節了
    if (transition == null || !transition.transition(resource, this)) {
      setResourceInternal(resource);
    } else {
      ......
    }
  }
  
  private void setResourceInternal(@Nullable Z resource) {
    // 調用了 setResource
    setResource(resource);
    ......
  }
 
}

public class DrawableImageViewTarget extends ImageViewTarget<Drawable> {
    
  protected void setResource(@Nullable Drawable resource) {
    // 呈現到 View 上
    view.setImageDrawable(resource);
  }  
    
}
複製代碼

ImageViewTarget 調用了子類重寫的 setResource 方法, 將數據填充進去, 至此一次 Glide 圖像加載就完成了

三) 流程回顧

六. 總結

經過一次流程分析咱們得知, 整個 Glide 圖片加載主要有以下幾步

• 請求管理器的構建
  • 一個 Context 對應一個 RequestManager
• 請求的構建
  • 請求的寬高、採樣的方式、transform 變化...
• 經過請求獲取資源
  • Engine 從內存緩存中查找
    • 從 ActiveResources 緩存中查找
    • 從 LruResourceCache 緩存中查找
  • 內存緩存不存在, 則構建任務執行
    • 構建一個 EngineJob 描述一個請求任務, 任務類型爲 DecodeJob
      • DecodeJob 從 diskCache 中查找
      • diskCache 不存在, 則經過網絡請求, 獲取數據源
      • 經過 Downsampler 解析源數據並進行採樣壓縮獲取 Bitmap
      • 對 Bitmap 進行 transform 處理
        • 構建磁盤緩存的 key
      • 將 transform 以後的 Bitmap 轉爲 Resource 回傳給上層
        • DecodeJob 進行磁盤緩存
  • Engine 對資源進行內存緩存
• 傳遞給 View 進行展現

看了 Glide 的加載流程, 我彷佛可以明白爲何他是 Google 推薦的圖片加載框架了, 內部細節的處理作的很是的到位, 並且使用 GlideContext 用於描述 Glide 的上下文, 與 Android 的 Context 巧妙的融合在一塊兒, 讀起來真有一種閱讀 Android 源碼的既視感

不過這只是最簡單的流程, 並且 Glide 支持 Gif, 視頻加載操做, 可想而知其內部的 Decorder 處理了多少邏輯代碼, 如此複雜的流程, 嵌套了如此之多的回調, 無疑增長了咱們閱讀源碼的難度, 如果將這些操做分層, 而且使用攔截器去實現, 我想定會讓一次圖像加載操做變得更加清晰明瞭

若想了解 Glide 採樣壓縮獲取 Bitmap 的實現詳情， 請查看下面這篇文章 juejin.im/post/5ca5c8…