Glide加载图片流程浅析

Glide是Android开发中常用的图片框架,其最基本用法例如Glide.with(context).load(url).into(imageView),我们沿着此链式调用的顺序一窥Glide图片加载流程的样貌。

一图胜千言

b784f4ad31217d419faedc0d0efc595f.jpg

1.Glide.with(context)

// Glide.java 
public static RequestManager with(@NonNull Context context) { 
    return getRetriever(context).get(context); 
} 
public static RequestManager with(@NonNull Activity activity) { 
    return getRetriever(activity).get(activity); 
} 
public static RequestManager with(@NonNull FragmentActivity activity) { 
    return getRetriever(activity).get(activity); 
} 
public static RequestManager with(@NonNull Fragment fragment) { 
    return getRetriever(fragment.getContext()).get(fragment); 
} 
public static RequestManager with(@NonNull View view) { 
    return getRetriever(view.getContext()).get(view); 
} 

该函数的作用是创建了RequestManager对象并返回。其参数有五种类型,这里选取Context类型情形进行分析。

可以看到RequestManager对象是先通过getRetriver()方法创建得到一个RequestManagerRetriever对象,再调用该对象的get()方法返回。

1.1RequestManager对象的创建过程

// Glide.java 
private static RequestManagerRetriever getRetriever(@Nullable Context context) { 
    // Glide.get(context)获取Glide实例 
    return Glide.get(context).getRequestManagerRetriever(); 
} 
public static Glide get(@NonNull Context context) { 
    if (glide == null) { 
      // 加载AppGlideModule 
      GeneratedAppGlideModule annotationGeneratedModule = 
          getAnnotationGeneratedGlideModules(context.getApplicationContext()); 
      synchronized (Glide.class) { 
        if (glide == null) { 
          // 加载Mainfest配置、注册模块回调 
          // 这一步执行了 Glide.build()方法构造Glide实例。build方法下面会讲到 
          checkAndInitializeGlide(context, annotationGeneratedModule); 
        } 
      } 
    } 
    return glide; 
  } 

getRetriever(context)方法中,先通过Glide.get(context)获取Glide实例,Glide采用双重校验锁的懒汉式的单例模式创建,同时读取AppGlideModule和AndroidManifest.xml的配置。

获取到Glide实例后,紧接着调用getRequestManagerRetriever方法返回了上一步已经初始化好的RequestManagerRetriever对象。

1.1.1RequestManagerRetriever是如何初始化的?

RequestManagerRetriever对象的初始化主要是在Glide对象的创建过程中完成的,也就是Glide.get(context)方法中的checkAndInitializeGlide()函数中,该函数内部调用了Glide.build方法,源码如下:

// GlideBuilder.java 
Glide build(@NonNull Context context) { 
      // 分配线程池、配置缓存策略 
      sourceExecutor = GlideExecutor.newSourceExecutor(); 
      diskCacheExecutor = GlideExecutor.newDiskCacheExecutor(); 
      animationExecutor = GlideExecutor.newAnimationExecutor(); 
      memorySizeCalculator = new MemorySizeCalculator.Builder(context).build(); 
      // 监听网络变化 
      connectivityMonitorFactory = new DefaultConnectivityMonitorFactory(); 
      int size = memorySizeCalculator.getBitmapPoolSize(); 
      if (size > 0) { 
        bitmapPool = new LruBitmapPool(size); 
      } else { 
        bitmapPool = new BitmapPoolAdapter(); 
      } 
      arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes()); 
      memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize()); 
      diskCacheFactory = new InternalCacheDiskCacheFactory(context); 
    // engine是负责执行加载任务的 
    if (engine == null) { 
      engine = 
          new Engine( 
              memoryCache, 
              diskCacheFactory, 
              diskCacheExecutor, 
              sourceExecutor, 
              GlideExecutor.newUnlimitedSourceExecutor(), 
              animationExecutor, 
              isActiveResourceRetentionAllowed); 
    } 
    if (defaultRequestListeners == null) { 
      defaultRequestListeners = Collections.emptyList(); 
    } else { 
      defaultRequestListeners = Collections.unmodifiableList(defaultRequestListeners); 
    } 
   // focus 1===
    RequestManagerRetriever requestManagerRetriever = 
        new RequestManagerRetriever(requestManagerFactory); 
    return new Glide( 
        context, 
        engine, 
        memoryCache, 
        bitmapPool, 
        arrayPool, 
        requestManagerRetriever, 
        connectivityMonitorFactory, 
        logLevel, 
        defaultRequestOptionsFactory, 
        defaultTransitionOptions, 
        defaultRequestListeners, 
        isLoggingRequestOriginsEnabled, 
        isImageDecoderEnabledForBitmaps); 
  } 

注意focus 1处的代码创建了RequestManagerRetriever对象。

public interface RequestManagerFactory {
    @NonNull
    RequestManager build(
        @NonNull Glide glide,
        @NonNull Lifecycle lifecycle,
        @NonNull RequestManagerTreeNode requestManagerTreeNode,
        @NonNull Context context);
  }

从以上代码我们可以知道:

1.执行Glide.get()方法时就已经分配好了资源加载、缓存线程池、配置好了缓存策略,这里的engine专门负责加载、解码资源,ConnectivityMonitor注册了网络状态监听器,当网络断开时暂停请求网络资源,重连后继续请求资源;
2.RequestManagerRetriever是通过RequestManagerFactory工厂类构造的,进入到RequestManagerFactory.java类中,可以看到其build()方法获取到了相应的RequestManager对象;

1.1.2 factory.build()方法在什么时候调用的?

在之前getRetriever(context).get(context);的调用中可以发现
在RequestManagerRetriever类中有一个get()方法,正是在这个方法中调用了factory.build()方法返回了RequestManager对象。

如果Glide.with(context)传入的context参数是Application类或者是在后台线程调用的该方法,则调用getApplicationManager(Context context)

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) {
          // Normally pause/resume is taken care of by the fragment we add to the fragment or
          // activity. However, in this case since the manager attached to the application will not
          // receive lifecycle events, we must force the manager to start resumed using
          // ApplicationLifecycle.

          // TODO(b/27524013): Factor out this Glide.get() call.
          Glide glide = Glide.get(context.getApplicationContext());
          applicationManager =
              factory.build(
                  glide,
                  new ApplicationLifecycle(),
                  new EmptyRequestManagerTreeNode(),
                  context.getApplicationContext());
        }
      }
    }

    return applicationManager;
  }

否则调用supportFragmentGet或者fragmentGet

private RequestManager fragmentGet(
      @NonNull Context context,
      @NonNull android.app.FragmentManager fm,
      @Nullable android.app.Fragment parentHint,
      boolean isParentVisible) {
    RequestManagerFragment current = getRequestManagerFragment(fm, parentHint, isParentVisible);
    RequestManager requestManager = current.getRequestManager();
    if (requestManager == null) {
      // TODO(b/27524013): Factor out this Glide.get() call.
      Glide glide = Glide.get(context);
      requestManager =
          factory.build(
              glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
      current.setRequestManager(requestManager);
    }
    return requestManager;
  }

从这里也可以发现,当App进入后台后会导致页面不可见,此时RequestManager绑定到了ApplicationContext,与App的生命周期一致;在其他情况下,RequestManager是和当前页面的生命周期绑定,因此在RequestManager.java类中也实现了生命周期相关的回调函数;

执行完Glide.with(context)后我们拿到了一个对应的RequestManager对象,接下来就执行下一个任务load(url);

load(url)

拿到了RequestManager,紧接着调用load方法开始执行下一步操作,同样先看看load方法的实现

// RequestManager.java 
public RequestBuilder<Drawable> load(@Nullable Bitmap bitmap) { 
    return asDrawable().load(bitmap); 
  } 
  public RequestBuilder<Drawable> load(@Nullable Drawable drawable) { 
    return asDrawable().load(drawable); 
  } 
  public RequestBuilder<Drawable> load(@Nullable String string) { 
    return asDrawable().load(string); 
  } 
  public RequestBuilder<Drawable> load(@Nullable Uri uri) { 
    return asDrawable().load(uri); 
  } 
  public RequestBuilder<Drawable> load(@Nullable File file) { 
    return asDrawable().load(file); 
  } 
  public RequestBuilder<Drawable> load(@RawRes @DrawableRes @Nullable Integer resourceId) { 
    return asDrawable().load(resourceId); 
  } 
  public RequestBuilder<Drawable> load(@Nullable URL url) { 
    return asDrawable().load(url); 
  } 
  public RequestBuilder<Drawable> load(@Nullable byte[] model) { 
    return asDrawable().load(model); 
  } 
  public RequestBuilder<Drawable> load(@Nullable Object model) { 
    return asDrawable().load(model); 
  } 

load()同样有多个重载函数,传入的参数可以是图片对象Bitmap、Drawable、本地资源Uri、在线资源路径Url、文件对象File、assets资源的id,这里以参数为Url为例;

asDrawable().load(url)返回了一个RequestBuilder对象,首先看看asDrawable方法干了什么;

// RequestManager.java 
  public RequestBuilder<Drawable> asDrawable() { 
    return as(Drawable.class); 
  } 
  public <ResourceType> RequestBuilder<ResourceType> as(@NonNull Class<ResourceType> resourceClass) { 
    return new RequestBuilder<>(glide, this, resourceClass, context); 
  } 

asDrawable方法创建了RequestBuilder对象,然后调用RequestBuilder.java中的load方法;

// RequestBuilder.java 
  // 传入的String类型的url将会被作为缓存的key 
  public RequestBuilder<TranscodeType> load(@Nullable String string) { 
    return loadGeneric(string); 
  } 
  // 这里返回了自身 
  private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) { 
    this.model = model; 
    isModelSet = true; 
    return this; 
  } 

load函数主要工作就是根据传入的资源类型,构造了一个相应的RequestBuilder对象。至此一切准备工作准备就绪,接下来就是最为重要的一步了-加载、展示文件,让我们来着看into(view)方法如何完成这些任务;

3.load(imageView)

拿到的是对应类型RequestBuilder实例,那么就看看该类里into方法的具体实现。同样into方法有into(@NonNull Y target)into(@NonNull ImageView )两个重载函数(这两个函数最终都会走到同一个函数中),由于调用into方法时我们传入的参数是ImageView类型的;

// RequestBuilder.java 
  public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) { 
    Util.assertMainThread(); 
    BaseRequestOptions<?> requestOptions = this; 
    // View's scale type. 
    // 处理图片缩放,根据缩放类型来初始化对应的requestOptions对象 
    ...... 
    return into( 
        glideContext.buildImageViewTarget(view, transcodeClass), 
        /*targetListener=*/ null, 
        requestOptions, 
        Executors.mainThreadExecutor() // 运行在主线程的handler ,利用Handler实现子线程到主线程的切换,因为最终将图片设置到ImageView是需要在主线程操作的
    ); 
  } 

上面代码段首先处理图片缩放类型(裁剪、对齐方式等),并将生成的相关参数放入了requestOptions对象中,然后再将其作为参数传给了RequestBuilder.java类私有方法into。该方法定义的四个参数分别为:viewTarget、target回调监听器、请求参数、主线程的回调函数;

显然外部传入ImageView对象最终被转换成了ViewTarget对象,转换函数便是glideContext.buildImageViewTarget(view, transcodeClass);
无论传入参数是何种类型,最终都会转换成两种类型的ViewTarget :BitmapImageViewTarget或者DrawableImageViewTarget;具体取决于asBitmap()、asGif()和asDrawable()函数是否被调用,默认是调用的asDrawable(),所以默认返回的是DrawableImageViewTarget类型。

public class DrawableImageViewTarget extends ImageViewTarget<Drawable> {

  public DrawableImageViewTarget(ImageView view) {
    super(view);
  }

  /** @deprecated Use {@link #waitForLayout()} instead. */
  // Public API.
  @SuppressWarnings({"unused", "deprecation"})
  @Deprecated
  public DrawableImageViewTarget(ImageView view, boolean waitForLayout) {
    super(view, waitForLayout);
  }

  @Override
  protected void setResource(@Nullable Drawable resource) {
    view.setImageDrawable(resource); //显示图片
  }
}

至此ViewTarget创建完毕,我们再回到RequestBuilder.java私有into方法

// RequestBuilder.java` 
 private <Y extends Target<TranscodeType>> Y into( 
      @NonNull Y target, 
      @Nullable RequestListener<TranscodeType> targetListener, 
      BaseRequestOptions<?> options, 
      Executor callbackExecutor) { 
    // 注释1:创建request 
    Request request = buildRequest(target, targetListener, options, callbackExecutor); 
    // 获取前一个reqeust请求对象 
    Request previous = target.getRequest(); 
    // 与上一个请求相同 并且 上一个请求已完成 
    if (request.isEquivalentTo(previous)&& !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) { 
     // 上一个请求已完成,那么重新启动它 
      if (!Preconditions.checkNotNull(previous).isRunning()) { 
        previous.begin(); 
      } 
      return target; 
    } 
    // 与上一个请求不同,则清除掉上一个,再将加入新请求 
    requestManager.clear(target); 
    target.setRequest(request); 
    requestManager.track(target, request); 
    return target; 
  } 

顺着代码次序,来看看这个方法每一步都干了什么:

1.首先执行buildRequest方法创建一个新的Request请求req1;
2.获取当前ViewTarget上正在进行中的Request请求req2;
3.判断新建的请求req1与已有的请求req2是否相同,如果相同则判断是否跳过req2请求的缓存,两个条件都满足则开始执行begin()方法开始请求资源并停止往下执行,条件都不满足则继续执行第四步;
4.给ViewTarget设置最新的请求req1,然后执行track方法追踪req1。
5.执行into(view)方法首先获取到了Request请求,然后开始执行Request。如果是复用的Request则直接执行begin(),否则执行track(target, request),但最终仍然会执行begin();

当我们在常见的列表界面中(如 recycleview 实现的列表),使用上面的代码,在我们快速滑动中,glide 是如何实现正确加载图片,而没有导致图片内容的错位或者是不正确呢?

答案就在上面的代码中。执行上面的代码后,glide 要把最新的图片加载到正确的对象上,而取消对象之前关联的图片加载请求。

首先,在该方法中构建了一个 Request 并持有了 target 。这样便可以将结果通知给 target。Target 是 Glide 对我们要加载目标的一个封装和抽象。
判断Taget 中的之前的 Request 和最新构建的 Request 是否相同,如果相同回收最新的 Request ,让旧的 Request 继续运行。如果不同,就取消之前的 Request 和 target 的关联。

 requestManager.clear(target);

最终会触发下面的代码

if (!isOwnedByUs && !glide.removeFromManagers(target) && target.getRequest() != null) {
      Request request = target.getRequest();
      target.setRequest(null);
      request.clear();
    }

可以看到, target 对应的 request 被置 null, 而旧的 request 被 “clear”。旧的 Request 被 clear 后,又是如何让资源没有去加载到关联的 Target 上的? 我们看其中 SingleRequest 的实现

# SingleRequest.java
  /**
   * Cancels the current load if it is in progress, clears any resources held onto by the request
   * and replaces the loaded resource if the load completed with the placeholder.
   *
   * <p> Cleared requests can be restarted with a subsequent call to {@link #begin()} </p>
   *
   * @see #cancel()
   */
  @Override
  public void clear() {
    Util.assertMainThread();
    assertNotCallingCallbacks();
    stateVerifier.throwIfRecycled();
    if (status == Status.CLEARED) {
      return;
    }
    cancel();
    // Resource must be released before canNotifyStatusChanged is called.
    if (resource != null) {
      releaseResource(resource);
    }
    if (canNotifyCleared()) {
      target.onLoadCleared(getPlaceholderDrawable());
    }
    // Must be after cancel().
    status = Status.CLEARED;
  }

可以看到 clear() 方法中先是 执行了 cancel(),该方法会取消加载资源请求与该 Request 的回调关联。

  /**
   * Cancels the current load but does not release any resources held by the request and continues
   * to display the loaded resource if the load completed before the call to cancel.
   *
   * <p> Cancelled requests can be restarted with a subsequent call to {@link #begin()}. </p>
   *
   * @see #clear()
   */
  void cancel() {
    assertNotCallingCallbacks();
    stateVerifier.throwIfRecycled();
    target.removeCallback(this);
    status = Status.CANCELLED;
    if (loadStatus != null) {
      loadStatus.cancel();
      loadStatus = null;
    }
  }

起关键作用代码为

 loadStatus.cancel();
public static class LoadStatus {
    private final EngineJob<?> engineJob;
    private final ResourceCallback cb;

    LoadStatus(ResourceCallback cb, EngineJob<?> engineJob) {
      this.cb = cb;
      this.engineJob = engineJob;
    }

    public void cancel() {
      engineJob.removeCallback(cb);
    }
  }

LoadStatus 实际上只是持有了ResourceCallback回调(该回调可获取资源加载成功或失败)和 EngineJob。
EngineJob 是负责加载资源,并在加载成功后回调回去,这里 SingleRequest 实现了回调,所以它便可得知资源加载完成并获取到。所以 cancel() 调用后,即使旧的加载请求完成也不会回调到 Tareget 上。

  target.setRequest(request);
    requestManager.track(target, request);

在该方法中,方法中,Target 持有了最新的 request , requestManager.track() 方法则触发了 request 的加载请求,实际是由内部 Engine 和 EngineJob 负责。当顺利加载成功后便回调到 Target 对象上,触发 target.onResourceReady(result, animation) 方法,图片便被正确显示出来了。

###########################################################

回到上面的流程,在into(view)方法中,首先获取到了Request请求,然后开始执行Request。如果是复用的Request则直接执行begin(),否则执行track(target, request),但最终仍然会执行begin();

// ReqeustManager.java   
synchronized void track(@NonNull Target<?> target, @NonNull Request request) { 
    // 与lifecycle绑定 
    targetTracker.track(target); 
    // 启动reqeust 
    requestTracker.runRequest(request); 
  } 
// RequestTracker.java 
  public void runRequest(@NonNull Request request) { 
    requests.add(request); 
    if (!isPaused) { 
      request.begin(); // 立即开始加载 
    } else { 
      //防止从以前的请求中加载任何位图,释放该请求所拥有的任何资源,显示当前占位符(如果提供了该占位符),并将该请求标记为已取消。 
      // request.java( Interface ) 
      request.clear(); 
      pendingRequests.add(request); // 加入队列等待执行 
    } 
  } 

Request类是interface类型,begin()是它的抽象方法,要想弄清楚begin()的具体实现,那就要先找到Request的实现类,SingleRequest,我们直接去SingleReqeust类里面 看看begin方法如何实现的;

// SingleReqeust.java 
public void begin() { 
      if (status == Status.COMPLETE) { 
        // 资源已下载,直接回调 
        // 执行动画 
        onResourceReady(resource, DataSource.MEMORY_CACHE); 
        return; 
      } 
        // 计算尺寸 
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) { 
        onSizeReady(overrideWidth, overrideHeight); 
      } else { 
        target.getSize(this); 
      } 
      if ((status == Status.RUNNING || status == Status.WAITING_FOR_SIZE) 
          && canNotifyStatusChanged()) { 
        // 开始加载 
        // 设置占位度 
        target.onLoadStarted(getPlaceholderDrawable()); 
      } 
  } 

进入begin方法后首先判断如果资源已经过加载好了则直接回调onResourceReady显示图片并缓存,否则测量出图片尺寸后再开始加载图片(onSizeReady()中执行加载任务)并同时显示占位图:
接着再看onSizeReady()测量完图片尺寸后如何加载图片的:

// SingleRequest.java 
@Override 
  public void onSizeReady(int width, int height) { 
      if (status != Status.WAITING_FOR_SIZE) { 
        return; 
      } 
      status = Status.RUNNING; 
      // 获取图片尺寸 
      float sizeMultiplier = requestOptions.getSizeMultiplier(); 
      this.width = maybeApplySizeMultiplier(width, sizeMultiplier); 
      this.height = maybeApplySizeMultiplier(height, sizeMultiplier); 
      // 开始加载任务 
      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, 
              callbackExecutor); 
  } 

可以看到真正的下载任务是在Engine类的load方法中实现的,其中也涉及到了图片缓存逻辑;

最终通过Handler机制,Glide从工作线程切换到主线程,并最终将Drawable对象显示到ImageView上;
具体再分析一下线程是如何切换的。

线程切换的过程

回到SingleRequest.onSizeReady()

# SingleRequest
@Override
  public void onSizeReady(int width, int height) {
  ...
  // 省略不相关代码
  ...
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,
              callbackExecutor);
}
#Engine
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) {
Util.assertMainThread();
long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
//focus1 更新相应属性创建缓存key--EngineKey 
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);
  if (VERBOSE_IS_LOGGABLE) {
    logWithTimeAndKey("Loaded resource from active resources", startTime, key);
  }
  return null;
}
//尝试从内存缓存中获取
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
  cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
  if (VERBOSE_IS_LOGGABLE) {
    logWithTimeAndKey("Loaded resource from cache", startTime, key);
  }
  return null;
}
//判断当前请求是在在队列中
EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
if (current != null) {
  current.addCallback(cb);
  if (VERBOSE_IS_LOGGABLE) {
    logWithTimeAndKey("Added to existing load", startTime, key);
  }
  return new LoadStatus(cb, current);
}
//创建请求job
EngineJob<R> engineJob =
    engineJobFactory.build(
        key,
        isMemoryCacheable,
        useUnlimitedSourceExecutorPool,
        useAnimationPool,
        onlyRetrieveFromCache);
//创建解码job
DecodeJob<R> decodeJob =
    decodeJobFactory.build(
        glideContext,
        model,
        key,
        signature,
        width,
        height,
        resourceClass,
        transcodeClass,
        priority,
        diskCacheStrategy,
        transformations,
        isTransformationRequired,
        isScaleOnlyOrNoTransform,
        onlyRetrieveFromCache,
        options,
        engineJob);
//保存当前请求job
jobs.put(key, engineJob);

engineJob.addCallback(cb);
//开始请求
engineJob.start(decodeJob);

return new LoadStatus(cb, engineJob);
}

注意focus1处的代码

假设一个ImageView的宽高是300300,另一个ImageView的宽高是900900,则在这两个ImageView中加载同一张图片资源会缓存几次?

创建图片缓存Key和图片的model(图片链接Url)、图片资源的宽高都有关系,因此两个不同宽高的ImageView加载同一图片会缓存两次。

1.尝试从活跃的资源内存缓存中中获取资源,取到直接回调返回,没取到执行第二步
2.尝试从内存缓存中获取资源,取到直接回调返回,没取到执行第三步
3.创建请求engineJob
4.执行请求

#EngineJob
public void start(DecodeJob<R> decodeJob) {
this.decodeJob = decodeJob;
// focus1
GlideExecutor executor = decodeJob.willDecodeFromCache()
    ? diskCacheExecutor
    : getActiveSourceExecutor();
executor.execute(decodeJob);
}

DecodeJob实现了Runnable接口,这里将其添加到线程池中,接下来看下run方法 。

#DecodeJob
@Override
public void run() {
GlideTrace.beginSectionFormat("DecodeJob#run(model=%s)", model);
DataFetcher<?> localFetcher = currentFetcher;
try {
  //判断是否已经被取消
  if (isCancelled) {
    notifyFailed();
    return;
  }
  runWrapped();
} catch (Throwable t) {
  if (stage != Stage.ENCODE) {
    throwables.add(t);
    notifyFailed();
  }
  if (!isCancelled) {
    throw t;
  }
} finally {
  if (localFetcher != null) {
    localFetcher.cleanup();
  }
  GlideTrace.endSection();
}
 }
private void runWrapped() {
switch (runReason) {
  case INITIALIZE:
    stage = getNextStage(Stage.INITIALIZE);
    //根据当前流程步骤获取相应获取数据类(刚开始肯定为INITIALIZE初始化状态)
    currentGenerator = getNextGenerator();
    runGenerators();
    break;
  case SWITCH_TO_SOURCE_SERVICE:
    runGenerators();
    break;
  case DECODE_DATA:
    decodeFromRetrievedData();
    break;
  default:
    throw new IllegalStateException("Unrecognized run reason: " + runReason);
}
}
# DecodeJob.getNextGenerator
  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);
}
}

默认的AUTOMATIC方式是允许解码缓存的RESOURCE,所以在 getNextStage 会先返回Stage.RESOURCE_CACHE,然后在start中会返回diskCacheExecutor,然后开始执行DecodeJob,也就是说这里会获得一个ResourceCacheGenerator,

#DecodeJob.runGenerators()
 private void runGenerators() {
currentThread = Thread.currentThread();
startFetchTime = LogTime.getLogTime();
boolean isStarted = false;
 while (!isCancelled && currentGenerator != null
    && !(isStarted = currentGenerator.startNext())) {
  stage = getNextStage(stage);
  currentGenerator = getNextGenerator();
  if (stage == Stage.SOURCE) {
    reschedule();
    return;
  }
}
if ((stage == Stage.FINISHED || isCancelled) && !isStarted) {
  notifyFailed();
}
 }

在 runGenerators 中,会调用 startNext,目前currentGenerator是ResourceCacheGenerator, 那么就是调用它的startNext方法:

@Override
 public boolean startNext() {
  ...
 # 省略部分代码
  ...
  // 这里会从registry中匹配相应的Modeloader来加载数据
       loadData.fetcher.loadData(helper.getPriority(), this);
  ...
   return started;
 }

这里是loadData.fetcher是HttpUrlFetcher。

# HttpUrlFetcher.loadData()
@Override
public void loadData(@NonNull Priority priority,
  @NonNull DataCallback<? super InputStream> callback) {
// 省略部分代码
 //连接网络获取图片流
  InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
  //成功回调
  callback.onDataReady(result);
}

请求成功之后回调了DataCallback方法。最终会回调到DecodeJob的onDataFetcherReady方法,之后在进行解码操作:
解码成功之后,回调EngineJob中的onResourceReady方法:

# EngineJob
 public void onResourceReady(Resource<R> resource, DataSource dataSource) {
    synchronized (this) {
      this.resource = resource;
      this.dataSource = dataSource;
    }
    notifyCallbacksOfResult();
  }

在notifyCallbacksOfResult方法中:

# Engine.java
void notifyCallbacksOfResult() {
   // 省略部分代码
    engineJobListener.onEngineJobComplete(this, localKey, localResource);

    for (final ResourceCallbackAndExecutor entry : copy) {
    // focus 
      entry.executor.execute(new CallResourceReady(entry.cb));
    }
    decrementPendingCallbacks();
  }

注意focus行的代码:

使用entry中的executor执行线程,而entry就是ResourceCallbackAndExecutor ,而它里面的executor正好是我们Executors.mainThreadExecutor()

很明显它是在这里切换到了主线程。

补充说明1:

首先回顾下主线程的创建,在RequestBuilder.java中的into方法中:

public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
    Util.assertMainThread();
    ...

    return into(
        glideContext.buildImageViewTarget(view, transcodeClass),
        /*targetListener=*/ null,
        requestOptions,
        Executors.mainThreadExecutor());
  }

Executor.java
  private static final Executor MAIN_THREAD_EXECUTOR =
      new Executor() {
        private final Handler handler = new Handler(Looper.getMainLooper());

        @Override
        public void execute(@NonNull Runnable command) {
          handler.post(command);
        }
      };

它最终会一层一层传递到EngineJob中。engineJob.addCallback(cb, callbackExecutor); 它将被实例化为一个ResourceCallbackAndExecutor对象并add到cbs集合中。

EngineJob.java
  synchronized void addCallback(final ResourceCallback cb, Executor callbackExecutor) {
    ...
    cbs.add(cb, callbackExecutor);
    ...
  }

    void add(ResourceCallback cb, Executor executor) {
      callbacksAndExecutors.add(new ResourceCallbackAndExecutor(cb, executor));
    }

补充说明2:

以上代码基于glide 4.11.0版本,可能代码有所不同,但是原理是一样。

参考:
Android源码进阶之Glide加载流程和源码详解

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350

推荐阅读更多精彩内容