モバイルデバイスのファイルシステム：その概要、ディレクトリ構造、動作の仕組み

モバイルデバイスのファイルシステムとは

ファイルシステムは、物理メディア上のデータの書き込み、読み取り、整理方法を管理するオペレーティングシステムのソフトウェアコンポーネントです。モバイルデバイスでは、ファイルシステムは重要な機能を実行します：フラッシュメモリ領域の管理、権限に基づくファイルアクセス制御、クラッシュ後の復旧のための変更ジャーナリング、NANDフラッシュメモリの特性を考慮した書き込み最適化です。

デスクトップOSとは異なり、モバイルファイルシステムはフラッシュメモリの限られた書き換えサイクルを考慮して設計されています。NANDセルは限られた回数の消去操作に耐えられます—TLCおよびMLCメモリでそれぞれ3,000〜10,000サイクルです。ストレージの寿命を延ばすために、ファイルシステムはウェアレベリングメカニズムとTRIMコマンドを採用しています。Samsungがフラッシュメモリ専用に開発したF2FSは、NANDアレイのジオメトリを考慮し、フラグメンテーションとブロック消去操作の数を最小限に抑えるようにデータを配置します。

最新のモバイルデバイスは複数のファイルシステムの組み合わせを使用しています。内部メモリ（/dataパーティション）はAndroidではEXT4またはF2FS、iOSではAPFSとしてフォーマットされます。SDカードは従来、4GBを超えるファイルにはexFAT、最大の互換性にはFAT32を使用します。Androidの/systemパーティションは多くの場合読み取り専用でマウントされ、EXT4またはEROFS（Enhanced Read-Only File System）—Huaweiがシステムパーティションのサイズを削減するために開発した圧縮ファイルシステム—を使用します。

Androidのディレクトリ構造

Androidのディレクトリ階層は/をルートとするLinux構造に基づいています。各パーティションには独自のファイルシステム、アクセス権限、目的があります。アプリケーションは限られたディレクトリセットにのみアクセスでき、残りはroot権限で保護されています。

/dataパーティションとアプリサンドボックス

/dataパーティションは、ユーザーデータ、インストールされたアプリケーション、およびその設定を保存するための主要パーティションです。各アプリケーションは/data/data/<package_name>/に自身のディレクトリを取得します。このディレクトリ内で、システムは自動的にサブディレクトリを作成します：アプリケーションファイル用のfiles/、一時ファイル用のcache/、SQLiteデータベース用のdatabases/、SharedPreferences用のshared_prefs/です。このディレクトリへのアクセス権限はアプリケーションのインストール時に設定され、rootアクセスなしでは変更できません。最新のデバイスの大半では/dataパーティションはF2FSとしてフォーマットされ、EXT4と比較して最大40%高いランダム書き込み速度を提供します。

/systemパーティションとシステムコンポーネント

/systemパーティションにはオペレーティングシステム、システムアプリケーション、ライブラリが含まれています。このパーティションは、システムファイルの誤った変更や悪意のある変更を防ぐために読み取り専用でマウントされます。Android 10+とProject Trebleを搭載したデバイスでは、/systemパーティションは動的であり、完全な再フラッシュなしでOTAパッケージを介して更新できます。アプリケーションにとって、/systemパーティションはアクセス不可です—書き込みを試みるとSecurityExceptionがスローされます。ただし、アプリケーションは適切な権限があれば、システムフォントや設定ファイルなど/systemから一部のファイルを読み取ることができます。

/sdcardマウントポイント

/sdcardマウントポイントは、エミュレートまたは物理的な外部ストレージパーティションへのシンボリックリンクです。SDカードのないデバイスでは、/sdcardは共有アクセス用に指定された/data内のサブパーティションを指します。このパーティションは、デバイスがMTPプロトコルを介してコンピュータに接続されているときにユーザーに表示されます。アプリケーションはREAD_EXTERNAL_STORAGEおよびWRITE_EXTERNAL_STORAGE権限を介して/sdcardにアクセスし、Android 10以降はMediaStore APIを使用したスコープドストレージを介してアクセスします。/sdcardのサイズは通常フラッシュメモリ全体の60〜80%で、残りは/dataパーティション用に予約されています。

iOSのディレクトリ構造

iOSでは、ファイルシステムはアプリケーションのサンドボックスコンテナを介して編成されています。各アプリケーションは、XNUカーネルレベルでアクセスが制限された分離ディレクトリを取得します。ユーザーパーティションはiOS 10.3で導入されたAPFS（Apple File System）を使用します。APFSはスナップショット、ファイルクローン、ファイルレベルの暗号化をサポートし、モバイルデバイスに最適です。

標準サンドボックスコンテナディレクトリ

iOSのサンドボックスコンテナには、Documents、Library、tmp、SystemDataの4つの主要ディレクトリが含まれます。各ディレクトリには独自のバックアップポリシー、データ保持期間、アクセスレベルがあります。Documentsは自動的にiCloudおよびiTunesバックアップに含まれます。LibraryにはサブディレクトリCaches（バックアップなし）、Preferences（バックアップあり）、Application Support（バックアップあり）が含まれます。tmpディレクトリはストレージが不足したときにiOSが削除する可能性のある一時ファイル用で、バックアップには含まれません。SystemDataはシステム自体によって使用され、標準APIを介してアプリケーションがアクセスすることはできません。

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

各サンドボックスコンテナディレクトリには独自の保護クラスがあります。iOSは4つのクラスをサポートしています：完全保護（デバイスロック時にファイルにアクセス不可）、ロック時以外保護（既に開かれているファイルはロック時もアクセス可能）、初回ユーザー認証まで保護（最初のロック解除後にファイルにアクセス可能）、保護なし（デバイス起動後は常にファイルにアクセス可能）。デフォルトでは、DocumentsとLibraryのすべてのファイルは完全保護クラスを受け取り、ユーザーデータの最大限の保護を保証します。ファイル作成時に、バックグラウンドアプリケーションがデバイスロック中にデータにアクセスする必要がある場合は、別の保護クラスを明示的に指定できます。

ファイルシステムのアクセス権限とセキュリティ

モバイルデバイスでのファイルへのアクセス制御はAndroidとiOSの重要な違いです。Androidはアプリケーション分離のための拡張機能を備えた古典的なLinux権限モデル（読み取り、書き込み、実行）を使用します。iOSはより厳格なサンドボックスモデルを使用し、各アプリケーションは分離されたコンテナで実行され、特別なメカニズムなしに他のアプリケーションのファイルにアクセスできません。

Androidの権限

Androidでは、各アプリケーションは個別のUID（ユーザーID）で実行されます。アプリケーションがそのサンドボックス内で作成したすべてのファイルはこのUIDに属し、他のアプリケーションからは見えません。共有ディレクトリ（外部ストレージ）にアクセスするには、アプリケーションはREAD_EXTERNAL_STORAGEおよびWRITE_EXTERNAL_STORAGE権限を要求する必要があります。Android 11以降、権限は実行時に要求する必要があり、targetSdkVersion 30+のアプリケーションは他のアプリケーションのファイルにアクセスするためにSAFを使用する必要があります。権限モデルに違反するとSecurityExceptionが発生し、標準のtry-catchブロックで処理されます。Google Playは公開前にアプリケーションの権限ポリシーへの準拠を自動的にチェックします。

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

iOSのサンドボックスとキーチェーン

iOSサンドボックスはXNUカーネルレベルで実装されており、アプリケーションがそのコンテナを離れることを許可しません。アプリケーションがDocument Pickerを介して外部ファイルURIにアクセスできたとしても、オペレーティングシステムはオリジナルへの直接アクセスを提供する代わりに、アプリケーションのコンテナ内に一時的なコピーを作成します。アプリケーション間でファイルを共有するために、iOSはShare SheetとUIActivityViewControllerメカニズムを使用し、あるアプリケーションのコンテナから別のアプリケーションのコンテナにファイルをコピーします。認証情報（トークン、パスワード、キー）の安全な保存のために、iOSはキーチェーンを提供します—カーネルレベルでシステムがアクセス可能な暗号化ストレージです。キーチェーンはサンドボックスコンテナの一部ではなく、独立したsecuritydデーモンによって管理され、アプリケーションが侵害された場合でも追加の保護層を提供します。

ファイルシステムの特徴：EXT4、APFS、F2FS

ファイルシステムの選択はストレージのパフォーマンスと信頼性に直接影響します。各ファイルシステムには独自のアーキテクチャ、最適化、制限があります。開発者がこれらの違いを理解することは、異なるデバイスでのアプリケーションの動作を予測するのに役立ちます。

• EXT4 — ジャーナリング付きの標準Linuxファイルシステムで、最大16TBのファイルと1EBのボリュームをサポートします。F2FS採用前はAndroidの主要ファイルシステムとして使用されていました。ジャーナリングによる信頼性を提供しますが、各操作でのiノードとブロックビットマップの更新が必要なため、ランダム書き込み速度ではF2FSに劣ります
• F2FS — Samsungが2012年にNANDフラッシュメモリ専用に開発したファイルシステムです。フラッシュアレイのジオメトリを考慮し、ログ構造化アーキテクチャを使用し、EXT4と比較して25〜40%高いランダム書き込みパフォーマンスを提供します。Android 11以降、Googleは/dataパーティションの主要ファイルシステムとしてF2FSを推奨しています
• APFS — Appleが2017年に導入したファイルシステムです。スナップショット、ファイルクローン（コピーオンライト）、ファイルレベルの暗号化、チェックサムによる厳格なデータ整合性制御をサポートします。APFSはSSD用に最適化され、ストレージの寿命全体にわたってパフォーマンスを維持するためにTRIMコマンドを使用します
• exFAT — SDカードやUSBドライブで使用されるMicrosoftのファイルシステムです。4GBを超えるファイルと最大128PBのボリュームをサポートします。ジャーナリングがないため、突然の電源喪失でデータが破損する可能性があります。リムーバブルメディアには推奨されますが、システムパーティションには推奨されません

アプリケーションを開発する際、異なるファイルシステムには異なるファイル名長制限（EXT4とF2FSでは255バイト、APFSでは255 Unicode文字）、最大ファイルサイズ、特殊文字サポートがあることに注意してください。たとえば、APFSは絵文字を含むUnicode文字をファイル名に許可しますが、EXT4はASCIIに制限されています。アプリケーションが異なる言語の名前でファイルを作成する場合は、すべてのターゲットデバイスでテストしてください—APFSで正しく作成されたファイル名がEXT4で切り詰められる可能性があります。

ファイルシステム操作の推奨事項

モバイルデバイスのファイルシステムでの信頼性の高い操作には、いくつかの重要なルールに従う必要があります。これらは開発者の典型的なミスの分析と公式ドキュメントの推奨事項に基づいています。

• ディレクトリへのハードコードされたパスを使用しないでください。常にシステムAPIを介してパスを取得してください：Androidではcontext.filesDir、iOSではNSSearchPathForDirectoriesInDomains。ハードコードされたパスはOSのバージョンやデバイス間で変更されます
• ファイル操作の例外を処理してください：IOException、FileNotFoundException、SecurityException。iOSでは、すべてのFileManager操作がエラーをスローする可能性があります—do-catchでラップしてください。Androidでは、外部ストレージ操作がメディアの不在により失敗する可能性があります
• 書き込み前に利用可能な容量を確認してください。AndroidではFile.getUsableSpace()、iOSではURLResourceValues.volumeAvailableCapacityKeyを使用してください。空き容量が不足している場合はユーザーに警告してください
• バックアップに含まれるディレクトリに大きなファイルを保存しないでください。iOSではisExcludedFromBackupを使用してキャッシュをバックアップから除外してください。Androidでは一時ファイルにcacheDirを優先してください
• ストレージオーバーフローや突然の電源喪失時の動作をテストしてください。トランザクション書き込みを使用してください：一時ファイルに書き込んでから原子的に名前を変更します

クロスプラットフォームの違いに特に注意してください。Androidのファイルパスはフォワードスラッシュ（/data/data/.../files/）を使用し、iOSはURLスキーム（file:///var/mobile/.../Documents/）を使用します。アプリケーションがクロスプラットフォームフレームワーク（Flutter、React Native、Kotlin Multiplatform）を使用する場合は、プラットフォームアダプターを介してファイル操作を統一してください。たとえば、Flutterはpath_providerパッケージを提供し、プラットフォーム固有のコードを記述せずに両方のプラットフォームでDocumentsまたはfilesDirへの正しいパスを返します。文字列操作でパスを連結しないでください—異なるプラットフォームで区切り文字を正しく処理するFile.join()またはURL.appendingPathComponent()を使用してください。