Glide原理分析(二)：Engine加载流程

上一篇文章《Glide原理解析（一）：加载流程分析》主要大致地分析了Glide加载图片的整体流程，这一篇主要解决的上一篇遗留的一个问题：

Glide Engine 如何加载图片，内部涉及到Glide的缓存模块

上篇文章在SingleRequest中获取到了ViewTarget的宽高之后(假定是ImageView)，onSizeReady()调用了engine的load()方法

loadStatus = engine.load(
        glideContext,
        model,
        requestOptions.getSignature(),
        this.width,
        this.height,
        requestOptions.getResourceClass(),
        transcodeClass,
        priority,
        requestOptions.getDiskCacheStrategy(),
        requestOptions.getTransformations(),
        requestOptions.isTransformationRequired(),
        requestOptions.isScaleOnlyOrNoTransform(),
        requestOptions.getOptions(),
        requestOptions.isMemoryCacheable(),
        requestOptions.getUseUnlimitedSourceGeneratorsPool(),
        requestOptions.getUseAnimationPool(),
        requestOptions.getOnlyRetrieveFromCache(),
        this);

在看Engine的load()方法之前，先看下Engine主要的数据结构

private final Jobs jobs;
负责缓存EngineJob的管理类

private final EngineKeyFactory keyFactory;
负责创建缓存的key

private final DecodeJobFactory decodeJobFactory;
负责创建DecodeJob, DecodeJob负责从缓存或原始资源解码转换

private final EngineJobFactory engineJobFactory;
负责创建EngineJob，EngineJob负责处理DecodeJob的加载结果

private final ResourceRecycler resourceRecycler;
当资源被移除或者释放时，负责回收资源（可能是被回收到其他的LruCache中去）

private final MemoryCache cache;
内部是LruCache缓存

private final LazyDiskCacheProvider diskCacheProvider;
内部是DiskLruCache缓存

private final ActiveResources activeResources;
内部是弱引用缓存，当前活跃的缓存资源

看完了上面的数据结构，开始load()加载资源

// Engine.java
public <R> LoadStatus load(
      GlideContext glideContext,
      Object model,
      Key signature,
      int width,
      int height,
      Class<?> resourceClass,
      Class<R> transcodeClass,
      Priority priority,
      DiskCacheStrategy diskCacheStrategy,
      Map<Class<?>, Transformation<?>> transformations,
      boolean isTransformationRequired,
      boolean isScaleOnlyOrNoTransform,
      Options options,
      boolean isMemoryCacheable,
      boolean useUnlimitedSourceExecutorPool,
      boolean useAnimationPool,
      boolean onlyRetrieveFromCache,
      ResourceCallback cb) {
    // 根据图像类型、原始宽高、目标宽高、转换等各种因素创建一个Key
    EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);

    // 从当前活跃资源里面获取
    EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
      // 获取成功，直接回调返回
      cb.onResourceReady(active, DataSource.MEMORY_CACHE);
      return null;
    }
    // 从LruCache资源获取
    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
    if (cached != null) {
      // 获取成功，直接回调返回
      cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
      return null;
    }

    // 从DiskLruCache资源获取
    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      // 获取成功，需要进一步转码
      current.addCallback(cb);
      return new LoadStatus(cb, current);
    }

    EngineJob<R> engineJob =
        engineJobFactory.build(
            key,
            isMemoryCacheable,
            useUnlimitedSourceExecutorPool,
            useAnimationPool,
            onlyRetrieveFromCache);

    DecodeJob<R> decodeJob =
        decodeJobFactory.build(
            glideContext,
            model,
            key,
            signature,
            width,
            height,
            resourceClass,
            transcodeClass,
            priority,
            diskCacheStrategy,
            transformations,
            isTransformationRequired,
            isScaleOnlyOrNoTransform,
            onlyRetrieveFromCache,
            options,
            engineJob);
            
    // 添加engineJob到jobs中管理
    jobs.put(key, engineJob);

    engineJob.addCallback(cb);
    // 开始加载
    engineJob.start(decodeJob);

    return new LoadStatus(cb, engineJob);
  }

在开始看engineJob如何加载之前，先看下一个问题：

一般来说我们都是使用LruCache和DiskLruCache作为缓存，为什么Glide还用上了弱引用缓存？

如果你仔细的看你可以注意到从LruCache加载资源方法，有些奇怪：

private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
    ...
    // 从LruCache获取资源
    EngineResource<?> cached = getEngineResourceFromCache(key);
    if (cached != null) {
      cached.acquire();
      // 加入到activeResources弱引用
      activeResources.activate(key, cached);
    }
    return cached;
  }

  private EngineResource<?> getEngineResourceFromCache(Key key) {
    // 从LruCache获取资源,并且移除它
    Resource<?> cached = cache.remove(key);
    ...
    return result;
  }

相信你看到了，从LruCache获取资源并将它移除，加入到弱引用缓存中。后面终于想清楚了：

LruCache是有容量限制的，比如说设定10个，那么当前活跃图片如果有8个，那么LruCache其中有8个是当前活跃图片，2个缓存之前使用过的图片。

加入了弱引用缓存以后，LruCache可以缓存10个之前使用过的图片，并且因为弱引用的特性，不会复制副本，占据内存。

在不增加缓存内存容量限制的情况下，弱引用缓存极大地增大了Glide的命中率。

继续看engineJob.start(decodeJob)

// EngineJob.java
  public void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
    // 根据是否从缓存加载选定不同的线程池
    GlideExecutor executor = decodeJob.willDecodeFromCache()
        ? diskCacheExecutor
        : getActiveSourceExecutor();
    // 加入到线程池中，继续到decodeJob.run()
    executor.execute(decodeJob);
  }

注释写得蛮清楚，继续到DecodeJob.run()

// DecodeJob.java
  public void run() {
    ...
      runWrapped();
    ...
  }

  private void runWrapped() {
    switch (runReason) {
      case INITIALIZE:
        // 首次获取
        stage = getNextStage(Stage.INITIALIZE);
        currentGenerator = getNextGenerator();
        runGenerators();
        break;
      case SWITCH_TO_SOURCE_SERVICE:
        // 从获取Disk资源失败重新获取
        runGenerators();
        break;
      case DECODE_DATA:
        // 获取资源成功
        decodeFromRetrievedData();
        break;
      default:
        throw new IllegalStateException("Unrecognized run reason: " + runReason);
    }
  }
  
  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);
    }
  }

在runWrapped中还使用了状态者模式，对应有三种资源：
Data: 原始的图片缓存数据
Resource： 经过处理的图片缓存数据（例如旋转裁剪转换）
Source：无缓存数据

代码会依次走DataCacheGenerator、ResourceCacheGenerator、SourceGenerator，如果一个无法处理就传递给下一个Generator。

这里假定是首次加载数据，就会走到 SourceGenerator ，并且runGenerators()方法调用SourceGenerator.runNext()

// SourceGenerator.java
public boolean startNext() {
    // dataToCache 表示已经获取到的资源
    if (dataToCache != null) {
      Object data = dataToCache;
      dataToCache = null;
      // 将数据缓存
      cacheData(data);
    }
    
    // cacheData 会生成sourceCacheGenerator，交由sourceCacheGenerator缓存处理器处理
    if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
      // 到这里，说明不需要去获取数据
      return true;
    }
    sourceCacheGenerator = null;

    loadData = null;
    boolean started = false;
    
    // 以下部分就是根据缓存策略和各个ModelLoader去加载对应的资源
    while (!started && hasNextModelLoader()) {
      loadData = helper.getLoadData().get(loadDataListIndex++);
      if (loadData != null
          && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
          || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
        started = true;
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
}

ModelLoader 是一个工厂接口，用于将任意复杂的数据模型转换为具体数据类型，从而能够使用DataFetcher去获取由该模型表示的资源的数据。

LoadData 一系列Key和DataFetcher组合的一个数据结构。

HttpGlideUrlLoader ModelLoader实现类，内部会构建一个HttpUrlFetcher对象。

FileLoader ModelLoader实现类，内部会构建一个FileFetcher对象。

在Glide初始化的时候有注册了各种ModelLoader，包括了HttpGlideUrlLoader

registry.append(GlideUrl.class, InputStream.class, new HttpGlideUrlLoader.Factory())

HttpGlideUrlLoader 内部构造了 HttpUrlFetcher ，调用了 HttpUrlFetcher 的loadData()加载网络数据

// HttpUrlFetcher
  public void loadData(@NonNull Priority priority,
      @NonNull DataCallback<? super InputStream> callback) {
    try {
      InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
      callback.onDataReady(result);
    } catch (IOException e) {
      callback.onLoadFailed(e);
    } 
  }
  
private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl,
      Map<String, String> headers) throws IOException {
    ...
    // 利用HttpUrlConnection
    urlConnection = connectionFactory.build(url);
    for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
      urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
    }
    // 设置 HttpUrlConnection 参数
    urlConnection.setConnectTimeout(timeout);
    urlConnection.setReadTimeout(timeout);
    urlConnection.setUseCaches(false);
    urlConnection.setDoInput(true);

    urlConnection.setInstanceFollowRedirects(false);

    urlConnection.connect();
    stream = urlConnection.getInputStream();
    if (isCancelled) { // 被取消
      return null;
    }
    final int statusCode = urlConnection.getResponseCode();
    if (isHttpOk(statusCode)) { // 成功
      return getStreamForSuccessfulRequest(urlConnection);
    } else if (isHttpRedirect(statusCode)) { // 重定向
      String redirectUrlString = urlConnection.getHeaderField("Location");
      if (TextUtils.isEmpty(redirectUrlString)) {
        throw new HttpException("Received empty or null redirect url");
      }
      URL redirectUrl = new URL(url, redirectUrlString);
      cleanup();
      return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
    } 
  }

千辛万苦终于到最后一步的网络加载，底层是利用HttpUrlConnection加载数据

  public void onDataReady(Object data) {
    DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
    // 如果可以缓存
    if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
      dataToCache = data; // 将网络获取到资源缓存在SourceGenerator中
      cb.reschedule(); // DecodeJob会再次执行
    } else {
      cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
          loadData.fetcher.getDataSource(), originalKey);
    }
  }

SourceGenerator再次执行到了startNext()，但是dataToCache已经有数据，在cacheData内部生成了 DataCacheGenerator

// SourceGenerator.java
public boolean startNext() {
    // dataToCache 表示已经获取到的资源
    if (dataToCache != null) {
      Object data = dataToCache;
      dataToCache = null;
      // 将数据缓存
      cacheData(data);
    }
    
    // cacheData 会生成 sourceCacheGenerator，交由 sourceCacheGenerator 缓存处理器处理
    if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
      // 到这里，说明不需要去获取数据
      return true;
    }
    ...
}

// SourceGenerator.java
private void cacheData(Object dataToCache) {
    long startTime = LogTime.getLogTime();
    try {
      Encoder<Object> encoder = helper.getSourceEncoder(dataToCache);
      DataCacheWriter<Object> writer =
          new DataCacheWriter<>(encoder, dataToCache, helper.getOptions());
      // 生成对应的缓存key
      originalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());
      // 将写入磁盘缓存
      helper.getDiskCache().put(originalKey, writer);
    } finally {
      loadData.fetcher.cleanup();
    }
    //生成了 DataCacheGenerator
    sourceCacheGenerator =
        new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);
  }

可见，SourceGenerator第二次执行的时候将缓存写入，并且生成 DataCacheGenerator，并交给DataCacheGenerator.startNext()。

DataCacheGenerator内部会回调 FetcherReadyCallback.onDataFetcherReady()，其实 FetcherReadyCallback就是 SourceGenerator ，依次SourceGenerator会回调到DecodeJob，依次回到EngineJob，最后到Target中，调用ImageView.setImageBitmap()。

总结
Glide使用了弱引用缓存、LruCache、DiskLruCache，底层默认利用了HttpUrlConnection加载数据资源，中间处理转换细节很复杂。