简述
基于项目需求，用户更换新头像后，iOS、Android、web 端三端需要能更新到最新的头像。由于各种原因，用户头像的URL始终是不变的。而一般App端的图片加载框架都会把 URL 作为 key 对图片进行多级缓存，用户更改了新头像，此时 URL 不变就会导致图片框架始终都只会加载本地的缓存。
梳理以上需求，有以下问题需要解决：
1、在 URL 不变的情况下，如何得知服务端的图片是否已经更改
2、在知道服务端图片已经更改的情况下，如何让图片请求框架去请求服务端的最新图片，而不是加载本地缓存
- 针对第一个问题，Http协议提供了 ETag 或者 Last-Modified 来判断当前请求资源是否改变，具体可以查看链接了解，通俗解释为第一次请求资源 A，会返回一个请求头 H，第二次请求 A 时带上该请求头 H，返回的响应码为 304 代表资源没有变（不会返回资源 A ），为 200 代表资源有更新（会返回资源 A ）。
注意：
ETag 对比 Last-Modified 的优势
1、一些文件也许会周期性的更改，但是他的内容并不改变（ 仅仅改变的修改时间），这个时候我们并不希望客户端认为这个文件被修改了，而重新GET;
2、某些文件修改非常频繁，比如在秒以下的时间内进行修改，（比方说 1s 内修改了 N 次），If-Modified-Since 能检查到的粒度是 s 级的，这种修改无法判断（或者说 UNIX 记录 MTIME 只能精确到秒）；
3、某些服务器不能精确的得到文件的最后修改时间。
- 针对第二个问题，项目中使用 Glide 作为图片请求，设置 memery 和 disk 缓存都忽略是可以让 glide 直接去请求服务端图片的，但是没有了缓存，体验会比较差，这里使用的是 Glide 的 signature，通过 ObjectKey 来作为图片的标识，ObjectKey 大家可以看一下源码，通过所传参数的 hashCode 来区分，结合第一个问题的回答，我们可以把 ETag 或者 Last-Modified 作为 ObjectKey 的参数
/**
* 使用Glide加载图片
* @param context 上下文
* @param key Last-Modified或Etag
* @param url 图片url
* @param imageView 图片控件
*/
private fun glideLoadImg(context: Context, key: String, url: String, imageView: ImageView) {
Glide.with(context)
.setDefaultRequestOptions(RequestOptions.circleCropTransform()
//图片签名信息，相同url下如果需要刷新图片，signature不同则会加载网络端的图片资源
.signature(ObjectKey(key)).placeholder(imageView.drawable))
.load(url)
.into(imageView)
}
- 综合上面的，一个简单的方案就有了，接下来就是代码实现，首先是获取资源的 ETag 或者 Last-Modified，这两个都是存在于响应头里面，为了性能和流量（ HEAD 请求只会返回响应头，不会响应体），我们使用了 HEAD 请求，代码是用 Retrofit 实现
/**
* 基础api方法，包括POST、GET、UPLOAD、DOWNLOAD等
* @version 2.2.0
* @date 2017/5/16 16:49
*/
interface BaseApiService {
/** HEAD请求，只会返回响应头，没有返回响应体，节省流量 */
/** HEAD请求，带上Last-Modified或Etag的请求头 */
@HEAD
fun getImg(@Url url: String, @Header(IF_NONE_MATCH) lastModify: String): Observable<Response<Void>>
}
/**
* 图片相关工具类
*
* @date 2018/2/27 18:27
* @version v4.0.0
*/
const val ETAG = "ETag"
const val IF_NONE_MATCH = "If-None-Match"
const val LAST_MODIFIED = "Last-Modified"
const val IF_MODIFIED_SINCE = "If-Modified-Since"
/**
* 加载头像
* @param url 图片url
*/
fun ImageView.loaderHeadImgWithHead(url: String) {
//当url为空时，不请求网络,加载默认图片
if (url.isEmpty()) {
Glide.with(context).load(R.drawable.default_head).into(this)
} else {
//获取url对应存储在sp中的Last-Modified或Etag
val key = SharedPreferencesUtils[context, SP_FILE_COMMON, url, ""]
if (key.isNotEmpty()) {
//key非空，即本地存在缓存，先加载本地缓存
glideLoadImg(context, key, url, this)
} else {
//key为空，不存在缓存，加载默认图片
Glide.with(context).load(R.drawable.default_head).into(this)
}
RetrofitClient.getInstance(context).getApiService().getImg(url, key)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe({
//获取响应头中的Last-Modified或Etag
val head = it.headers().get(ETAG)
if (it.code() == 304) {
//304的时候返回的lastModified或者Etag为null，此时使用上次存储的key来加载图片
glideLoadImg(context, key, url, this)
} else if (it.code() == 200) {
//保存最新的lastModified或者Etag
SharedPreferencesUtils.save(context, SP_FILE_COMMON, url, head!!)
glideLoadImg(context, head, url, this)
}
},{it.printStackTrace()})
}
}
总结上面的实现，大概就是 Retrofit 携带 ETag 或者 Last-Modified 作为请求头发起 HEAD 请求，根据返回的请求码（ 304 或者 200 ）来判断服务端的图片是否更改，如果有更改，再将服务端返回的 ETag 或者 Last-Modified 作为 Signature 让 Glide 去加载新图片。上面的代码更细致一点，还加了本地是否已经存在缓存图片的校验，体验稍微好一些。
上面的实现可优化的地方还有很多，正常的图片加载，本地缓存存在的情况下根本不需要进行网络请求，上面的实现会先进行一次 HEAD 请求，是为了判断服务端图片是否有更改，下图是 Android studio 监测的流量，HEAD 请求是黄色，加载图片的是蓝色，虽然流量消耗很少，但是增加一次网络请求，图片多的情况下还是会有影响的。如果大家仔细了解了 ETag 或者 Last-Modified，会发现，如果资源有更新，返回 200 时，同时资源也会返回回来，这里返回的应该是图片的二进制，此时已经拿到图片的二进制了，本来可以不用 Glide 再次发起请求，只需要让 Glide 加载二进制流即可，但是这里存在一个问题，直接加载二进制流，下次需要加载缓存的时候就没办法加载了，因为一般都是用 url 作为加载图片的路径，这里直接给流，那么 url 跟图片之间就没有关联了，如果有更好的方案，欢迎拍砖。
本地搞了个 Tomcat，把图片放在 webapps\ROOT 路径下，直接就可以测试访问。
