Glide学习(一)—工作流程分析

Glide遇到重定向url产生的bug分析以及解决 android Glide4遇到重定向url产生的bug分析以及解决 阅读详情

前言

目前在Android中有许多图片加载框架,比如UniversalImageLoader、Volley、Picasso、Fresco、Glide等。Glide作为一个快速高效的Android图片加载库,是Android开发使用最多的图片加载库之一。因为Glide的高性能、可扩展的特性,也是被Google推荐使用的图片加载库。

用过Glide的同学都知道,Glide仅仅使用一行代码就可以将图片加载到对应的位置。比如:Glide.with(activity).load(url).into(imageView); 可以将对应url的网络图片加载到一个ImageView中。

本篇文章不讲Glide的使用。主要分析下Glide的加载流程用来深入的学习Glide。

以下基于Glide 4.8.0的源码进分析

Glide的加载流程

在上面从url中加载图片的例子中可以看到,Glide通过调用几个简单的方法就能实现图片的加载。

Glide.with(activity).load(url).into(imageView);

虽然只是简单的一行代码,但是可以想到的是Glide做了大量的工作才能完成图片的加载。在上面的代码总共调用了三个方法,分别是with()、load()以及into()。接下来逐一分析。

从with()开始
public class Glide {
  @NonNull
  public static RequestManager with(@NonNull Context context) {
    return getRetriever(context).get(context);
  }

  @NonNull
  public static RequestManager with(@NonNull Activity activity) {
    return getRetriever(activity).get(activity);
  }

  @NonNull
  public static RequestManager with(@NonNull FragmentActivity activity) {
    return getRetriever(activity).get(activity);
  }

  @NonNull
  public static RequestManager with(@NonNull Fragment fragment) {
    return getRetriever(fragment.getActivity()).get(fragment);
  }

  @NonNull
  public static RequestManager with(@NonNull View view) {
    return getRetriever(view.getContext()).get(view);
  }
}

可以看到,在Glide中有许多with()方法的重载。其中传入with()的参数可以是Activity、Fragment或者Context。每个with()方法都返回了一个RequestManager对象。接着往下看,通过getRetriever().get()方法得到RequestManager对象。

@NonNull
  private static RequestManagerRetriever getRetriever(@Nullable Context context) {
    return Glide.get(context).getRequestManagerRetriever();
  }

@NonNull
  public RequestManagerRetriever getRequestManagerRetriever() {
    return requestManagerRetriever;
  }

可以看出,RequestManager对象来自于RequestManagerRetriever的get方法。

@NonNull
  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)) {
      if (context instanceof FragmentActivity) {
        return get((FragmentActivity) context);
      } else if (context instanceof Activity) {
        return get((Activity) context);
      } else if (context instanceof ContextWrapper) {
        return get(((ContextWrapper) context).getBaseContext());
      }
    }

    return getApplicationManager(context);
  }

  @NonNull
  public RequestManager get(@NonNull FragmentActivity activity) {
    //.....省略代码
    return supportFragmentGet(activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
  }

  @NonNull
  public RequestManager get(@NonNull Fragment fragment) {
    //.....省略代码
    return supportFragmentGet(fragment.getActivity(), fm, fragment, fragment.isVisible());
  }

  @SuppressWarnings("deprecation")
  @NonNull
  public RequestManager get(@NonNull Activity activity) {
      //.....省略代码
      return fragmentGet(activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
    }
  }

  @SuppressWarnings("deprecation")
  @NonNull
  public RequestManager get(@NonNull View view) {
    //.....省略代码
    return get(fragment);
  }

RequestManagerRetriever中get()方法也有很多种重载,分别处理不同的情况Context的情况、Activity、Fragment的情况。总共存在这两种处理方案:这两种方案的主要区别就是Glide的请求的生命周期的差异。

  • 处理参数为Context的情况:在这种情况下最终会通过Application以及ApplicationLifecycle来构造RequestManager。这样Glide的请求就是Application的生命周期。

  • 处理Activity、Fragment的情况:这种情况是通过创建一个不可见的Fragment加入到对应的Activity中来实现Glide的请求的生命周期。

以上是两种不同的处理方式,关于Application的情况,Glide的生命周期是应用的生命周期,当应用被关闭是Glide会停止还没有加载完的请求;关于Activity以及Fragment的情况,通过创建一个不可见的Fragment加入到对应的Activity中实现Glide的生命周期。当Glide在摸个Activity中加载图片时,Activity退出时,Glide也会停止加载。

以下通过代码看下这两种情况:

//处理Application的情况
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(), //Application的生命周期回调接口
                  new EmptyRequestManagerTreeNode(),
                  context.getApplicationContext());
        }
      }
    }

    return applicationManager;
  }
//处理Activity的情况

//1.获取不可见的Fragment
private RequestManagerFragment getRequestManagerFragment(
      @NonNull final android.app.FragmentManager fm,
      @Nullable android.app.Fragment parentHint,
      boolean isParentVisible) {
    RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
    if (current == null) {
      current = pendingRequestManagerFragments.get(fm);
      if (current == null) {
        current = new RequestManagerFragment();
        current.setParentFragmentHint(parentHint);
        if (isParentVisible) { //parent可见,执行生命周期回调
          current.getGlideLifecycle().onStart();
        }
        pendingRequestManagerFragments.put(fm, current);
        fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss(); //添加Fragment
        handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
      }
    }
    return current;
  }

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);  //创建RequestManager对象
      current.setRequestManager(requestManager);
    }
    return requestManager;
  }

以上就是with()的调用情况,在with()方法中主要构造了RequestManager对象,并且会根据参数的不同来决定不同生命周期额加载逻辑。接下来要处理load()方法。我们可以知道load()方法是RequestManager中的方法,接下来分析load()方法。

load()方法

可以知道,load()方法是在RequestManager中的。

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()方法也有很多重载的方法,这些方法对应了Glide加载图片的不同类型Url、资源id、文件等。load()最终返回了RequestBuilder对象。

除此之外,还能看到一个asDrawable()方法,这个方法的意义是Glide最终以Drawable的形式加载图片。除了asDrawable()方法外还有asBitmap()、asGif()等方法。我们从asDrawable()开始分析。

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是泛型类,传入的类型就是Glide最终加载图片的类型。asDrawable()方法返回RequestBuilder对象,那么接下来的load()方法就是RequestBuilder中的方法。

public RequestBuilder<TranscodeType> load(@Nullable Object model) {
    return loadGeneric(model);
  }

public RequestBuilder<TranscodeType> load(@Nullable Bitmap bitmap) {
    return loadGeneric(bitmap).apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
  }

  public RequestBuilder<TranscodeType> load(@Nullable Drawable drawable) {
    return loadGeneric(drawable).apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
  }

  public RequestBuilder<TranscodeType> load(@Nullable String string) {
    return loadGeneric(string);
  }

  public RequestBuilder<TranscodeType> load(@Nullable Uri uri) {
    return loadGeneric(uri);
  }

  public RequestBuilder<TranscodeType> load(@Nullable File file) {
    return loadGeneric(file);
  }

  public RequestBuilder<TranscodeType> load(@RawRes @DrawableRes @Nullable Integer resourceId) {
    return loadGeneric(resourceId).apply(signatureOf(ApplicationVersionSignature.obtain(context)));
  }

  public RequestBuilder<TranscodeType> load(@Nullable URL url) {
    return loadGeneric(url);
  }

  public RequestBuilder<TranscodeType> load(@Nullable byte[] model) {
    RequestBuilder<TranscodeType> result = loadGeneric(model);
    if (!result.isDiskCacheStrategySet()) {
      result = result.apply(diskCacheStrategyOf(DiskCacheStrategy.NONE));
    }
    if (!result.isSkipMemoryCacheSet()) {
      result = result.apply(skipMemoryCacheOf(true /*skipMemoryCache*/));
    }
    return result;
  }

可以看到,RequestBuilder中也有多种load()的重载方法,这些方法最终也都返回RequestBuilder对象。同时他们都会调用loadGeneric()方法。

private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
    this.model = model;
    isModelSet = true;
    return this;
  }

loadGeneric()方法记录了加载类型model。

以上就是load()方法的加载过程,逻辑并不复杂,在load()主要的工作就是构造RequestBuilder对象。

into()方法

在完成with()、load()方法后就只剩下最后一步了,into()方法最终会将获取的图片加载到ImageView中去。以上两个方法中,我们看到只是构造了RequestManager以及RequestBuilder对象,并没有做太多的工作,甚至连图片的加载过程还没开始。那个可以知道,在into()方法中将完成接下来的所有工作。

我们从代码看起:

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

    BaseRequestOptions<?> requestOptions = this;
    if (!requestOptions.isTransformationSet()
        && requestOptions.isTransformationAllowed()
        && view.getScaleType() != null) {
      
      switch (view.getScaleType()) {
        case CENTER_CROP:
          requestOptions = requestOptions.clone().optionalCenterCrop();
          break;
        case CENTER_INSIDE:
          requestOptions = requestOptions.clone().optionalCenterInside();
          break;
        case FIT_CENTER:
        case FIT_START:
        case FIT_END:
          requestOptions = requestOptions.clone().optionalFitCenter();
          break;
        case FIT_XY:
          requestOptions = requestOptions.clone().optionalCenterInside();
          break;
        case CENTER:
        case MATRIX:
        default:
          // Do nothing.
      }
    }

    return into(
        glideContext.buildImageViewTarget(view, transcodeClass), //这里创建Target对象
        /*targetListener=*/ null,
        requestOptions,
        Executors.mainThreadExecutor());
  }

在上面的方法中,要将获取的图片加载到ImageView中。在方法的开始,处理了ImageView的缩放方式,然后保存在了RequestOptions中。接下来调用了其他重载的into()方法,在开始这个into()方法时,还创建了Target对象,这里是DrawableImageViewTarget。Target对象的主要作用是保存目标View、request等信息。

private <Y extends Target<TranscodeType>> Y into(
      @NonNull Y target,
      @Nullable RequestListener<TranscodeType> targetListener,
      BaseRequestOptions<?> options,
      Executor callbackExecutor) {
    Preconditions.checkNotNull(target);
    if (!isModelSet) {
      throw new IllegalArgumentException("You must call #load() before calling #into()");
    }
    //创建 Request -> 图片加载请求
    Request request = buildRequest(target, targetListener, options, callbackExecutor);
    Request previous = target.getRequest(); //是否与前一个请求相同
    if (request.isEquivalentTo(previous)
        && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {
      request.recycle();
      if (!Preconditions.checkNotNull(previous).isRunning()) {
        previous.begin();
      }
      return target;
    }

    requestManager.clear(target);
    target.setRequest(request); 
    requestManager.track(target, request); //发起请求

    return target;
  }

这个方法中主要构造了图片获取请求以及发起图片请求。通过buildRequest()方法获取了图片请求,在构造Request的过程中,传递了很多参数,比如placeholderId、errorPlaceholder、diskCacheStrategy等,这里不展开描述了。在构造完Request时,就开始发起请求。通过RequestManager的track()方法实现。

/**RequestManager**/
synchronized void track(@NonNull Target<?> target, @NonNull Request request) {
    targetTracker.track(target);
    requestTracker.runRequest(request); //开始图片请求
  }

/**RequestTracker**/
public void runRequest(@NonNull Request request) {
    requests.add(request);
    if (!isPaused) {
      request.begin(); //如果不是停止状态,则开始请请求
    } else {
      request.clear();
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        Log.v(TAG, "Paused, delaying request");
      }
      pendingRequests.add(request);
    }
  }

最终,在RequestTracker中开始请求。

public synchronized void begin() {
    assertNotCallingCallbacks();
    stateVerifier.throwIfRecycled();
    startTime = LogTime.getLogTime();
    if (model == null) {
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
        width = overrideWidth;
        height = overrideHeight;
      }
      int logLevel = getFallbackDrawable() == null ? Log.WARN : Log.DEBUG;
      //图片加载失败
      onLoadFailed(new GlideException("Received null model"), logLevel);
      return;
    }

    if (status == Status.RUNNING) {
      throw new IllegalArgumentException("Cannot restart a running request");
    }

    if (status == Status.COMPLETE) {
      //请求完成,加载图片到对应的View
      onResourceReady(resource, DataSource.MEMORY_CACHE);
      return;
    }

    // Restarts for requests that are neither complete nor running can be treated as new requests
    // and can run again from the beginning.
    status = Status.WAITING_FOR_SIZE; //从这里开始请求
    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()方法中已经开启了图片加载流程,根据不同的运行状态加载图片。在开始status是WAITING_FOR_SIZE用来确定图片尺寸。如果在构造请求时传入了长和宽的参数直接开始下一步,否则调用Target对象的getSize()方法。继续跟getSize()代码的话,最终调用的还是onSizeReady()方法,这里我们只分析onSizeReady()的方法。

public synchronized void onSizeReady(int width, int height) {
    stateVerifier.throwIfRecycled();
    if (status != Status.WAITING_FOR_SIZE) {
      return;
    }
    status = Status.RUNNING; //设置status为RUNNING,接下来会执行占位符的加载

    float sizeMultiplier = requestOptions.getSizeMultiplier();
    this.width = maybeApplySizeMultiplier(width, sizeMultiplier);
    this.height = maybeApplySizeMultiplier(height, sizeMultiplier);
    //这里开始加载图片,通过Engine
    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);
    if (status != Status.RUNNING) {
      loadStatus = null;
    }
    if (IS_VERBOSE_LOGGABLE) {
      logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime));
    }
  }

可以看到在onSizeReady()方法中调用了Engine的load()方法。从这里就开始了图片的真正加载流程。接下来看看Engine的load()方法做了什么。

public <R> LoadStatus load(
     /**省略参数显示**/) {
    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;

    EngineKey key =
        keyFactory.buildKey(
            model,
            signature,
            width,
            height,
            transformations,
            resourceClass,
            transcodeClass,
            options);

    EngineResource<?> memoryResource;
    synchronized (this) {
      //先从缓存中获取
      memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);

      if (memoryResource == null) {
        //获取图片
        return waitForExistingOrStartNewJob(
            glideContext,
            model,
            signature,
            width,
            height,
            resourceClass,
            transcodeClass,
            priority,
            diskCacheStrategy,
            transformations,
            isTransformationRequired,
            isScaleOnlyOrNoTransform,
            options,
            isMemoryCacheable,
            useUnlimitedSourceExecutorPool,
            useAnimationPool,
            onlyRetrieveFromCache,
            cb,
            callbackExecutor,
            key,
            startTime);
      }
    }
    //图片获取完成,开始加载
    cb.onResourceReady(memoryResource, DataSource.MEMORY_CACHE);
    return null;
  }

在load()方法中先从缓存中获取图片数据,如果没有在继续获取图片。这里不深入分析Glide的缓存原理。继续下一步分析图片的加载过程。

private <R> LoadStatus waitForExistingOrStartNewJob(
      /**省略参数**/) {
    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      current.addCallback(cb, callbackExecutor);
      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);

    jobs.put(key, engineJob);
    engineJob.addCallback(cb, callbackExecutor);
    engineJob.start(decodeJob); //开始加载
    return new LoadStatus(cb, engineJob);
  }

在waitForExistingOrStartNewJob()方法中创建了EngineJob和DecodeJob,然后通过EngineJob执行DecodeJob。

public synchronized void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
    GlideExecutor executor =
        decodeJob.willDecodeFromCache() ? diskCacheExecutor : getActiveSourceExecutor(); //通过不同的策略获取不同线程池
    executor.execute(decodeJob);
  }

在EngineJob中通过使用Glide中的线程池开始执行DecodeJob任务。接下来分析DecodeJob中都做了些什么。

class DecodeJob {
  @Override
  public void run() {
    //DecodeJob实现了Runnable接口
    GlideTrace.beginSectionFormat("DecodeJob#run(model=%s)", model);
    DataFetcher<?> localFetcher = currentFetcher;
    try {
      if (isCancelled) {
        notifyFailed();
        return;
      }
      runWrapped(); //加载
    } catch (CallbackException e) {
      throw e;
    } catch (Throwable t) {
      if (stage != Stage.ENCODE) {
        throwables.add(t);
        notifyFailed(); //通知加载失败
      }
      if (!isCancelled) {
        throw t;
      }
      throw t;
    } finally {
      if (localFetcher != null) {
        localFetcher.cleanup();
      }
      GlideTrace.endSection();
    }
  }
  //继续执行加载过程
  private void runWrapped() {
    switch (runReason) {
      case INITIALIZE:
        stage = getNextStage(Stage.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);
    }
  }
    
  private Stage getNextStage(Stage current) {
    switch (current) {
      case INITIALIZE:
        return diskCacheStrategy.decodeCachedResource()
            ? Stage.RESOURCE_CACHE
            : getNextStage(Stage.RESOURCE_CACHE);
      case RESOURCE_CACHE:
        return diskCacheStrategy.decodeCachedData()
            ? Stage.DATA_CACHE
            : getNextStage(Stage.DATA_CACHE);
      case DATA_CACHE:
        // Skip loading from source if the user opted to only retrieve the resource from cache.
        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);
    }
  }
}

可以看到,在DecodeJob中正常加载的情况下,会调用runWrapped()方法。在这个方法中,主要的工作是根据不同的加载阶段执行相应的加载过程。从getNextStage()方法的调用可以知道,如果不是从内存中取得话,最终会返回Stage.SOURCE,后获取SourceGenerator。

在创建SourceGenerator时,有个变量decodeHelper,这个变量在初始化(执行init()方法)时会根据model创建DataFetcher对象。这里我们的例子中使用的是url,所以会创建HttpUrlFetcher。在说明了接下来加载过程需要用到的角色后,我们继续分析。

在获取完SourceGenerator后,执行了runGenerators()方法。

private void runGenerators() {
    currentThread = Thread.currentThread();
    startFetchTime = LogTime.getLogTime();
    boolean isStarted = false;
    while (!isCancelled
        && currentGenerator != null
           //currentGenerator.startNext()这里执行加载过程
        && !(isStarted = currentGenerator.startNext())) {
      stage = getNextStage(stage);
      currentGenerator = getNextGenerator();

      if (stage == Stage.SOURCE) {
        reschedule(); //重新执行
        return;
      }
    }
    // We've run out of stages and generators, give up.
    if ((stage == Stage.FINISHED || isCancelled) && !isStarted) {
      notifyFailed();
    }
  }

/**SourceGenerator**/
public boolean startNext() {
    if (dataToCache != null) {
      //缓存数据
      Object data = dataToCache;
      dataToCache = null;
      cacheData(data);
    }
    if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
      return true;
    }
    sourceCacheGenerator = null;

    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      loadData = helper.getLoadData().get(loadDataListIndex++);
      if (loadData != null
          && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
              || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
        started = true;
        //通过HttpUrlFetcher加载数据
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
  }

在runGenerators()方法中调用SourceGenerator的startNext()方法。从代码中可以看出,startNext()方法通过loadData.fetcher.loadData()方法继续加载数据。在上面我们讲到fetcher对象通过model选择。这里fetcher是HttpUrlFetcher。接下来看下HttpUrlFetcher的loadData()方法做了哪些事情。

public void loadData(
      @NonNull Priority priority, @NonNull DataCallback<? super InputStream> callback) {
    long startTime = LogTime.getLogTime();
    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 {
    if (redirects >= MAXIMUM_REDIRECTS) {
      throw new HttpException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");
    }
    //......
      //执行网络请求
    urlConnection = connectionFactory.build(url);
    for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
      urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
    }
    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);
    } else if (statusCode == INVALID_STATUS_CODE) {
      throw new HttpException(statusCode);
    } else {
      throw new HttpException(urlConnection.getResponseMessage(), statusCode);
    }
  }

从上面的代码中可以看到,在HttpUrlFetcher中执行了网络请求加载数据。在完成加载后将数据流返回,然后调用callback.onDataReady(result),callback就是SourceGenerator。接下来的过程就是开始将加载好的数据流进行回传。

第一步是SourceGenerator的onDataReady()方法。

public void onDataFetcherReady(
      Key sourceKey, Object data, DataFetcher<?> fetcher, DataSource dataSource, Key attemptedKey) {
    cb.onDataFetcherReady(sourceKey, data, fetcher,  loadData.fetcher.getDataSource(), sourceKey);  //这里的cb是DecodeJob
  }

在onDataReady()方法中通过callback回调onDataFetcherReady()方法。这里的cb是DecodeJob。

public void onDataFetcherReady(
      Key sourceKey, Object data, DataFetcher<?> fetcher, DataSource dataSource, Key attemptedKey) {
    //......
    if (Thread.currentThread() != currentThread) {
      runReason = RunReason.DECODE_DATA;
      callback.reschedule(this);
    } else {
      GlideTrace.beginSection("DecodeJob.decodeFromRetrievedData");
      try {
        decodeFromRetrievedData();
      } finally {
        GlideTrace.endSection();
      }
    }
  }
private void decodeFromRetrievedData() {
    //......
    Resource<R> resource = null;
    try {
      resource = decodeFromData(currentFetcher, currentData, currentDataSource); //解码资源
    } catch (GlideException e) {
      e.setLoggingDetails(currentAttemptingKey, currentDataSource);
      throwables.add(e);
    }
    if (resource != null) {
      notifyEncodeAndRelease(resource, currentDataSource); //通知
    } else {
      runGenerators();
    }
  }
private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {
	//......
    notifyComplete(result, dataSource); //资源准备完毕
    //......
  }

private void notifyComplete(Resource<R> resource, DataSource dataSource) {
    setNotifiedOrThrow();
    callback.onResourceReady(resource, dataSource);
  }

在DecodeJob中进一步完成回调,主要的工作是解码资源,接下来继续进行资源的回传。这里的callback时候EngineJob。

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) {
      stateVerifier.throwIfRecycled();
      if (isCancelled) {
          //如果是取消状态,回收资源
        resource.recycle();
        release();
        return;
      } else if (cbs.isEmpty()) {
        throw new IllegalStateException("Received a resource without any callbacks to notify");
      } else if (hasResource) {
        throw new IllegalStateException("Already have resource");
      }
      engineResource = engineResourceFactory.build(resource, isCacheable, key, resourceListener);
     
      hasResource = true;
      copy = cbs.copy();
      incrementPendingCallbacks(copy.size() + 1);

      localKey = key;
      localResource = engineResource;
    }
    //这里将资源加入了活动资源缓存
    engineJobListener.onEngineJobComplete(this, localKey, localResource);
	//这里执行资源回调
    for (final ResourceCallbackAndExecutor entry : copy) {
      entry.executor.execute(new CallResourceReady(entry.cb));
    }
    decrementPendingCallbacks();
  }

CallResourceReady是EngineJob的内部类,主要作用是执行资源回调。

public void run() {
      synchronized (cb) {
        synchronized (EngineJob.this) {
          if (cbs.contains(cb)) {
            // Acquire for this particular callback.
            engineResource.acquire();
            callCallbackOnResourceReady(cb); //执行回调
            removeCallback(cb);
          }
          decrementPendingCallbacks();
        }
      }
    }

void callCallbackOnResourceReady(ResourceCallback cb) {
    try {
      cb.onResourceReady(engineResource, dataSource);
    } catch (Throwable t) {
      throw new CallbackException(t);
    }
  }

在这里继续执行资源回调。这里的cb是SingleRequest。

public synchronized void onResourceReady(Resource<?> resource, DataSource dataSource) {
    stateVerifier.throwIfRecycled();
    loadStatus = null;
    //......
    Object received = resource.get();
    if (received == null || !transcodeClass.isAssignableFrom(received.getClass())) {
      releaseResource(resource);
      onLoadFailed(exception);
      return;
    }
    //......
    onResourceReady((Resource<R>) resource, (R) received, dataSource);
  }

  private synchronized void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {
    boolean isFirstResource = isFirstReadyResource();
    status = Status.COMPLETE;
    this.resource = resource;

    isCallingCallbacks = true;
    try {
      boolean anyListenerHandledUpdatingTarget = false;
      if (requestListeners != null) {
        for (RequestListener<R> listener : requestListeners) {
          anyListenerHandledUpdatingTarget |=
              listener.onResourceReady(result, model, target, dataSource, isFirstResource);
        }
      }
      anyListenerHandledUpdatingTarget |=
          targetListener != null
              && targetListener.onResourceReady(result, model, target, dataSource, isFirstResource);

      if (!anyListenerHandledUpdatingTarget) {
        Transition<? super R> animation = animationFactory.build(dataSource, isFirstResource);
        target.onResourceReady(result, animation); //这个target是上面讲到的持有ImageView的Target
      }
    } finally {
      isCallingCallbacks = false;
    }

    notifyLoadSuccess();
  }

从代码中可以看到,这里调用了Target对象。这里的Target对象就是上面讲到的持有ImageView的Target对象。这里的Target是DrawableImageViewTarget,但是onResourceReady在ImageViewTarget中实现。

/**ImageViewTarget**/
public void onResourceReady(@NonNull Z resource, @Nullable Transition<? super Z> transition) {
    //在transition方法中设置图片
    if (transition == null || !transition.transition(resource, this)) {
      setResourceInternal(resource);
    } else {
      maybeUpdateAnimatable(resource);
    }
  }
/**DrawableCrossFadeTransition**/
public boolean transition(Drawable current, ViewAdapter adapter) {
    Drawable previous = adapter.getCurrentDrawable();
    if (previous == null) {
      previous = new ColorDrawable(Color.TRANSPARENT);
    }
    TransitionDrawable transitionDrawable =
        new TransitionDrawable(new Drawable[] {previous, current});
    transitionDrawable.setCrossFadeEnabled(isCrossFadeEnabled);
    transitionDrawable.startTransition(duration);
    adapter.setDrawable(transitionDrawable); //设置图片
    return true;
  }

至此,Glide就完成了整个图片回调的流程了。

总结

可以看到,一行简单的代码 Glide.with(this).load(url).into(imageView);却有着极其复杂的逻辑。这也反映了Glide的功能强大。

在上面的整个加载流程中,涉及到看各个方面。不同类型的图片不同的加载方式,以及缓存的处理等。

Glide源码分析——开篇 Glide是一个很优秀的图片加载开源框架,它能做到一行代码就可以让图片资源显示出来,对使用者非常友好。对于这么优秀的一款开源库,有很多值得学习和借鉴的地方。这也是为什么已经有那么多关于Glide的文章,自己还要去研究它。这将是一个系列的文章,这属于第一篇,在这篇文章中主要介绍Glide的基本使用以及Glide对象的初始化。当然最重要的事,在这个过程中我们能学到什么,那么我们开始吧 文章目录Glide 基本使用使用Glide对象使用GlideApp对象我们能从中学到什么Glide对象创建我们能从中学到什么. 阅读详情

相关推荐

Glide源码学习八:实现带进度的Glide图片加载功能

相关文章:=====扩展目标====首先来确立一下功能扩展的目标。虽说Glide本身就已经十分强大了,但是有一个功能却长期以来都不支持,那就是监听下载进度功能。我们都知道,使用Glide来加载一张网络上的图片是非常简单的,但是让人头疼的是,我们却无从得知当前图片的下载进度。如果这张图片很小的话,那么问题也不大,反正很快就会被加载出来。但如果这是一张比较大的GIF图,用户耐心等了很久结果图片还没显示出来,这个时候你就会觉得下载进度功能是十分有必要的了。

2301_77595001的博客 922

【笔记】开源框架 - Glide(三):代码流程分析

基于Glide基本使用的流程分析

lingchen881218的博客 458

APP图片缓存与Glide之signature的分析

在缓存网络图片的过程中,有一种情况是图片的地址不变,但图片发生了变化,如果只按照图片的地址进行缓存,在加载缓存中的图片时就会发生图片一直显示为旧图的现象。 本文就此问题结合Glide的处理方法进行简要分析。

C.Shawn 1万+

图解Glide流程

在这一周的时间内,事情不是太多,简单的阅读了下Glide 3.6.1的源码,对于其整个调用流程有了一定的了解,希望通过本篇将其总结下来,一来加深印象,二来以后可以反复修改。主要想通过时序图分享一下Glide的调用流程以及其中比较关键的生命周期管理和数据处理流程。 一、流程分析 在整个分析的过程中都基于 Glide.with(context).load(“”).asBitmap

起风了... 3871

Glide源码解析(一)

简介 由于在Android项目开发中我们经常会用到图片加载,你会选择什么第三库来加载图片,今天让我们来学习一下Glide图片加载库的源码吧,之前文章有讲解到Glide的简单使用。 简单使用 这里就不说添加依赖那些了,大家可以看官方文档,或者我之前的文章Glide的简单使用,但是版本现在最新的版本是4.8.0。 接下来我们看看Glide是如何加载图片的,如下代码 public class MainA...

Eirunye的博客 1231

深入分析Glide源码

前言 最近研究了一下Glide源码,发现很多地方写的真的很精妙,值得细细品味。Glide 功能丰富,图片三级缓存、可深度定制(继承AppGlideModule、LibraryGlideModule实现更多功能)、修改网络请求库、支持多种输入输出资源的转换(例如输入Stream,输出bitmap等等)、生命周期的管理 虽然下面分析完了,整体的流程,但是想要真正领会设计思想,还需要好好沉淀一下。文章篇幅比较长,但逻辑并不复杂 一、基本使用流程 Glide最基本的使用流程就是下面这行代码,其它所有扩展的额外功能都

薛瑄的博客 6283

聊一聊关于Glide在面试中的那些事

1.前言 今天填完离职表,帮着公司面试几个帮着填坑的同行,聊着聊着就聊到了Glide,信誓旦旦的和我说,这块很熟悉,之前在掘金社区里,看过一个叫蓝师傅写的这块的文章,基本细节都掌握????。(一副胜利在望的表情,好吧,正巧我也看过,咱们就问一问看的仔细情况) 2. 来简单介绍下Glide的缓存 2.1 分析 (这货滔滔不绝的说了一大通,从LruCache说到了LinkedHashMap,巴拉巴拉。。。...

刘洋巴金的专栏 1万+

Glide 重定向图片资源不刷新问题

http://open.****.cn/v1/getAvatar?id=3&sign=cdeab1c37e9ea2b3c42628db4ab8d5f5&appkey=a63eb2115ea940a69d10feac79a57a25 当图片资源师以上重定向的图片时候、当图片资源修改后此地址不变、获取不到最新图片、此包解决此问题、此包如有问题请邮箱329716228@qq.com联系本人解决

Glide源码学习一:Glide框架介绍、with方法详解

目录 系列文章: Glide的几个基本概念: 使用: with方法详解: 点进去 get(Context context): get(Activity activity) 系列文章: Android面试题:Glide Glide源码学习一:Glide框架介绍、with方法详解 Glide源码学习二:load()详解 Glide源码学习三:into()详解 Glide源码学...

songzi1228的博客 1866

手把手教你:基于STM32H7自制飞控,如何从零开始移植PX4固件(附避坑指南)

本文详细介绍了如何基于STM32H7自制飞控板并移植PX4固件的完整流程,包括硬件设计、开发环境搭建、关键配置文件移植、驱动开发与适配等关键步骤。特别针对PX4-AutoPilot的移植过程提供了实用技巧和避坑指南,帮助开发者高效完成飞控系统开发。

weixin_30271335的博客 143

强化学习赋能宇树机器狗:Isaac Gym与MuJoCo仿真训练全解析

本文详细解析了如何利用Isaac Gym和MuJoCo两大仿真平台为宇树机器狗构建强化学习训练管道。内容涵盖环境配置、模型导入、PPO算法框架设计、奖励函数构建以及从仿真到实机的策略迁移技巧,为开发者提供了一套完整的宇树狗仿真训练实践方案。

zeta9的博客 620

GLIDE 学习笔记

GLIDE模型完成,文字条件生成图片,图片修复任务。

be_humble的博客 6134

LPDDR5时序精调:深入解析Read Gate Training的两种模式

本文深入解析了LPDDR5内存中关键的Read Gate Training技术,详细对比了RDQS Toggle Mode(翻转模式)与Enhanced RDQS Mode(增强模式)的工作原理、时序参数及适用场景。文章阐述了在高速数据传输下精准校准时序的必要性,并提供了两种模式的实战选型指南与系统级调试思路,帮助工程师优化内存性能与稳定性。

weixin_29219189的博客 368

Picasso,Glide,Fresco对比分析

前言 图片加载是Android开发中最最基础的功能,同时图片加载OOM也一直困扰着很多开发者,因此为了降低开发周期和难度,我们经常会选用一些图片加载的开源库。 老牌的有ImageLoader,UIL,Volley,主流的有,Picasso,Glide,Fresco等等,选择一款好的图片加载裤就成了我们的首要问题。 接下来我们对比一下主流的三款 Picasso,Glide,Fr

李彬博客专栏 2万+

python中frida的安装+frida-server(雷电模拟器)保姆级安装教程

frida的安装,安卓逆向,adb

2301_80224944的博客 4580

ZY1-02D (ZY1E)多光谱数据预处理

资源一号02D卫星(5米光学卫星)于2019年9月12日成功发射,卫星搭载的两台相机,可有效获取115公里幅宽的9谱段多光谱数据以及60公里幅宽的166谱段高光谱数据,其中全色谱段分辨率可达2.5米、 多光谱为10米、高光谱优于30米,高光谱载荷可见近红外和短波红外光谱分辨率分别达到10纳米和20纳米。

热爱分享,热爱记录 4830

Glide 4源码分析(一)

Glide 4 源码分析: 本想写一篇Glide 源码分析, 发现大佬写的不错了, 特此记录: 转自: https://blog.youkuaiyun.com/nbsp22/article/details/80666592 Glide.with(this) .load("https://p.upyun.com/docs/cloud/demo.jpg") ....

sfhong2008的专栏 565

基于咸鱼最新九宫格图标验证码的语义增强模型识别

本文探讨了破解复杂验证码的技术思路,重点分析了某平台的九宫格验证码应对策略。作者提出通过图像语义抽取和增强技术来扩充数据集:先采集少量真实样本,利用形态学操作进行前增强生成变形图像,再通过叠加背景噪声进行后增强。同时强调真实数据集的重要性,建议采用真实+生成数据的混合训练方法。实验表明该方法可使模型准确率达到95%以上,但作者特别声明本文仅供技术研究,严禁用于非法用途。

码王吴彦祖的博客 601

Glide源码分析之Glide的整体加载流程

  大家应该都听说过Glide图片加载库,或多或少都知道怎么去使用Glide去加载一张图片。Glide对于使用者来说是非常友好的一个库。那么今天我们就来学习Glide的源码,网上也有很有优秀的博客讲解Glide的源码的,现在我们一起来学习Glide的源码。这个优秀的框架是怎么帮助我们实现图片的加载和显示的。很多人看源码都不知道从哪里下手。这篇博客也分享一下我平时是怎么看源码的。这是基于Glide:4.10版本的源码分析   首先我们平时是怎么使用Glide的? Glide.with(context).loa

weixin_37873786的博客 1109

[毕设项目-MCP+ENSP]一句话搞定ENSP自动化:MCP + LLM实战(架构图、工具清单、踩坑全解)

用 MCP + LLM 把“人话”变成对华为 ENSP 的安全自动化操作,三款工具覆盖配置/查询/落盘,配套架构、实战与排坑清单。

逐梦苍穹的博客 2539

芒果YOLO11改进106:检测头篇DynamicHead动态检测头:基于DynamicHead,二次原创提出SATNeXt模块,提出全新的动态DynamicSatDetect

检测头篇DynamicHead动态检测头:基于DynamicHead,二次原创提出SATNeXt模块,提出全新的动态DynamicSatDetect

包括YOLOv5、YOLOv7、YOLOv8等模型改进 773

Glide的缓存机制原理分析

一、Glide请求图片的流程 当执行 Glide.with(this).load("").into(imageview)的into方法时候,该方法接收一个Target或者一个ImageView,Target是一个接口,默认的实现类包括SimpleTarget,ViewTarget,ImageViewTarget等,如果传递的是ImageView接下来回执行以下几步: 调用RequestBuil...

一杯清泉 3960

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

android glide代码,Android Glide 源码分析和学习

1.引言最近在开发产品过程中,项目经理提了一个问题:"为什么图片加载这么缓慢?",我看了看的确非常缓慢,图片加载用的经典的Glide框架,慢难道仅仅只是网络的原因?带着这份不解,我下了一个glide源码,开启了学习之路。2.正题通过学习想彻底弄懂这几个问题:Glide加载流程Glide切换Activity,是否有中断和恢复操作Glide的内存管理Glide的弱网管理机制2.1 Glide总体加载流...

weixin_36365168的博客 352

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

RU DOS版、EFI版32bit/64bit BIOS常用工具

DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。

Glide源码分析 一

Glide的源码分析 一

ivyxjc的博客 1371

jdk-8u144-linux-x64.tar.gz.

该资源为搭建Linux系统Java环境用,资源的后缀为tar.gz格式的压缩包

Glide——缓存分析整理

文章目录LruCache概述原理DiskLruCache概述Glide缓存概述资源分类缓存设计Glide 缓存源码分析1、生成key2、创建缓存对象LruResourceCache3、获取内存缓存中的图片4、开启加载图片线程5、获取磁盘缓存6、写入磁盘7、写入内存缓存写入弱引用缓存写入LruCache LruCache 概述 LruCache是Android 3.1所提供的一个缓存类,所以在And...

PdKingLiu 2051
上一篇: Android上下文Context的那些小事
下一篇: Kotlin学习(一)—Kotlin的泛型
Coding-ls
博客等级 码龄11年 41粉丝 61原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值