两个具有两个缓存的OkHttpClients - 奇怪的行为

Question

我的应用目前有一个OkHttpClient（v3.2.0）用于：

1. 改造
2. 毕加索
3. 将图片/视频上传到云端媒体服务
4. 使用HttpDataSource（ExoPlayer
的视频here's the implementation)

我想使用单独的OkHttpClients进行Retrofit和媒体用例，因为：

1. 我想将他们的缓存分开
2. 媒体OkHttpClient将有一些特定的Interceptors，而改造版不应该

完成更改后，我为OkHttpClient的每个实例提供了自己的Cache;两者都在应用程序的缓存目录中，一个使用目录http，另一个使用media。两个实例都以相同的方式设置（在CookieJar中使用相同的Interceptors和Builders;唯一的区别是传递给它们的是不同的Cache个实例） 。缓存与Picasso完美配合，但与OkHttpDataSource一起使用时表现出奇怪的行为。

传递给OkHttpDataSource的URL是我的应用程序服务器上的一个端点，它将（302）重定向到云端媒体服务。这与我们用于图像/毕加索的过程相同，并且工作正常。

我的缓存基本测试步骤是：

1. 使用OkHttpDataSource播放视频（我的应用服务器发回正确的缓存标头）
2. FC应用程序并重新打开
3. 将设备置于飞行模式
4. 使用OkHttpDataSource播放视频（即使没有互联网连接，也应播放）

当我使用一个OkHttpClient时，一切正常。当我使用上面描述的两个实例时，我的应用程序服务器的响应被缓存（302），但是当它尝试解析Location标题时，会抛出IOException说它可以＆＃39 ; t解析地址。同样，当我只使用OkHttpClient的一个实例时，这不会发生。此外，当我有2个实例时，如果我使用OkHttpDataSource的Retrofit实例，则缓存可以正常工作。

我试图通过调试DiskLruCache来弄清楚发生了什么，但由于附加调试器似乎有副作用，因此遇到了困难。我能够观察到的是，在某些情况下，重定向URL的缓存条目已被删除，因为其DiskLruCache.Entry.readable始终设置为false。据我所知，这是因为DiskLruCache.completeEdit被调用了success = false，但我不确定为什么会这样。同样，仅使用OkHttpClient的一个实例，或使用REST实例而不是OkHttpDataSource的媒体实例时，这不是问题。

Answer 1

OkHttp的缓存只会存储完整的响应。第一次下载文件时，您是在阅读整个响应主体，然后在该流上调用close（）吗？