私のアプリには現在OkHttpClient、次の目的で使用されるもの (v3.2.0) があります。
- レトロフィット
- ピカソ
- クラウド メディア サービスへの画像/動画のアップロード
- 使用する
HttpDataSourceビデオ用ExoPlayer(実装はこちら)
OkHttpClientsRetrofit とメディアのユース ケースを別々に使用したい理由は次のとおりです。
- キャッシュを分けておきたい
- メディアには、レトロフィットのものにはない
OkHttpClient特定のものがありますInterceptors
変更を行った後、各インスタンスにOkHttpClient独自のCache;を提供します。どちらもアプリのキャッシュ ディレクトリにあり、1 つは directory を使用し、httpもう 1 つは を使用しmediaます。両方のインスタンスは同じように設定されます (同じ と を使用しCookieJarますInterceptors。Builders唯一の違いは、Cacheそれらに渡される異なるインスタンスがあることです)。キャッシュはピカソと完全に連携しますが、OkHttpDataSource.
渡される URL はOkHttpDataSource、クラウド メディア サービスにリダイレクト (302) するアプリケーション サーバーのエンドポイントです。これは、画像/ピカソに使用するのと同じプロセスであり、正常に機能します。
キャッシュの基本的なテスト手順は次のとおりです。
- を使用し
OkHttpDataSourceてビデオを再生します (私のアプリケーション サーバーは正しいキャッシュ ヘッダーを送り返します)。 - アプリを FC して再度開く
- デバイスを機内モードにする
- を使用し
OkHttpDataSourceてビデオを再生します (インターネット接続がない場合でも再生する必要があります)。
私が1つを使用すると、OkHttpClientすべて正常に動作します。上記のように 2 つのインスタンスを使用すると、アプリケーション サーバーからの応答がキャッシュされます (302) が、Locationヘッダーを解決しようとするIOExceptionと、アドレスを解決できないというメッセージがスローされます。繰り返しますが、これは、 のインスタンスを 1 つしか使用しない場合には発生しませんOkHttpClient。さらに、インスタンスが 2 つある場合、Retrofit インスタンスを に使用するOkHttpDataSourceと、キャッシュが正常に機能します。
デバッグで何が起こっているのかを把握しようとしていましたDiskLruCacheが、デバッガーを接続していると副作用があるようで、苦労していました。私が観察できたのは、リダイレクトされた URL のキャッシュ エントリDiskLruCache.Entry.readableが常に に設定されていたため、状況によっては削除されていたことfalseです。私が知る限り、これは でDiskLruCache.completeEdit呼び出されたためでしたがsuccess = false、なぜそうなったのかはわかりません。の 1 つのインスタンスのみを使用する場合OkHttpClient、または のメディア インスタンスの代わりに REST インスタンスを使用する場合も、これは問題ではありませんでしたOkHttpDataSource。