Glide的缓存机制原理分析

一、Glide请求图片的流程

当执行 Glide.with(this).load("").into(imageview)的into方法时候，该方法接收一个Target或者一个ImageView，Target是一个接口，默认的实现类包括SimpleTarget，ViewTarget，ImageViewTarget等，如果传递的是ImageView接下来回执行以下几步：

1. 调用RequestBuilder的into方法，并且传递Imageview；
2. 判断ImageView是否含有tag;
3. 如果有tag则从tag中拿出来Request对象，调用begin方法；
4. 如果没有tag则给setTag，tag的值为本次请求的request对象;
5. 将请求加入到一个Map集合中；
6. 调用该的request.begin()方法;
7. 在begin方法中设置加载的生命周期，调用onSizeReady方法
8. 执行engine.load方法得到加载的status状态。

into - RequestBuilder -  target/iamgeview - buildRequest - obtainRequest - SingleRequest - begin - onSizeReady - Engine

 

二、Engine请求图片的流程

 public  LoadStatus load(…………………………省略参数…………………………) {
    //开始加载的时间毫秒值
    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
    //图片缓存的key，从这里可以看出影响key的参数非常多
    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;
  }

三、glide的缓存

Glide的缓存分为三级缓存：弱引用内存缓存，LurCatch内存缓存，磁盘缓存，从上面可以看出内存缓存的方法是loadFromMemory，磁盘缓存的方法是waitForExistingOrStartNewJob。

   private EngineResource loadFromMemory(EngineKey key, boolean isMemoryCacheable, long startTime) {
        if (!isMemoryCacheable) {
          return null;
        }
        //弱引用内存缓存
        EngineResource active = loadFromActiveResources(key);
        if (active != null) {
          if (VERBOSE_IS_LOGGABLE) {
            logWithTimeAndKey("Loaded resource from active resources", startTime, key);
          }
          return active;
        }
        //LurCatch内存缓存
        EngineResource cached = loadFromCache(key);
        if (cached != null) {
          if (VERBOSE_IS_LOGGABLE) {
            logWithTimeAndKey("Loaded resource from cache", startTime, key);
          }
          return cached;
        }

        return null;
   }

从上面的loadFromMemory方法中，可以发现首先读取的是弱引用内存缓存部分的内容，如果弱引用缓存中没有，然后读取的是LurCatch内存缓存，缓存的读取是根据key进行读取，key是一个接口重写了equals、hashCode、toString方法，key值和图片宽高，资源转化的class，以及其他配置信息相关，也就是只要图片中这些值的任意一个信息改变了，那么key就变了，缓存信息也就变了，虽然原始图片一样，但是展示的大图，小图，圆图是尺寸不一样，缓存的也不是一张图片了。在缓存key中内存缓存的是EngineKey，磁盘缓存的是DataCacheKey。

四、glide的内存缓存

Glide的内存缓存分为弱引用内存缓存和LruCatch内存缓存。

1、弱引用内存缓存

  @Nullable
  private EngineResource loadFromActiveResources(Key key) {
    EngineResource active = activeResources.get(key);
    if (active != null) {
      active.acquire();
    }
    return active;
  }

ActiveResources为glide的Map内存缓存管理类，提供了弱引用内存缓存的缓存，获取，清除等。如果读的内存缓存不为空，采用引用记数法acquired加1，当释放内存资源的时候acquired又减1。acquired的作用是的保证资源内存释放或者资源回收的正确性。下面通过get方法来看他是怎么获取的：

   @Nullable
   synchronized EngineResource get(Key key) {
      //第一步，通过key拿去Map集合弱引用数据
      ResourceWeakReference activeRef = activeEngineResources.get(key);
      if (activeRef == null) {
        return null;
      }
      //第二步，通过弱引用拿去资源数据
      EngineResource active = activeRef.get();
      if (active == null) {
        cleanupActiveReference(activeRef);
      }
      return active;
   }

可以看出弱引用内存内存缓存是通过两步走的：

第一步：通过key拿去Map集合弱引用数据，key为缓存的键，value为一个资源的弱引用，如果Map中没有，则返回空。

第二步：通过弱引用拿去资源数据，弱引用中没有，则从Map中移除该key，再返回该对象。

2、LruCatch内存缓存

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

Glide使用的LruCatch缓存不是原生的LruCatch，而是自定义的LruCatch，实现类为LruResourceCache，他管理了LruCatch内存缓存。如果LruCatch内存缓存资源存在则处理和上面的Map内存缓存一样，引用记数法acquired加1，在回收或者是放内存时候-1，同时将该资源放到内存缓存的Map集合中，以便于下次再从Map内存缓存中读取。下面看看具体如何读取LruCatch内存缓存：

  private EngineResource getEngineResourceFromCache(Key key) {、
    //移除之前的LruCatch缓存内存资源（为啥要移除没看明白）
    Resource cached = cache.remove(key);

    final EngineResource result;
    if (cached == null) {
      //LruCatch缓存为空，则表示没有缓存，走网络
      result = null;
    } else if (cached instanceof EngineResource) {
      //如果为EngineResource，则表示有内存缓存
      // Save an object allocation if we've cached an EngineResource (the typical case).
      result = (EngineResource) cached;
    } else {
      //其他情况，这重新创建EngineResource(自定义的EngineResource)
      result =
          new EngineResource<>(
              cached, /*isMemoryCacheable=*/ true, /*isRecyclable=*/ true, key, /*listener=*/ this);
  }

可以看出LruCatch内存缓存是通过两步走的，流程图如下：

第一步：获取到资源，移除之前的LruCatch缓存的资源。

第二步：如果资源不为空，则返回。

 

 

五、glide的磁盘缓存引入

磁盘缓存的默认目录：

String DEFAULT_DISK_CACHE_DIR = "image_manager_disk_cache";

默认大小：

int DEFAULT_DISK_CACHE_SIZE = 250 * 1024 * 1024;

配置选项：

• DiskCacheStrategy.NONE// 表示不缓存任何内容
• DiskCacheStrategy.DATA// 表示只缓存原始图片
• DiskCacheStrategy.RESOURCE// 表示只缓存转换过后的图片
• DiskCacheStrategy.ALL // 表示既缓存原始图片，也缓存转换过后的图片

当内存的两级缓存没拿到数据时候，会执行waitForExistingOrStartNewJob方法：

  private  LoadStatus waitForExistingOrStartNewJob(*******省略参数********) {
	//从EngineJob缓存Map集合中获取job任务
	//onlyRetrieveFromCache = true表示只从磁盘中获取，=false表示可以从网络中获取对应两个Map集合，根据key获取value
	EngineJob current = jobs.get(key, onlyRetrieveFromCache);
	if (current != null) {
	  //开启回调线程池，设置回调
	  current.addCallback(cb, callbackExecutor);
	  return new LoadStatus(cb, current);
	}
	//EngineJob：负责请求回调
	EngineJob engineJob =
		engineJobFactory.build(
			key,
			isMemoryCacheable,
			useUnlimitedSourceExecutorPool,
			useAnimationPool,
			onlyRetrieveFromCache);

	//DecodeJob：负责从缓存数据或原始源解码资源的类以及应用转换和转码
	DecodeJob decodeJob =
		decodeJobFactory.build(
			glideContext,
			model,
			key,
			signature,
			width,
			height,
			resourceClass,
			transcodeClass,
			priority,
			diskCacheStrategy,
			transformations,
			isTransformationRequired,
			isScaleOnlyOrNoTransform,
			onlyRetrieveFromCache,
			options,
			engineJob);

	//将请求任务放到Map里面
	jobs.put(key, engineJob);
	//开启缓存线程池
	engineJob.addCallback(cb, callbackExecutor);
	//开启网络请求线程池
	engineJob.start(decodeJob);

	return new LoadStatus(cb, engineJob);
  }

磁盘缓存有两个关键类EngineJob和DecodeJob，其中EngineJob负责回调部分，DecodeJob负责磁盘读取和网络请求的编码和解码部分。二者的创建是采用工厂设计模式从缓存池里面读取的，缓存池pool的最大容量为150，数据结构为数组。步骤如下：

1、从Map>缓存Map集合中根据key获取job任务，如果不为空则开启回调线程线程池设置回调，资源不为空则执行onResourceReady方法。

2、如果EngineJob缓存为空，创建DecodeJob和EngineJob，将EngineJob添加到缓存集合中，一并交给DecodeJob，开启资源加载线程池，进行磁盘缓存加载或者网络请求。流程如下：

engineJob.start(decodeJob) -> DecodeJob.run() -> runWrapped() -> startNext()

六、glide的磁盘缓存过程

首次进来runReason默认为INITIALIZE，调用runWrapped如下：

	private void runWrapped() {
		switch (runReason) {
		  //首次进来执行，默认数据执行完毕之后，status = RESOURCE_CACHE； currentGenerator = ResourceCacheGenerator
		  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);
		}
	}

currentGenerator.startNext()这里不在详细深入了，主要是加载数据，对应的接口是DataFetcherGenerator三个实现类分别是：

• ResourceCacheGenerator：从缓存的显示数据中通过startNext获取
• DataCacheGenerator：从缓存的原始数据中通过startNext获取
• SourceGenerator：从网络数据中通过startNext获取

runGenerators是一个while循环，默认首次进执行ResourceCacheGenerator的startNext方法，如果获取失败，通过getNextStage改变status的值为DATA_CACHE，同时currentGenerator = DataCacheGenerator，在执行DataCacheGenerator的startNext，如果再返回失败status的值为SOURCE，currentGenerator = SourceGenerator执行到这里满足条件退出循环。

    private void runGenerators() {
        boolean isStarted = false;
        while (!isCancelled
            && currentGenerator != null
            && !(isStarted = currentGenerator.startNext())) {
          stage = getNextStage(stage);
          currentGenerator = getNextGenerator();

          if (stage == Stage.SOURCE) {
            reschedule();
            return;
          }
        }
    }

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

退出循环之前这时候执行reschedule方法，设置任务的RunReason是SWITCH_TO_SOURCE_SERVICE，触发回调Callback的reschedule方法，EngindJob实现此回调接口， 再次调用向线程池派发该DecodeJob任务：

   @Override
   public void reschedule(DecodeJob job) {
     getActiveSourceExecutor().execute(job);
   }

即再次执行runWrapped方法，这时候currentGenerator = SourceGenerator，runReason = SWITCH_TO_SOURCE_SERVICE，会在此执行SourceGenerator的startNext方法，如下：

    @Override
    public boolean startNext() {
        //第二次执行时候进行缓存
        if (dataToCache != null) {
            Object data = dataToCache;
            dataToCache = null;
            cacheData(data);
        }
        //缓存成功后，return不执行网络请求了。
        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;
    }

第一次网络请求时候，在loadData中具体的请求是由XxxFetcher（HttpUrlFetcher等）中的loadData方法进行请求，在4.10.0版本时使用的HttpURLConnection进行获取图片资源Stream的，当获取成功时候会调用callback.onDataReady(result);callback为SourceGenerator中的监听接口，将结果返回给SourceGenerator方法中的onDataReady，同时数据保存在SourceGenerator内部 dataToCache变量中，接着第二次触发reschedule()方法：

  @Override
  public void onDataReady(Object data) {
	DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
	if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
	 //数据保存在SourceGenerator内部
	  dataToCache = data;
	  //再次触发DecodeJob中的reschedule
	  cb.reschedule();
	} else {
	  cb.onDataFetcherReady(
		  loadData.sourceKey,
		  data,
		  loadData.fetcher,
		  loadData.fetcher.getDataSource(),
		  originalKey);
	}
  }

次执行runWrapped方法，和上面的一样，会在此执行SourceGenerator的startNext方法，这时候dataToCache已经有数值了，这时候才会调用cacheData(data);方法进行缓存，这块才是Glide设置缓存的地方。

    private void cacheData(Object dataToCache) {
        long startTime = LogTime.getLogTime();
        try {
          //创建缓存内容
          Encoder