2018-01-01 狗年的第一篇问题总结，URL不变的情况下，Glide加载图片不更新

---

• 序言

• 问题描述

  • 触发条件

• 解决思路

  • 查看glide缓存模块的wiki
  • signature是什么
  • 修改不了signature怎么办

• 总结

---

序言

发现这个问题源于17年最后一天的一个线上事故，昨晚八点多的时候后端哥们儿打电话给我，询问为什么app的直播模块的截图不能实时更新.我立刻打开电脑，debug这段代码，打断点发现程序逻辑没有错误，图片链接放在浏览器中也是能实时更新的，最后发现直播截图的url始终没有发生更改，但实际上服务器上的资源内容已经改变了，这个bug也就成为了我18年处理的第一个问题，还是很有纪念意义的.

---

问题描述

这应该是一个使用Glide的经典问题了: 如果服务器上的某个资源对应的URL保持不变，那么使用Glide下载该资源（比如图片）的时候，会导致使用内存或flash上的数据来作为这次请求的结果，造成图片无法与服务器上的最新资源保持一致.

---

触发条件

• 图片对应的URL始终未变化
• 配置glide的时候没有禁用内存和硬盘缓存
• 保持app进程不被杀死

---

解决思路

---

查看Glide缓存模块的wiki

因为对Glide缓存这块一直没有怎么关注过，所以接着去看了下Glide关于缓存的wiki.

• https://github.com/bumptech/glide/wiki/Caching-and-Cache-Invalidation
  这篇wiki讲了两个方面的内容
• 硬盘缓存键值对的key是如何组成的
• 硬盘缓存的刷新机制

硬盘缓存key如何组成

• DateFetcher.getId() 方法返回的字符串,一般是URL或者文件路径.
• override(int,int) 方法传入的图片宽高值（如果调用了）,默认为 Target.getSize() 方法返回的宽高值.
• 每次加载图片时一个可选的签名字段.

前两项都很好理解，那么这个signature签名字段是什么意思，这要牵涉到glide的缓存刷新机制.

---

Glide的缓存刷新机制

文档中解释如下: 硬盘缓存文件的key值都是哈希处理过的，并且在加载图片过程产生的缩略图等文件也都是以哈希值命名的,所以很难简单地根据代码中提供的原始图片路径(url,filePath等)来清除所有的相关缓存,所以官方建议的最佳方式是，如果想更新硬盘缓存，就要更新上述提供的三个key值组成项中的一项.
那么问题来了，url和文件路径很有可能不会改变（比如我这次碰到的问题），图片的宽高一般情况下也不会修改，那么只有通过修改signature这个值来达到修改key值的目的了.

---

如何使用signature

贴一个Signature的最简单实现：StringSignature

package com.bumptech.glide.signature;

import com.bumptech.glide.load.Key;

import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;

/**
 * A unique Signature that wraps a String.
 */
public class StringSignature implements Key {
    private final String signature;

    public StringSignature(String signature) {
        if (signature == null) {
            throw new NullPointerException("Signature cannot be null!");
        }
        this.signature = signature;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()) {
            return false;
        }

        StringSignature that = (StringSignature) o;

        return signature.equals(that.signature);
    }

    @Override
    public int hashCode() {
        return signature.hashCode();
    }

    @Override
    public void updateDiskCacheKey(MessageDigest messageDigest) throws UnsupportedEncodingException {
        messageDigest.update(signature.getBytes(STRING_CHARSET_NAME));
    }

    @Override
    public String toString() {
        return "StringSignature{"
            + "signature='" + signature + '\''
            + '}';
    }
}

可以看到实现了 KEY接口的 Signature 对象包含一个 updateDiskCacheKey()方法用来更新Key：
通过SHA-256等算法来根据用户输入的signature来生成一个加密过的key
这样也就能理解其它诸如 MediaStoreSignature等等各种Signature类，它们只是输入的被加密对象类型不同而已.

---

修改不了signature怎么办

看完wiki文档了解了signature后我以为自己的问题解决了，但是又有一个很尴尬的问题就是服务器并没有下发能作为signature的数据,事实上我能拿到的只有一个url而已，除此之外没有任何数据可以标示服务器上的图片资源是否发生了改变.这种情况能怎么办呢,难道只能跳过内存和硬盘缓存么??
只能继续在google上搜索解决方案，幸运地是找到了两位开发者关于这个问题的一段对话.
https://github.com/bumptech/glide/issues/
这里不再展开讲了，简单记录下他们两个对话的要点:

• 可以通过先发一次head请求来判断服务器上的资源是否发生了改变，然后再通过Get请求来下载资源,不过这种方式需要发送两次网络请求，响应速度要慢一些.
• 可以通过强制刷新空url的方法来重置当前内存数据和硬盘数据(相当不优雅)
• 替换并设置Glide使用的OkHttpClient，在拦截器里判断 header里的 Etag或者modifyTimeStamp，当然前提是下发图片的服务器回传的response里有配置这两个header字段(很不幸，服务器没配置这两个字段)

---

总结

最终还是用了 跳过内存和硬盘缓存的方式来解决了这个问题，由于问题涉及的业务范围并不大，也没有做轮询等操作，所以这种解决方案虽然不算完美，但综合来说是最简捷和影响最小的方案,后续会和服务端的同事沟通看有没有更好的解决方案.