Glide获取图片缓存文件名Key

最近项目由于需要支持gif动图，所以把图片加载框架由 ImageLoader 切换到 glide ，因为需要支持长按保存图片，所以就需要找到 glide 加桥搭帆载后缓存的图片路径。

根据网上资料，最终找到 Glide 最终生成path的路径为： /data/枝没data/your_packagexxxxxxx/cache/image_manager_disk_cache

对应的生成规则： com.bumptech.glide.load.engine.EngineKey#updateDiskCacheKey

问题转换为：获取url到缓存文件path的生成规则算法上

直接把获取函数贴出敏雹来：

由 Glide源码分析二——Request相关 可知，SingleRequest#onSizeReady(w,h)可知是通过Engine来加载图片的。滚察散

Engine是在GlideBuilder#build(context)构造Glide时，new出来传给Glide的。之后在RequestBuilder创建SingleRequest时通过GlideContext.getEngine()获取Engine并传给SingleRequest.

DocodeJob主要是根据不同的Stage获取不同的DataFetcherGenerator，不同的DataFetcherGenerator可以得到不同的DataFetcher，DataFetcher是用来请求数据的。

获取数据成功之后，会使用DecodePath中保存的Decoder、Transcoder进行解码 *** 作，得到最终数据。

其中Decoder解码成功后会回调DecodeCallback#onResourceDecoded(Resource<Z>decoded)，在该回调中会使用Transformation#transform(...)进行变换 *** 作，之后会调用DeferredEncodeManager#init(...)将变换后的数据保存起来。 最后在Transcoder解码完成后会在notifyEncodeAndRelease(...)中调用DeferredEncodeManager#encode(...)缓存变换后的数据。

DataFetcherGenerator有3个子类，逐级尝试获取数据：

这里分析下ResourceCacheGenerator吧：

DataCacheGenerator和SourceCacheGenerator也差不多，只是SourceCacheGenerator获取到数据之后会根据Engine#load(...)中设置的diskCacheStrategy来缓存数据。

DataCacheWriter是个包装类，实际还是通过Encoder在缓存数据的：

随便看一个Encoder的实现吧：

由DecodeJob章节可以知道，通过Generator获取数据成功后，会通过LoadPath/DecodePath进行解码。

LoadPath相当于代理类，内部使用DecodePath来完成解码 *** 作。

由DecodeJob章节可以知道，数据解码成大氏功后，会通过DeferredEncodeManager进行缓存，它是DecodeJob的内部类。

它其实是个辅助类，实际的缓存工作是由ResourceEncoder完成的。

DecodeHelper是一个辅助类，每个DecodeJob对没族应一个DecodeHelper，在DecodeJob#init(...)中进行初始化，为DecodeJob提供能够处理Model的ModelLoader、LoadData和对应的Key、DiskCache、DiskCacheStrategy、LoadPath、Transformation、以及缓存数据用的Encoder等。

最近在弄一个功能，其中别人已经写好了图片显示，是用把url转成了String格式的，但是我需要一侍团个bitmap格式来做图片保存，后来查看了正配Glide之后发现可以利用Glide把url加载出来获得bitmap资源。老清橘

Glide中加载之后into到一个simpleTarget<Bitmap>里就可以得到Bitmap资源了。

---