调研版本为4.7.1
为了更加简单的理解，会将函数代码简化，详细代码请自行照源码对比
Glide用法
Glide.with(...).load(...).into(...)
我们从into方法开始探寻之旅
开启加载线程
RequestBuilder.class
public Target into() {
Request request = buildRequest(...);
requestTracker.runRequest(request);
}
requestTracker是RequestTracker对象
RequestTracker.class
public void runRequest(Request request) {
request.begin();
}
request是SingleRequest对象
SingleRequest.class
public void begin() {
onSizeReady(...);
}
public void onSizeReady(...) {
engine.load(...)
}
engine是Engine类的对象
Engine.class
void load(...) {
engineJob.start(...)
}
engineJob是EngineJob类的对象
EngineJob.class
public void start(DecodeJob job) {
GlideExecutor executor = ... //创建线程池
executor.execute(job); //job是一个runnable对象，此语句开启线程
}
获取资源过程
上面我们知道了开启线程的过程，这个线程主要就是获取二进制流并且编码成资源文件，如Bitmap、Drawable等用来在Android中显示。
DecodeJob.class
//线程从run方法开始
public void run() {
runWrapped();
}
private void runWrapped() {
runGenerators();
}
private void runGenerators() {
currentGenerator = getNextGenerator();
//依次调用generator的startNext方法
//startNext返回值表示是否可以获得图片的二进制流
//如果generator能获取图片数据，那么就不需要下级的generator去尝试获取图片数据
while (!currentGenerator.startNext()) {
...
currentGenerator = getNextGenerator();
}
}
//第一次调用该方法返回ResourceCacheGenerator
//第二次返回DataCacheGenerator
//第三次返回SourceGenerator(本地没有缓存时使用，下载数据并放入缓存)
private DataFetcherGenerator getNextGenerator() {
switch (stage) {
case RESOURCE_CACHE:
return new ResourceCacheGenerator(decodeHelper, this);
case DATA_CACHE:
return new DataCacheGenerator(decodeHelper, this);
case SOURCE:
return new SourceGenerator(decodeHelper, this);
}
}
本例是一个imageView加载网络图，ResourceCacheGenerator的startNext为false，这样会调用DataCacheGenerator的startNext方法。
DataCacheGenerator.class
//startNext方法会通过循环所有的modelLoader分别调用buildLoadData方法
//如果所有modelLoader获取的loadData都为空那么就返回false
//这就意味着Glide将调用下一个Generator的startNext方法
//也就是SourceGenerator的startNext方法
public boolean startNext() {
Key originalKey = new DataCacheKey(sourceId, helper.getSignature());
File cacheFile = helper.getDiskCache().get(originalKey);
boolean started = false;
while (!started && hasNextModelLoader()) {
//我们自定义的ModelLoader就可以在这派上用场了
ModelLoader modelLoader = modelLoaders.get(modelLoaderIndex++);
ModelLoader.LoadData loadData = modelLoader.buildLoadData(...);
if (loadData != null) {
started = true;
//本例中ByteBufferFileLoader获取的loadData不为空
//本例中loadData.fetcher是ByteBufferFetcher的对象
loadData.fetcher.loadData(this);
}
}
return started;
}
ByteBufferFetcher.class
public void loadData(DataFetcher.DataCallback<? super ByteBuffer> callback) {
ByteBuffer result;
try {
result = ByteBufferUtil.fromFile(file);
} catch (IOException e) {
callback.onLoadFailed(e);
return;
}
callback.onDataReady(result);
}
这里的callback是DataCacheGenerator对象，该类实现了DataFetcher.DataCallback接口，所以此处回调到DataCacheGenerator类中的onDataReady方法
DataCacheGenerator.class
public void onDataReady(Object data) {
cb.onDataFetcherReady(sourceKey, data, loadData.fetcher, DataSource.DATA_DISK_CACHE, sourceKey);
}
cb是DecodeJob类对象
DecodeJob.class
public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,
DataSource dataSource, Key attemptedKey) {
//将二进制流解码成资源文件
decodeFromRetrievedData();
}
}
private void decodeFromRetrievedData() {
Resource<R> resource = null;
resource = decodeFromData(currentFetcher, currentData, currentDataSource);
if (resource != null) {
notifyEncodeAndRelease(resource, currentDataSource);
}
}
notifyEncodeAndRelease方法里主要是使用Handler回到主线程调用各种回调以及释放资源。至此，加载过程就分析完毕啦。
在上面我们已经完整的走过了一个加载流程，但是Glide缓存的文件是什么形式的呢？如果一个图片的url被Glide加载缓存过，我们是不是可以通过该url获取缓存文件呢？获取的缓存文件是不是还是.jpg、.png等图片形式的可以直接从手机提取到电脑呢？如果你有这些疑问，那就继续往下看吧~
Glide缓存机制
Glide默认缓存在 data/data/包名/cache/image_manager_disk_cache 文件夹下，并且缓存文件的文件名根本不能直观上和请求的图片URL所匹配：
类似这种021db417987c5c446d2042037c78e9d9c127432d5a8cdd2b58cd2a702fc917b3.0，后缀还是 .0 。是不是有点头大，让我们去看看文件名的生成规则吧。
Glide使用DiskLruCacheWrapper类进行缓存文件操作，我们主要看put和get方法，一个用于取缓存，一个用于存缓存。
DiskLruCacheWrapper.class
public File get(Key key) {
String safeKey = safeKeyGenerator.getSafeKey(key);
File result = null;
final DiskLruCache.Value value = getDiskCache().get(safeKey);
result = value.getFile(0);
return result;
}
public void put(Key key, DiskCache.Writer writer) {
String safeKey = safeKeyGenerator.getSafeKey(key);
DiskLruCache diskCache = getDiskCache();
DiskLruCache.Editor editor = diskCache.edit(safeKey);
File file = editor.getFile(0);
if (writer.write(file)) {
editor.commit();
}
}
safeKeyGenerator是SafeKeyGenerator类的对象，其getSafeKey方法主要通过图片url获取缓存文件名，getSafeKey需要传入一个Key对象，Key对象就包括了要加载的url。
SafeKeyGenerator.class
public String getSafeKey(Key key) {
return calculateHexStringDigest(key);
}
private String calculateHexStringDigest(Key key) {
return Util.sha256BytesToHex(container.messageDigest.digest());
}
这里打个断点让大家看看Key里都有什么成员变量
calculateHexStringDigest方法也很简单，就是对该URL使用SHA256加密算法加密
为了让大家理解，这里贴两张图，第一张图是将图片地址字符串进行加密计算结果图，第二张图是手机缓存文件夹图片
那么后缀 .0 是怎么生成的呢？
我们可以看到在调用DiskLruCacheWrapper的put函数保存缓存文件时有一句代码DiskLruCache.Editor editor = diskCache.edit(safeKey);
其中diskCache是DiskLruCache对象
DiskLruCache.class
private DiskLruCache.Editor edit(String key) {
DiskLruCache.Entry entry = lruEntries.get(key);
if (entry == null) {
entry = new DiskLruCache.Entry(key);
lruEntries.put(key, entry);
}
}
注意了，这里的lruEntries是一个LinkedHashMap，里面存的就是图片url和DiskLruCache.Entry，其中DiskLruCache.Entry就存有缓存文件名！
可以看到Glide会优先从该Map中取，如果没有找到则自己创建DiskLruCache.Entry然后再放入Map
我们可以直接看DiskLruCache.Entry的构造函数
private Entry(String key) {
cleanFiles = new File[valueCount];
StringBuilder fileBuilder = new StringBuilder(key).append('.');
for (int i = 0; i < valueCount; i++) {
fileBuilder.append(i);
cleanFiles[i] = new File(directory, fileBuilder.toString());
}
}
这里cleanFiles就存放着缓存文件，其中valueCount=1，至于valueCount为什么是1是因为调用DiskLruCache的静态方法open public static DiskLruCache open(File directory, int appVersion, int valueCount, long maxSize) 时传的valueCount参数为1
那么既然valueCount为1，上面代码应该可以简化了吧？
private Entry(String key) {
cleanFiles = new File[1];
StringBuilder fileBuilder = new StringBuilder(key).append('.');
fileBuilder.append(0);
cleanFiles[0] = new File(directory, fileBuilder.toString());
}
所以看了这么多，想到怎么用url获取本地图片了嘛？
另外，试试把 xxx.0 换成 xxx.png ~