NSURLCacheで頭を悩ませるのに非常に長い時間を費やしたばかりなので、他の人が私の不幸を回避できることを願って、このちょっとしたアドバイスを提供します。
それはすべて合理的に十分に始まりました。私の新しいアプリプロジェクトはiOS5以降のみを対象としているため、すべてのWebキャッシングのニーズに新しいNSURLCache実装を利用できると思いました。いくつかの特別なタスクを処理するためにNSURLCacheのカスタムサブクラスが必要でしたが、それはすべてAPIによって有効にサポートされているようでした。ドキュメントをざっと読んで、私はレースに出かけます：
[NSURLCache setSharedURLCache:[[MyCustomCache alloc] initWithMemoryCapacity:8 * 1024 * 1024 //8mb
diskCapacity:32 * 1024 * 1024 // 32mb
diskPath:@"webcache.db"]];
8 MBのキャッシュを開始するのが適切だと思います。より大きなディスクキャッシュでバックアップして、より大きなイメージをローカルで提供できるようにします。残りのネットワークコードをフックしてNSURLConnectionを使用し（実際にはMKNetworkKitを使用しましたが、それは無関係であることが判明しました）、キャッシュから素晴らしいことを期待しています。案の定、キャッシュされるはずのすべてのリクエストは忠実にキャッシュに保存されており、応答はキャッシュから提供されると忠実にすばやく返されます。これは、ペンザンスの海賊の定期的な制作であり、私のネットワークスタックで非常に多くの義務が飛び交っています。
何かが足し合わないことを除いて。キャッシュから処理できるリクエストは、引き続きネットワーク経由で送信されます。そうでない場合を除いて。キャッシュが実際にリクエストを処理するために使用されているかどうかは、完全にランダムで断続的に見えます。私は欲求不満で髪を引き裂き、何が起こっているのかを理解しようと文字通りすべてを掘り下げます。私はテストアプリを構築し、あらゆる場所にブレークポイントを設定し、パケットトレースを切り取り、NSURLCacheに言及しているインターネット上のすべての単語を読み、キャッシュ制御ヘッダーを試し、コードをコメントアウトし、サブクラスをバイパスし、さらには丹念にトレースします。 NSURLCacheとそのCFNetworkingの友人が、その下にある不思議な論理を理解しようとするためのアセンブリ。私はARMとObjective-Cの呼び出し規約の知識を大幅に向上させ、低レベルのデバッグについてかなり学びますが、実際に何が起こっているのかを理解することはできません。全体がイオランテの悪夢の歌のように感じています海賊王の良心的な独裁政権よりも、私はそれをすべて捨てる寸前です。
TL / DRバージョン：NSURLCacheは機能しているように見えますが、キャッシュされた結果が利用可能であっても、ランダムに返されません。