如何解決Glide緩存key的問題

這篇文章主要為大家展示了“如何解決Glide緩存key的問題”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“如何解決Glide緩存key的問題”這篇文章吧。

最近項(xiàng)目里面有個(gè)地方是在前面用glide加載圖片后，后面再另外一個(gè)地方加載相同圖片時(shí)沒有復(fù)用glide的緩存，而是自己另外又重新緩存了一套。

查找后發(fā)現(xiàn)問題是glide緩存的key不一致的問題。

從key的生成可以看到和很多參數(shù)有關(guān)，逐一排查后，發(fā)現(xiàn)了width和height還有id不一樣。這3個(gè)是項(xiàng)目外面?zhèn)鬟M(jìn)來的。

EngineKey key = keyFactory.buildKey(id, signature, width, height, loadProvider.getCacheDecoder(),
        loadProvider.getSourceDecoder(), transformation, loadProvider.getEncoder(),
        transcoder, loadProvider.getSourceEncoder());

key的作用大概是通過下面三步里面去找數(shù)據(jù)

如果都為null，就會(huì)進(jìn)入函數(shù)最后邊的開線程去decode（相當(dāng)于緩存沒找到，準(zhǔn)備重新加載數(shù)據(jù)吧）

EngineJob engineJob = engineJobFactory.build(key, isMemoryCacheable);
    DecodeJob<T, Z, R> decodeJob = new DecodeJob<T, Z, R>(key, width, height, fetcher, loadProvider, transformation,
        transcoder, diskCacheProvider, diskCacheStrategy, priority);
    EngineRunnable runnable = new EngineRunnable(engineJob, decodeJob, priority);
    jobs.put(key, engineJob);
    engineJob.addCallback(cb);
    engineJob.start(runnable);

進(jìn)入EngineRunnable的run方法看

 resource = decode();
private Resource<?> decode() throws Exception {
    if (isDecodingFromCache()) {
      return decodeFromCache();
    } else {
      return decodeFromSource();
    }
  }

其中l(wèi)oadCache還是loadFromSource的條件

  private boolean isDecodingFromCache() {
    return stage == Stage.CACHE;
  }

默認(rèn)stage會(huì)進(jìn)去，走到decodeFromCache（），由于cache里沒有，返回null到run方法里面觸發(fā)加載失敗的回調(diào)

 if (resource == null) {
      onLoadFailed(exception);
    } else {
      onLoadComplete(resource);
    }

在回調(diào)中重新提交一個(gè)runnable，改變stage，下一次run執(zhí)行時(shí)，stage==source，就不會(huì)去loadCache，而是loadSource。（開線程加載大概流程感覺就像是默認(rèn)先去緩存中找，沒找到就重新加載）

private void onLoadFailed(Exception e) {
    if (isDecodingFromCache()) {
      stage = Stage.SOURCE;
      manager.submitForSource(this);
    } else {
      manager.onException(e);
    }
  }

loadSource會(huì)一路走到

 private Resource<T> decodeFromSourceData(A data) throws IOException {
    final Resource<T> decoded;
    if (diskCacheStrategy.cacheSource()) {
      decoded = cacheAndDecodeSourceData(data);
    } else {
      long startTime = LogTime.getLogTime();
      decoded = loadProvider.getSourceDecoder().decode(data, width, height);
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Decoded from source", startTime);
      }
    }

這里回調(diào)的decode就是項(xiàng)目中自己設(shè)置的sourceDecoder

項(xiàng)目?jī)?nèi)的代碼象征性的打碼：

之前id和寬高傳的不一樣，導(dǎo)致key不一樣，然后Glide加載的時(shí)候通過key找不到緩存，最后就又回調(diào)到項(xiàng)目里面的decode那里來了。

改完后，第一次decode完后，后面用緩存就不會(huì)再進(jìn)入decode了。

以上是“如何解決Glide緩存key的問題”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！