Файловая система мобильного устройства: что это, структура каталогов и как работает

Что такое файловая система мобильного устройства?

Файловая система — это программный компонент операционной системы, который управляет тем, как данные записываются, читаются и организуются на физическом носителе. На мобильных устройствах файловая система выполняет критически важные функции: управление пространством флеш-памяти, контроль доступа к файлам на основе разрешений, журналирование изменений для восстановления после сбоев и оптимизация записи с учётом особенностей NAND-флеш-памяти.

В отличие от десктопных ОС, мобильные файловые системы проектируются с учётом ограниченного ресурса циклов перезаписи флеш-памяти. NAND-ячейки выдерживают ограниченное количество операций стирания — от 3 000 до 10 000 циклов для TLC и MLC памяти соответственно. Чтобы продлить срок службы накопителя, файловые системы применяют механизмы wear leveling (выравнивание износа) и TRIM-команды. F2FS, разработанная Samsung специально для флеш-памяти, учитывает геометрию NAND-массива и размещает данные таким образом, чтобы минимизировать фрагментацию и количество операций стирания блоков.

Современные мобильные устройства используют комбинацию нескольких файловых систем. Внутренняя память (раздел /data) форматируется в EXT4 или F2FS на Android и APFS на iOS. SD-карты традиционно используют exFAT для поддержки файлов размером более 4 ГБ или FAT32 для максимальной совместимости. Раздел /system на Android часто монтируется только для чтения и использует EXT4 или EROFS (Enhanced Read-Only File System) — сжатая файловая система, разработанная Huawei для уменьшения размера системного раздела.

Структура каталогов на Android

Иерархия каталогов Android основана на Linux-структуре с корнем в /. Каждый раздел имеет свою файловую систему, права доступа и назначение. Приложение может получить доступ только к ограниченному набору директорий — остальные защищены правами root.

Раздел /data и песочница приложений

Раздел /data — основной раздел для хранения пользовательских данных, установленных приложений и их настроек. Каждое приложение получает собственную директорию по пути /data/data/<package_name>/. Внутри этой директории система автоматически создаёт подкаталоги: files/ для файлов приложения, cache/ для временных файлов, databases/ для баз данных SQLite, shared_prefs/ для SharedPreferences. Права доступа к этой директории устанавливаются при установке приложения и не могут быть изменены без root-доступа. Раздел /data форматируется в F2FS на большинстве современных устройств, что обеспечивает до 40% более высокую скорость случайной записи по сравнению с EXT4.

Раздел /system и системные компоненты

Раздел /system содержит операционную систему, системные приложения и библиотеки. Этот раздел монтируется только для чтения, чтобы предотвратить случайное или злонамеренное изменение системных файлов. На устройствах с Android 10+ и Project Treble раздел /system является динамическим и может обновляться через OTA-пакеты без необходимости полной перепрошивки. Для приложений раздел /system недоступен — попытка записи вызовет исключение SecurityException. Однако приложения могут читать некоторые файлы из /system, например, системные шрифты и файлы конфигурации, если у них есть соответствующие права.

Точка монтирования /sdcard

Точка монтирования /sdcard — это символьная ссылка на раздел эмулированного или физического внешнего хранилища. На устройствах без SD-карты /sdcard указывает на подраздел внутри /data, который выделен для общего доступа. Этот раздел виден пользователю при подключении устройства к компьютеру через MTP-протокол. Приложения получают доступ к /sdcard через разрешения READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE, а начиная с Android 10 — через Scoped Storage с использованием MediaStore API. Размер /sdcard обычно составляет 60–80% от общего объёма флеш-памяти устройства, а остальное резервируется под раздел /data.

Структура каталогов на iOS

На iOS файловая система организована через Sandbox-контейнеры приложений. Каждое приложение получает изолированную директорию, доступ к которой ограничен на уровне ядра XNU. Пользовательский раздел использует файловую систему APFS (Apple File System), представленную в iOS 10.3. APFS поддерживает снапшоты, клонирование файлов и шифрование на уровне файлов, что делает её оптимальной для мобильных устройств.

Стандартные каталоги Sandbox-контейнера

Sandbox-контейнер iOS включает четыре основные директории: Documents, Library, tmp и SystemData. Каждая директория имеет свою политику резервного копирования, срок хранения данных и уровень доступа. 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!

Каждая директория Sandbox-контейнера имеет собственный идентификатор защиты (protection class). iOS поддерживает четыре класса: Complete Protection (файл недоступен при заблокированном устройстве), Protected Unless Open (уже открытые файлы доступны при блокировке), Protected Until First User Authentication (файлы доступны после первой разблокировки) и No Protection (файлы доступны всегда после загрузки устройства). По умолчанию все файлы в Documents и Library получают класс Complete Protection, что гарантирует максимальную защиту пользовательских данных. При создании файла можно явно указать другой класс защиты, если фоновое приложение должно иметь доступ к данным при заблокированном устройстве.

Права доступа и безопасность файловой системы

Управление доступом к файлам на мобильных устройствах — ключевое различие между Android и iOS. Android использует классическую Linux-модель прав доступа (чтение, запись, выполнение) с расширениями для изоляции приложений. iOS применяет более строгую модель Sandbox, где каждое приложение работает в изолированном контейнере и не имеет доступа к файлам других приложений без специальных механизмов.

Разрешения на Android

На Android каждое приложение запускается от отдельного UID (User 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
    )
}

Sandbox на iOS и Keychain

iOS Sandbox реализован на уровне ядра XNU и не позволяет приложению выходить за пределы своего контейнера. Даже если приложение получит доступ к URI внешнего файла через Document Picker, операционная система создаёт временную копию в контейнере приложения, а не предоставляет прямой доступ к оригиналу. Для обмена файлами между приложениями iOS использует механизмы Share Sheet и UIActivityViewController, которые копируют файл из контейнера одного приложения в контейнер другого. Для безопасного хранения учётных данных (токены, пароли, ключи) iOS предоставляет Keychain — зашифрованное хранилище, доступное системе на уровне ядра. Keychain не является частью Sandbox-контейнера и управляется отдельным демоном securityd, что обеспечивает дополнительный уровень защиты даже в случае компрометации приложения.

Особенности файловых систем: EXT4, APFS, F2FS

Выбор файловой системы напрямую влияет на производительность и надёжность хранения данных. Каждая файловая система имеет свою архитектуру, оптимизации и ограничения. Разработчику полезно понимать эти различия, чтобы предсказывать поведение приложения на разных устройствах.

• EXT4 — стандартная файловая система Linux с журналированием, поддержкой файлов до 16 ТБ и тома до 1 ЭБ. Используется на Android как основная до внедрения F2FS. Обеспечивает надёжность благодаря журналу, но уступает F2FS по скорости случайной записи из-за необходимости обновления инодов и битмапов блоков при каждой операции
• F2FS — файловая система, разработанная Samsung в 2012 году специально для NAND-флеш-памяти. Учитывает геометрию флеш-массива, использует лог-структурированную архитектуру и обеспечивает на 25–40% более высокую производительность случайной записи по сравнению с EXT4. Начиная с Android 11 F2FS рекомендуется Google в качестве основной файловой системы для раздела /data
• APFS — файловая система Apple, представленная в 2017 году. Поддерживает снапшоты, клонирование файлов (copy-on-write), шифрование на уровне файлов и строгий контроль целостности данных через контрольные суммы. APFS оптимизирована для SSD и использует TRIM-команды для поддержания производительности на протяжении всего срока службы накопителя
• exFAT — файловая система Microsoft, используемая на SD-картах и USB-накопителях. Поддерживает файлы размером более 4 ГБ и тома до 128 ПБ. Не имеет журналирования, поэтому внезапное отключение питания может привести к повреждению данных. Рекомендуется для сменных носителей, но не для системных разделов

При разработке приложений учитывайте, что разные файловые системы имеют различные ограничения на длину имени файла (255 байт для EXT4 и F2FS, 255 символов Unicode для APFS), максимальный размер файла и поддержку специальных символов. Например, APFS допускает символы Unicode в именах файлов, включая эмодзи, в то время как EXT4 ограничена ASCII. Если приложение создаёт файлы с именами на разных языках, тестируйте работу на всех целевых устройствах — имя файла, корректно созданное на APFS, может быть обрезано на EXT4.

Рекомендации по работе с файловой системой

Надёжная работа с файловой системой мобильного устройства требует соблюдения нескольких ключевых правил. Они основаны на анализе типичных ошибок разработчиков и рекомендациях официальной документации.

• Не используйте жёстко закодированные пути к директориям. Всегда получайте пути через системные API: context.filesDir на Android, NSSearchPathForDirectoriesInDomains на iOS. Жёсткие пути меняются между версиями ОС и устройствами
• Обрабатывайте исключения файловых операций: IOException, FileNotFoundException, SecurityException. На iOS все операции FileManager могут выбрасывать ошибки — оборачивайте их в do-catch. На Android операции с внешним хранилищем могут завершаться ошибкой из-за отсутствия носителя
• Проверяйте доступное место перед записью. Используйте File.getUsableSpace() на Android и URLResourceValues.volumeAvailableCapacityKey на iOS. Предупреждайте пользователя, если свободного места недостаточно
• Избегайте хранения больших файлов в директориях, которые попадают в резервное копирование. На 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(), которые корректно обрабатывают разделители на разных платформах.