Файлова система мобільного пристрою: що це, структура каталогів і як працює

Що таке файлова система мобільного пристрою?

Файлова система — це програмний компонент операційної системи, який керує тим, як дані записуються, читаються та організовуються на фізичному носії. На мобільних пристроях файлова система виконує критично важливі функції: управління простором флеш-пам’яті, контроль доступу до файлів на основі дозволів, журналювання змін для відновлення після збоїв та оптимізація запису з урахуванням особливостей 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(), які коректно обробляють роздільники на різних платформах.