Glide使用（四）缓存机制

最新推荐文章于 2024-09-21 17:24:19 发布
最新推荐文章于 2024-09-21 17:24:19 发布
阅读量2.9k 收藏 5
点赞数 1
分类专栏： github开源项目
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mingyunxiaohai/article/details/80174923
版权

本篇基于Glide4.6.1
前面的两篇文章走了一遍glide的请求网络图片并加载的流程，分析一个图片加载框架，其缓存机制是必须要知道的，一个完善的图片加载框架一般都包含内存缓存和硬盘缓存两种缓存策略。他们的作用各不相同，内存缓存主要是防止应用重复的把数据读到内存中，而硬盘缓存主要是防止应用重复的去网络上下载图片。这样才能让框架加载图片的速度更快，也能更省流量。下面就来看一下glide的缓存机制。

内存缓存

在内存缓存方面glide使用了两种方式，一个是我们常用的LruCache算法另一个是WeakReference弱引用的方式。下面看一下代码。代码在引擎类Engine的load方法中

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 = LogTime.getLogTime();

    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 (Log.isLoggable(TAG, Log.VERBOSE)) {
        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 (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Loaded resource from cache", startTime, key);
      }
      return null;
    }

    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      current.addCallback(cb);
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        logWithTimeAndKey("Added to existing load", startTime, key);
      }
      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);
    engineJob.start(decodeJob);

    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      logWithTimeAndKey("Started new load", startTime, key);
    }
    return new LoadStatus(cb, engineJob);
  }

（1） 首先根据很多的参数创建出一个key。这个key就是缓存存取的时候使用的key，之所以使用这么多参数创建，也是为了这个key的准确性，比如同一张图片我们给它的长宽不一样，所生成的key就不一样认为是两张图片。
（2） 然后 EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);先从弱引用中取图片 active可以翻译成活动，其实弱引用中缓存的图片是我们现在正在使用的图片，之所以多出来这个弱引用缓存主要为了当前使用的图片过多的时候可以防止这些图片被LruCache算法回收掉。进入loadFromActiveResources方法

@Nullable
  private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) {
    if (!isMemoryCacheable) {
      return null;
    }
    EngineResource<?> active = activeResources.get(key);
    if (active != null) {
      active.acquire();
    }

    return active;
  }

这里调用了一个get方法获取EngineResource

  @Nullable
  EngineResource<?> get(Key key) {
    ResourceWeakReference activeRef = activeEngineResources.get(key);
    if (activeRef == null) {
      return null;
    }

    EngineResource<?> active = activeRef.get();
    if (active == null) {
      cleanupActiveReference(activeRef);
    }
    return active;
  }

这里调用了activeEngineResources的get方法，看看activeEngineResources

 final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();

可以看到activeEngineResources就是一个HashMap，内部存的就是我们的弱引用对象。弱引用中保存了我们的资源对象EngineResource。
（3）如果在弱引用中取出的资源不为null，就直接回调放回结果，否则就去LruCache缓存中取EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);进入到loadFromCache方法

 private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
    if (!isMemoryCacheable) {
      return null;
    }
    EngineResource<?> cached = getEngineResourceFromCache(key);
    if (cached != null) {
      cached.acquire();
      activeResources.activate(key, cached);
    }
    return cached;
  }

这里面调用getEngineResourceFromCache传入key值来获取资源

 private EngineResource<?> getEngineResourceFromCache(Key key) {
    Resource<?> cached = cache.remove(key);
    final EngineResource<?> result;
    if (cached == null) {
      result = null;
    } else if (cached instanceof EngineResource) {
      result = (EngineResource<?>) cached;
    } else {
      result = new EngineResource<>(cached, true /*isMemoryCacheable*/, true /*isRecyclable*/);
    }
    return result;
  }

这里的cache可以去Engine类创建的地方看到传入的是LruResourceCache对象，而LruResourceCache继承了LruCache，所以我们知道这是在LruCache中取资源。取完之后删除这资源并返回，回到loadFromCache方法中，activeResources.activate(key, cached);把取到的资源在存在弱引用的缓存中。

OK这就是从内存中读取图片的逻辑，如果从两种内存缓存的方式中都没有得到资源，那就只好开启线程去硬盘上读取或者去网络上读取了。硬盘缓存等会再说，下面看看内存缓存是什么时候存进去的。

按照我们的正常逻辑，缓存应该是在图片加载完之后，把图片缓存，上一篇我们知道，图片加载完后会进入到EngineJob的onResourceReady方法中通过发送handler去主线程中执行

  void handleResultOnMainThread() {
    stateVerifier.throwIfRecycled();
    if (isCancelled) {
      resource.recycle();
      release(false /*isRemovedFromQueue*/);
      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);
    hasResource = true;

    // Hold on to resource for duration of request so we don't recycle it in the middle of
    // notifying if it synchronously released by one of the callbacks.
    engineResource.acquire();
    listener.onEngineJobComplete(this, key, engineResource);

    //noinspection ForLoopReplaceableByForEach to improve perf
    for (int i = 0, size = cbs.size(); i < size; i++) {
      ResourceCallback cb = cbs.get(i);
      if (!isInIgnoredCallbacks(cb)) {
        engineResource.acquire();
        cb.onResourceReady(engineResource, dataSource);
      }
    }
    // Our request is complete, so we can release the resource.
    engineResource.release();

    release(false /*isRemovedFromQueue*/);
  }

里面有一个方法listener.onEngineJobComplete(this, key, engineResource);传入了key和resource进入这个方法中可以看到

  public void onEngineJobComplete(EngineJob<?> engineJob, Key key, EngineResource<?> resource) {
    Util.assertMainThread();
    // A null resource indicates that the load failed, usually due to an exception.
    if (resource != null) {
      resource.setResourceListener(key, this);

      if (resource.isCacheable()) {
        activeResources.activate(key, resource);
      }
    }

    jobs.removeIfCurrent(key, engineJob);
  }

这里就可以看到把这个resource保存在了弱引用缓存activeResources中。ok弱引用缓存完毕，那什么时候保存到Lru缓存中呢，看handleResultOnMainThread中最后engineResource.release();方法

void release() {
    if (acquired <= 0) {
      throw new IllegalStateException("Cannot release a recycled or not yet acquired resource");
    }
    if (!Looper.getMainLooper().equals(Looper.myLooper())) {
      throw new IllegalThreadStateException("Must call release on the main thread");
    }
    if (--acquired == 0) {
      listener.onResourceReleased(key, this);
    }
  }

里面调用了onResourceReleased方法

  public void onResourceReleased(Key cacheKey, EngineResource<?> resource) {
    Util.assertMainThread();
    activeResources.deactivate(cacheKey);
    if (resource.isCacheable()) {
      cache.put(cacheKey, resource);
    } else {
      resourceRecycler.recycle(resource);
    }
  }

可以看到在这里我们把资源保存在了Lru缓存中了。

上面的handleResultOnMainThread() 方法中我们看到在弱引用缓存之前调用了 engineResource.acquire();方法最后调用了engineResource.release() ; engineResource是我们的图片资源的包装对象。acquire();和release() ;方法都是对齐成员变量acquired的操控acquire();是给acquired加一和release() ;是给acquired减一。当acquired大于0的时候说明这个图片我们正在使用，当他等于0的时候，说明不现在没使用可以存在LruCache中。

硬盘缓存

跟上面一样，先看一在哪里取的。操作硬盘也是个耗时的操作，所以会在工作线程中执行，上一篇中我们知道DecodeJob就是我们的Runnable对象既工作线程，我们直接去它的run方法中

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

runReason在类初始化的时候赋值INITIALIZE，所以从INITIALIZE开始stage = getNextStage(Stage.INITIALIZE);判断我们从哪里去取如果是去磁盘取返回ResourceCacheGenerator
INITIALIZE：第一次加载的时候
SWITCH_TO_SOURCE_SERVICE：从硬盘缓存中取
DECODE_DATA：解析从网络加载完的数据
我们进入ResourceCacheGenerator的startNext()方法

  public boolean startNext() {
    List<Key> sourceIds = helper.getCacheKeys();
    if (sourceIds.isEmpty()) {
      return false;
    }
    List<Class<?>> resourceClasses = helper.getRegisteredResourceClasses();
    if (resourceClasses.isEmpty()) {
      if (File.class.equals(helper.getTranscodeClass())) {
        return false;
      }
      throw new IllegalStateException(
          "Failed to find any load path from " + helper.getModelClass() + " to "
              + helper.getTranscodeClass());
    }
    while (modelLoaders == null || !hasNextModelLoader()) {
      resourceClassIndex++;
      if (resourceClassIndex >= resourceClasses.size()) {
        sourceIdIndex++;
        if (sourceIdIndex >= sourceIds.size()) {
          return false;
        }
        resourceClassIndex = 0;
      }

      Key sourceId = sourceIds.get(sourceIdIndex);
      Class<?> resourceClass = resourceClasses.get(resourceClassIndex);
      Transformation<?> transformation = helper.getTransformation(resourceClass);
      // PMD.AvoidInstantiatingObjectsInLoops Each iteration is comparatively expensive anyway,
      // we only run until the first one succeeds, the loop runs for only a limited
      // number of iterations on the order of 10-20 in the worst case.
      currentKey =
          new ResourceCacheKey(// NOPMD AvoidInstantiatingObjectsInLoops
              helper.getArrayPool(),
              sourceId,
              helper.getSignature(),
              helper.getWidth(),
              helper.getHeight(),
              transformation,
              resourceClass,
              helper.getOptions());
      cacheFile = helper.getDiskCache().get(currentKey);
      if (cacheFile != null) {
        sourceKey = sourceId;
        modelLoaders = helper.getModelLoaders(cacheFile);
        modelLoaderIndex = 0;
      }
    }

    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);
      loadData = modelLoader.buildLoadData(cacheFile,
          helper.getWidth(), helper.getHeight(), helper.getOptions());
      if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {
        started = true;
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }

    return started;
  }

可以看到cacheFile = helper.getDiskCache().get(currentKey);

  @Override
  public File get(Key key) {
    String safeKey = safeKeyGenerator.getSafeKey(key);
    if (Log.isLoggable(TAG, Log.VERBOSE)) {
      Log.v(TAG, "Get: Obtained: " + safeKey + " for for Key: " + key);
    }
    File result = null;
    try {
      final DiskLruCache.Value value = getDiskCache().get(safeKey);
      if (value != null) {
        result = value.getFile(0);
      }
    } catch (IOException e) {
      if (Log.isLoggable(TAG, Log.WARN)) {
        Log.w(TAG, "Unable to get from disk cache", e);
      }
    }
    return result;
  }

可以看到这里就是从DiskLruCache硬盘缓存中取了DiskLruCache.Value value = getDiskCache().get(safeKey);OK取的方法已经找到，下面开始看一下什么时候存的。

首先我们想一下存的时候肯定是图片从网络中获取之后才能存，所以去网络获取成功之后的地方上一篇我们知道请求完之后会进入

 public void onDataReady(Object data) {
    DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
    if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
      dataToCache = data;
      // We might be being called back on someone else's thread. Before doing anything, we should
      // reschedule to get back onto Glide's thread.
      cb.reschedule();
    } else {
      cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
          loadData.fetcher.getDataSource(), originalKey);
    }
  }

这里判断了我们的缓存策略，缓存策略我们从开始初始化的时候可以配置

  RequestOptions options = new RequestOptions()
                .placeholder(R.mipmap.ic_launcher)//加载成功之前占位图
                .error(R.mipmap.ic_launcher)//加载错误之后的错误图
                .override(400,400)//指定图片的尺寸
                .fitCenter()//指定图片的缩放类型为fitCenter （等比例缩放图片，宽或者是高等于ImageView的宽或者是高。）
                .centerCrop()//指定图片的缩放类型为centerCrop （等比例缩放图片，直到图片的狂高都大于等于ImageView的宽度，然后截取中间的显示。）
                .circleCrop()//指定图片的缩放类型为centerCrop （圆形）
                .skipMemoryCache(true)//跳过内存缓存
                .diskCacheStrategy(DiskCacheStrategy.ALL)//缓存所有版本的图像
                .diskCacheStrategy(DiskCacheStrategy.NONE)//跳过磁盘缓存
                .diskCacheStrategy(DiskCacheStrategy.DATA)//只缓存原来分辨率的图片
                .diskCacheStrategy(DiskCacheStrategy.RESOURCE)//只缓存最终的图片

最后几句我们配置了我们的硬盘缓存策略，以后硬盘缓存就按照这些策略来。

在回到onDataReady中，如果我们允许缓存就给dataToCache 字段赋值，然后下一句cb.reschedule()

 public void reschedule() {
    runReason = RunReason.SWITCH_TO_SOURCE_SERVICE;
    callback.reschedule(this);
  }

进入 callback.reschedule(this);中

 public void reschedule(DecodeJob<?> job) {
    getActiveSourceExecutor().execute(job);
  }

可以看到更改runReason为SWITCH_TO_SOURCE_SERVICE然后又执行线程里的工作，所以又会回到run()方法中执行 runGenerators()

  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;
        loadData.fetcher.loadData(helper.getPriority(), this);
      }
    }
    return started;
  }

因为dataToCache 不为null，第一判断就可以进入cacheData(data);方法中了

 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());
      originalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());
      helper.getDiskCache().put(originalKey, writer);
    } finally {
      loadData.fetcher.cleanup();
    }

    sourceCacheGenerator =
        new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);
  }

这里就可以看到保存到硬盘中啦helper.getDiskCache().put(originalKey, writer);

Ok 啦glide的缓存流程就分析完啦。

Glide缓存机制
在路上-codingAndlearning
01-11 9118
Glide缓存机制 Glide缓存非常先进，很灵活，很全面，总体上来讲有内存缓存和磁盘文件缓存。缓冲机制概括来讲就是读缓存以及是写入缓存的机制。而Glide读缓存时机就是先内存缓存查找再到磁盘缓存查找最后网络，写入缓存则就是在获取到原始source图片之后，先写入磁盘缓存，再加入内存缓存。 每个缓存查找都是通过key来查询，一般都是直接用下载url来作为key，那Glide的key呢。直接看下
【Android面试八股文】谈谈你对Glide框架的缓存机制设计的理解
字节卷动
07-13 355
除了内存缓存，Glide还使用磁盘缓存来长期存储图像数据。磁盘缓存有助于避免每次应用启动时都重新下载图片，提升用户体验和节省网络带宽。磁盘缓存默认使用Android的来实现，它将图像数据存储在设备的持久存储中，例如内部存储或外部存储（SD卡）。当谈到自定义缓存时，我们通常指的是根据特定需求修改或扩展现有框架（如GlidePicasso等）的缓存行为，以优化应用程序的性能和用户体验。下面我会详细说明如何在使用Glide时实现自定义缓存。Glide默认使用LRU（最近最少使用）
字节Android岗面试必问：Glide的缓存机制，金三银四旗开得胜
m0_61417997的博客
09-08 668
} if (decodeFormat == null) { decodeFormat = DecodeFormat.DEFAULT; } return new Glide(engine, memoryCache, bitmapPool, context, decodeFormat); } } 这里也就是构建Glide对象的地方了。那么观察第22行，你会发现这里new出了一个LruResourceCache，并把它赋值到了memoryCache这个对象上面...
Glide 缓存机制
jiang19921002的博客
01-22 7709
Glide缓存分为 内存缓存 和 硬盘缓存。 这两个缓存模块的作用各不相同，内存缓存 的主要作用是防止应用重复将图片数据读取到内存当中，而 硬盘缓存 的主要作用是防止应用重复从网络或其他地方重复下载和读取数据。 缓存key 那么Glide的缓存Key是怎么生成的呢？我不得不说，Glide的缓存Key生成规则非常繁琐，决定缓存Key的参数竟然有10个之多。不过繁琐归繁琐，至少逻辑还是比较简单的，...
Android Glide 缓存机制及源码全解_android glide lru
最新发布
2401_87287188的博客
09-21 548
因为内存缓存使用LRU算法，当你使用Gilde加载并显示第一张图片时，后面又加载了很多图片，同时你的第一张图片还在用。LruCache的核心思想很好理解，就是要维护一个缓存对象列表，其中对象列表的排列方式是按照访问顺序实现的，即一直没访问的对象，将放在队尾，即将被淘汰。LRU是近期最少使用的算法(缓存淘汰算法)，它的核心思想是当缓存满时，会优先淘汰那些近期最少使用的缓存对象。Glide 主要将缓存分为两块内存缓存和硬盘缓存，两种缓存的结合，构成了 Glide 缓存机制的核心。咱继续往下走，顺着源码跑。
Glide 4.4+缓存机制原理
baliang8的博客
04-21 548
介绍 在上一篇中，我们知道了 Glide 框架的最基本的执行流程，那么只知道基本执行流程，这显然是不够的，我们要深挖 Glide 框架的细节处理原理，比如缓存机制，图片处理等，这一篇我们就一起去探索 Glide 的缓存机制。 Glide 缓存机制可以说是设计的非常完美，考虑的非常周全，下面就以一张表格来说明下 Glide 缓存。 缓存类型 缓存代表 说明 活动缓存 ActiveResources 如果当前对应的图片资源是从内存缓存中获取的，那么会将这个图片存储到活动资源中。
浅谈Glide缓存key的问题
08-27
四、Glide缓存机制 Glide缓存机制分为两个阶段，首先是从缓存中加载图片，如果缓存中没有找到图片，则从源数据中加载图片。Glide缓存机制可以大大提高图片加载的效率，减少网络请求的次数。 五、EngineRunnable和...
android glide不缓存,Glide中的缓存
weixin_36332394的博客
06-02 1722
本文主要介绍了如何配置和管理Glide中的缓存，其中大部分内容都可以直接在官方Wiki中找到，这里只是进行了整理和汇总。言归正传，Glide支持图片的二级缓存(并不是三级缓存，因为从网络加载并不属于缓存)，即内存缓存和磁盘缓存。磁盘缓存一般的图片缓存指的就是磁盘缓存，把网络上的图片缓存到本地，这样就不需要每次都从网络加载，既提高了加载速度，又为用户节省了流量。Glide在默认情况下是开启磁盘缓存的...
Android-Glide原理缓存加载
12-18
Glide原理解析，手写Glide框架。视频教程。 Glide三级缓存原理 Glide源码解析 相关算法讲解
Glide 的缓存机制
lollo01的博客
01-20 339
Glide 的缓存机制，需要了解 LruCache 和 DiskLruCache,可以参考以下两篇博文 https://blog.csdn.net/guolin_blog/article/details/28863651 下面我们通过写一个阉割版的Glide来了解一下Glide的缓存机制 首先看一下Glide的一行代码经典用法 private final String IMAGE_URL = "http://p1.pstatp.com/large/166200019850062839d3";
glide内存缓存机制
darwin12148888的博客
08-02 2206
https://www.jianshu.com/p/a751d0b855d1 1）首先Glide内存缓存采用了2种策略，弱引用缓存和LRU算法内存缓存（2）弱引用缓存就是把图片的弱引用缓存在一个HashMap中，被下载使用的图片首先会缓存在这个弱引用HashMap中。Glide会通过引用计数的方式来记录图片被引用的次数，当引用次数为0时，也就意味着图片资源不再被使用嘛，这时就会将图片资源从这个弱引...
Glide（四）内存缓存
Applicaton的专栏
09-28 499
内存缓存 前引声明 上文中我们知道Glide内存缓存通过两部分组成又叫做运行时缓存 LruCache -》MemoryCache cache 实现类是LruResourceCache在创建Glide的时候创建，大小为屏幕大小的两张图片 采用LruCache实现，遵循最近最少使用原则，当缓存大小达到设定缓存大小时将最近使用的最少的缓存对象清除 其内部维护了一个LinkedHashMap 将 缓存对象的强引用缓存 该缓存只存储当前没在使用的资源 弱引用缓存（活动缓存）-》Map<Key,
Glide源码--缓存机制
Egypt_nova
11-05 213
Glide在缓存功能上也是分成了两个模块，一个内存缓存，一个硬盘缓存。内存缓存的主要作用是防止应用重复将图片数据读取到内存当中，硬盘缓存的主要作用是防止应用重复从网络或其他地方重复下载和读取数据。 缓存的图片资源 分为两类：原始图片和转换后的图片（经过尺寸缩放和大小压缩等处理后的图片） 内存缓存只缓存转换过后的图片，而硬盘缓存可缓存原始图片和转换过后的图片，用户自行设置 缓存key 决定缓存key...
安卓开发中Glide的缓存机制
m0_66843126的博客
06-28 1528
在使用Glide加载图片时，Glide会在一个新的图片请求之前检查再决定是否需要在原始资源数据中取出资源常用算法——算法是一种常用的缓存逐出策略，用于在内存受限的情况下管理缓存。当缓存达到其最大容量时，LRU算法会淘汰，以便为新项腾出空间。
Glide缓存策略详解：内存与磁盘缓存控制
在Android应用开发中，图片加载是一个关键环节，而Glide作为一款流行的图片加载库，提供了高效且灵活的缓存管理机制。本篇文章将深入探讨如何通过Glide设置缓存策略，包括跳过内存缓存、设定磁盘缓存策略以及清理...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值