アプリのキャッシュディレクトリ — その概要、目的、モバイル開発におけるクリア方法

アプリのキャッシュディレクトリとは？

キャッシュディレクトリは、一時ファイル用に設計されたアプリケーションの内部（または外部）メモリ内の特別なディレクトリです。Internal Storageとの主な違い：デバイスの空き容量が少ない場合、システムは通知なしにキャッシュからファイルを削除する権利があります。したがって、アプリケーションは重要なユーザーデータの唯一のコピーをキャッシュに保存してはいけません。キャッシュは、ダウンロードした画像、サーバー応答、プリコンパイル済みリソース、およびリモートで復元またはプログラムによって再作成できるその他のデータに最適です。

Androidでは、キャッシュディレクトリは/data/data/<package>/cache/にあり、context.cacheDirでアクセスできます。キャッシュサイズは明示的に制限されていませんが、Google Playは100 MBを超えないことを推奨しています。キャッシュが大きいアプリはユーザーから否定的な評価を受けるためです。iOSでは、キャッシュディレクトリはSandboxコンテナ内のLibrary/Caches/にあり、NSCachesDirectoryでアクセスできます。iOSは、デバイスをバックアップから復元するとき、または容量が著しく不足しているときにCachesからファイルを削除することがあります — これについてはアプリのドキュメントでユーザーに通知する必要があります。

どのデータを安全にキャッシュに格納でき、どのデータをInternal StorageまたはDocumentsに保存すべきかを理解することは、開発者の重要なスキルです。キャッシュの誤用は2つの相反する問題を引き起こします：アプリが大きすぎるスペースを占有するか（開発者がDocumentsにあるべきものをキャッシュに保存した場合）、またはユーザーがデータを失うか（開発者が永続的に保存すべきものをキャッシュに保存した場合）です。簡単なルールに従ってください：データを復元できる場合はキャッシュ、復元が不可能な場合はInternal StorageまたはDocumentsを使用します。

キャッシュされるデータの目的と種類

データの種類によって再作成速度とストレージ要件が異なります。これらの特性を理解することで、開発者はどのファイルをキャッシュに入れ、どのファイルを永続ストレージに入れるかを正しく選択できます。

画像とメディアファイルのキャッシュ

最も一般的なキャッシュデータの種類は、ネットワークからダウンロードされた画像です。Glide、Picasso、Coilなどのライブラリは、ダウンロードした画像を自動的にアプリのキャッシュディレクトリに保存します。ソーシャルアプリでの画像キャッシュの一般的なサイズは50〜200 MBです。キャッシュサイズはデバイスの画面解像度と表示されるコンテンツの量によって異なります。Glideは2レベルのキャッシュを使用します：最初にRAM内のL1キャッシュ（LRUアルゴリズム）を確認し、次にディスク上のL2キャッシュを確認します。これにより、追加のネットワークリクエストなしで繰り返し表示される画像の高速読み込みが保証されます。DiskCacheStrategyでディスクキャッシュの最大サイズを設定すると、占有スペースを制御できます：制限を超えると、ライブラリは自動的に最も使用されていないファイルを削除します。

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 MB

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // データをキャッシュに書き込む
    }
}

ネットワークリクエストキャッシュ

APIリクエストの応答は、オフラインアクセスやサーバー負荷の軽減のためにキャッシュできます。OkHttpはCacheクラスを通じて組み込みのキャッシュサポートを提供します。Cache-ControlとETagの応答ヘッダーがキャッシュポリシーを管理します：サーバーは応答が有効と見なされる期間を指定します。適切な設定により、ネットワークリクエストキャッシュは繰り返しの訪問でデータ読み込み時間を60〜80%削減し、インターネット接続なしで基本的なアプリ機能を提供できます。ネットワークリクエストキャッシュのサイズは10〜20 MBを超えることはめったにありませんが、アプリの頻繁な使用では50 MBに達する可能性があります。OkHttpClient.Builderコンストラクタで最大キャッシュサイズを設定し、アプリ起動ごとにキャッシュデータの有効性を確認します。

データベースとプリコンパイル済みデータのキャッシュ

SQLiteデータベースは動作中に一時ファイルを生成することがあります：WALファイル（Write-Ahead Log）、ロールバックジャーナル、インデックスページなどです。これらのファイルはメインデータベースと一緒に保存されますが、一時的なデータベース（全文検索や分析など）の場合はキャッシュディレクトリに配置を指定できます。プリコンパイルされたOpenGLおよびVulkanシェーダープログラムもこのディレクトリにキャッシュされ、グラフィックシーンの最初の読み込みを高速化します。iOSでは、NSCachesDirectoryはプリコンパイルされたCore Dataと一時的な画像処理ファイルの保存に推奨されます。

AndroidとiOSでのキャッシュクリアの仕組み

キャッシュクリアは自動的（システムによる）または手動（ユーザーまたはアプリによる）で行われます。さまざまなシナリオでのシステムの動作を理解することは、データ損失を防ぐために必要です。

システムによる自動キャッシュクリア

Androidでは、/dataパーティションの空き容量が重要なしきい値（通常500 MB）を下回ると、システムがキャッシュクリアプロセスを開始します。cacheflushプロセスはインストールされているすべてのアプリのキャッシュサイズを分析し、最も古いファイルから順に最も使用されていないファイルを削除します。ユーザーはシステム設定からすべてのアプリのキャッシュを手動でクリアすることもできます：「設定 → ストレージ → キャッシュ → キャッシュをクリア」。iOSでは、デバイスをバックアップから復元するときにCachesの自動クリアが発生します — iOSはLibrary/Caches/の内容を復元しません。さらに、iOSは空き容量が不足すると、分離されたデータに対してパージ可能ストレージメカニズムを使用して、Cachesからファイルを選択的に削除することがあります。

let fm = FileManager.default
let cachesURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let contents = try fm.contentsOfDirectory(
    at: cachesURL,
    includingPropertiesForKeys: nil
)
for fileURL in contents {
    try fm.removeItem(at: fileURL)
}

アプリによるプログラム的なキャッシュクリア

開発者は、ユーザーリクエストやスケジュールに基づいてプログラム的なキャッシュクリアを実装できます。Androidでは、context.cacheDirとcontext.externalCacheDir内のすべてのファイルを削除するだけでアプリのキャッシュをクリアできます。iOSでは、Library/Caches/の内容をクリアしますが、ディレクトリ自体は削除しないでください — 内容のみを削除します。アプリ設定で現在のキャッシュサイズと確認付きの「キャッシュをクリア」ボタンをユーザーに表示することをお勧めします。Google Play Consoleによると、キャッシュクリアボタンがあるアプリは、この機能がないアプリと比較して、ストレージ不足に関する苦情が22%少なくなっています。キャッシュクリアは安全である必要があります：アプリはキャッシュされたファイルが削除された状況を正しく処理し、次回アクセス時に透過的に再読み込みする必要があります。

AndroidとiOSのcacheDirの違い

同じ目的にもかかわらず、AndroidとiOSでのキャッシュディレクトリの実装には重要な違いがあります。開発者は両方のプラットフォームでアプリを正しく動作させるためにこれらを考慮する必要があります。

Androidはcontext.externalCacheDirを通じて別の外部キャッシュディレクトリを提供します — これはSDカード上にあり（インストールされている場合）、アプリをアンインストールしても削除されません。これは大きなメディアファイルに便利ですが、メモリカードにゴミを残すリスクがあります。iOSには外部キャッシュの概念がなく、すべての一時ファイルはSandboxコンテナ内に保存され、アンインストール時に確実に削除されます。Androidでは、キャッシュはアプリ設定でユーザーに表示され、手動でクリアできます。iOSでは、システム設定は個々のアプリのキャッシュサイズを表示しません — 開発者がインターフェースにクリアボタンを追加しない限り、ユーザーはアプリを削除して再インストールすることでのみキャッシュをクリアできます。

重要な違いは復元時の動作です。iOSでは、iTunesまたはiCloudバックアップから復元するとき、Cachesディレクトリは復元されません。iOSはキャッシュされたデータが最初の起動時に再作成されると想定するためです。Androidでは、Google Driveから復元するとき、Internal Storageのみがバックアップされます — 復元後、キャッシュは空のままです。どちらの場合も、アプリは空のキャッシュで正しく動作し、エラーを表示したり機能を失ったりしてはいけません。

キャッシュ管理の推奨事項

適切なキャッシュ管理は、ユーザーエクスペリエンスとアプリの評価に影響を与える要因の1つです。以下の推奨事項は、一般的な問題を回避し、ユーザー満足度を向上させるのに役立ちます。

• キャッシュサイズの制限を設定します。最大容量をメガバイトで指定してDiskLruCacheまたは同様のライブラリを使用します。制限を超えると、ライブラリは自動的に最も使用されていないファイルを削除します
• アプリ設定にキャッシュクリアボタンを実装します。現在のキャッシュサイズ（「12.5 MB」形式）を表示し、クリア前に確認を求めます。クリア後は表示サイズを更新します
• 復元できないファイルはキャッシュに保存しないでください。データがアプリの動作にとって重要な場合は、Internal Storage（Android）またはDocuments（iOS）に保存し、クイックアクセス用のコピーのみをキャッシュに配置します
• 書き込み前に外部キャッシュの利用可能性を確認します。Androidでは、SDカードがインストールされていないか利用できない場合、context.externalCacheDirがnullを返すことがあります。常に内部キャッシュへのフォールバックを提供します
• キャッシュデータにTTLポリシーを使用します。必要以上にファイルを保存しないでください：画像の場合は24〜48時間、API応答の場合はデータ更新頻度に応じて5分から1時間

アプリ分析でキャッシュサイズを定期的に監視します。Firebase Analyticsまたは同様のシステムにキャッシュサイズメトリクスのレポートを統合します。平均キャッシュサイズが100 MBを超える場合は、キャッシュ戦略を最適化します：まれに使用されるデータのTTLを減らし、キャッシュ前の画像圧縮を実装し（PNGの代わりにWebP、JPEG品質を85%に低減）、サーバーからのコンテンツ読み込みにページネーションを使用します。16〜32 GBのデバイスを使用するユーザーはアプリサイズに特に敏感であることを忘れないでください：キャッシュが200 MBに達すると、多くのユーザーがクリア方法を探し始めたり、単にアプリを削除したりします。Googleの調査によると、38%のユーザーが制御不能なキャッシュの増加とストレージ消費のために少なくとも1つのアプリを削除したことがあります。