Файлова система на мобилно устройство: какво е, структура на директориите и как работи

Какво е файлова система на мобилно устройство?

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

За разлика от десктоп операционните системи, мобилните файлови системи се проектират с оглед на ограничения ресурс от цикли на презаписване на флаш паметта. NAND клетките издържат ограничен брой операции на изтриване — от 3 000 до 10 000 цикъла за TLC и MLC памет съответно. За да се удължи животът на устройството за съхранение, файловите системи прилагат механизми за wear leveling (изравняване на износването) и TRIM команди. F2FS, разработена от Samsung специално за флаш памет, взема предвид геометрията на NAND масива и поставя данните по начин, който минимизира фрагментацията и броя на операциите за изтриване на блокове.

Съвременните мобилни устройства използват комбинация от няколко файлови системи. Вътрешната памет (дял /data) се форматира в EXT4 или F2FS на Android и APFS на iOS. SD картите традиционно използват exFAT за поддръжка на файлове по-големи от 4 GB или 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 TB и томове до 1 EB. Използва се на 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 GB и томове до 128 PB. Няма журналиране, така че внезапно прекъсване на захранването може да доведе до повреда на данни. Препоръчва се за сменяеми носители, но не за системни дялове

При разработването на приложения вземете предвид, че различните файлови системи имат различни ограничения за дължина на името на файла (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(), които правилно обработват разделителите на различни платформи.