Glide-源碼分析(三)

正文

第一篇文章介紹了下第一次加載網(wǎng)絡(luò)圖片的流程。
第二篇文章介紹了下加載過圖片,然后重啟app,從磁盤加載圖片的流程。
這一篇介紹下,已經(jīng)加載過圖片,沒有重啟app,直接從內(nèi)存加載圖片。
我們這里說的加載圖片是指同一個url的圖片,不同的url就相當(dāng)于第一次加載,這里就不再贅述了。

雖然說是加載同樣的url的圖片。但是也是分很多種情況的。這邊舉3個例子,來分析。

  1. 相同的target,也可以簡單理解為相同的ImageView
  2. 不同的ImageView

相同的target

Glide.with(this).load("https://cdn2.jianshu.io/assets/web/nav-logo-4c7bbafe27adc892f3046e6978459bac.png").into(iv)

這里我們直接從into方法看起。

private <Y extends Target<TranscodeType>> Y into(
      @NonNull Y target,
      @Nullable RequestListener<TranscodeType> targetListener,
      @NonNull RequestOptions options) {
  ...
    Request request = buildRequest(target, targetListener, options);

    Request previous = target.getRequest();
    //由于之前第一次請求,所以當(dāng)前的request!=之前的request。
    //但是經(jīng)過一次請求后,再次請求一樣的url
    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;
  }

之前第一次請求的時候,判斷條件不成立,直接走requestManager.track(target, request);,而現(xiàn)在相同的target請求一樣的url,這里會再次構(gòu)建一個新的Request對象。而target也保存著之前請求過的Request對象。

//SingleRequest.java
 @Override
  public boolean isEquivalentTo(Request o) {
    if (o instanceof SingleRequest) {
      SingleRequest<?> that = (SingleRequest<?>) o;
      return overrideWidth == that.overrideWidth
          && overrideHeight == that.overrideHeight
          && Util.bothModelsNullEquivalentOrEquals(model, that.model)
          && transcodeClass.equals(that.transcodeClass)
          && requestOptions.equals(that.requestOptions)
          && priority == that.priority
          && listenerCountEquals(this, that);
    }
    return false;
  }

這里的Request對象其實是SingleRequest這里就不多介紹了。第二次請求,參數(shù)肯定還是跟第一次請求一致,所以返回true。當(dāng)然這里還有個判斷。

private boolean isSkipMemoryCacheWithCompletePreviousRequest(
      RequestOptions options, Request previous) {
    return !options.isMemoryCacheable() && previous.isComplete();
  }

看options中是否設(shè)置不支持內(nèi)存緩存以及之前的請求是否以及完成。

所以第二次相同的target加載圖片的話,會進(jìn)入if里面

  request.recycle();   
      if (!Preconditions.checkNotNull(previous).isRunning()) {
        previous.begin();
      }
      return target;
    }

把這一次生成的request對象回收后,開始請求之前的request

//SingleRequest.java
public void begin() {
  ...
    if (status == Status.COMPLETE) {
      onResourceReady(resource, DataSource.MEMORY_CACHE);
      return;
    }
....
  }

因為之前這個Request已經(jīng)請求過了,所以參數(shù)status==Status.COMPLETE。所以直接調(diào)用onResourceReady,沒有發(fā)起真正的請求。使用了之前緩存的。

不同的target

我們還是從前面的into方法開始,顯然不同的target肯定不會進(jìn)if語句里面了。還是走requestManager.track(target, request)。

這里讓大家更清楚點,就再完整的過一遍.

//RequestManager.java
 void track(@NonNull Target<?> target, @NonNull Request request) {
    ...
    requestTracker.runRequest(request);
  }

//RequestTracker.java
 public void runRequest(@NonNull Request request) {
   ...
      request.begin();
    ...
  }

//SingleRequest.java
public void begin() {
   ....
      target.getSize(this);
   ...
  }
//ViewTarget.java
public void getSize(@NonNull SizeReadyCallback cb) {
    sizeDeterminer.getSize(cb);
  }

//ViewTarget.java
void getSize(@NonNull SizeReadyCallback cb) {
      ...
        ViewTreeObserver observer = view.getViewTreeObserver();
        layoutListener = new SizeDeterminerLayoutListener(this);
        observer.addOnPreDrawListener(layoutListener);
      ...
    }

//SingleRequest.java
public void onSizeReady(int width, int height) {
    ...
    loadStatus = engine.load(...);
...
  }

//Engine.java
public <R> LoadStatus load(
     ...
    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;
    }

    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;
    }
...
  }

這里就直接把源碼貼出,給大家過一遍,就不一步步解析了,不太熟悉的同學(xué)可以看下第一篇文章。那么這邊就直接說出結(jié)果


EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
    if (active != null) {
      cb.onResourceReady(active, DataSource.MEMORY_CACHE);
     ...
      return null;
    }


private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) {
    ...
    EngineResource<?> active = activeResources.get(key);
  ...
    return active;
  }

其實就是直接從activeResources獲取到緩存的資源直接調(diào)用onResourceReady方法。

那么我們這里可以回溯下,activeResources是什么時候放入資源的呢。ctrl+鼠標(biāo)左鍵看下引用。

找到了2個地方,第一個地方很快就排除了。只剩下這一個,來看

//Engine.java
 public void onEngineJobComplete(EngineJob<?> engineJob, Key key, EngineResource<?> resource) {
   ...
      if (resource.isCacheable()) {
        activeResources.activate(key, resource);
      }
    }
...
  }

繼續(xù)找哪里調(diào)用onEngineJobComplete,也只有2個地方,有個地方?jīng)]有傳入resource引用直接排除。

//EngineJob.java
void handleResultOnMainThread() {
    ...
    listener.onEngineJobComplete(this, key, engineResource);
...
  }

public boolean handleMessage(Message message) {
      EngineJob<?> job = (EngineJob<?>) message.obj;
      switch (message.what) {
        case MSG_COMPLETE:
          job.handleResultOnMainThread();
        ...

看到這個MSG_COMPLETE 大家應(yīng)該很熟悉,可以去看下第一篇文章,最終加載好圖片之后,發(fā)送下這個消息。然后圖片就緩存再內(nèi)存里了。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容