Mobil enhetens filsystem: vad det är, katalogstruktur och hur det fungerar

Vad är filsystemet för en mobil enhet?

Filsystem är en programvarukomponent i operativsystemet som hanterar hur data skrivs, läses och organiseras på det fysiska mediet. På mobila enheter utför filsystemet kritiskt viktiga funktioner: hantering av flashminnesutrymme, åtkomstkontroll till filer baserat på behörigheter, loggning av ändringar för återställning efter fel och optimering av skrivning med hänsyn till egenskaperna hos NAND-flashminne.

Till skillnad från stationära operativsystem utformas mobila filsystem med hänsyn till flashminnets begränsade resurs av omskrivningscykler. NAND-celler tål ett begränsat antal raderingsoperationer — från 3 000 till 10 000 cykler för TLC- respektive MLC-minne. För att förlänga lagringsenhetens livslängd tillämpar filsystem wear leveling-mekanismer (utjämning av slitage) och TRIM-kommandon. F2FS, utvecklat av Samsung specifikt för flashminne, tar hänsyn till NAND-arrayens geometri och placerar data på ett sätt som minimerar fragmentering och antalet blockraderingsoperationer.

Moderna mobila enheter använder en kombination av flera filsystem. Det interna minnet (partitionen /data) formateras i EXT4 eller F2FS på Android och APFS på iOS. SD-kort använder traditionellt exFAT för stöd av filer större än 4 GB eller FAT32 för maximal kompatibilitet. Partitionen /system på Android monteras ofta skrivskyddad och använder EXT4 eller EROFS (Enhanced Read-Only File System) — ett komprimerat filsystem utvecklat av Huawei för att minska storleken på systempartitionen.

Katalogstruktur på Android

Kataloghierarki för Android är baserad på Linux-strukturen med rot i /. Varje partition har sitt eget filsystem, åtkomsträttigheter och syfte. En app har endast åtkomst till en begränsad uppsättning kataloger — resten skyddas av root-rättigheter.

Partition /data och appars sandlåda

Partitionen /data är den huvudsakliga partitionen för lagring av användardata, installerade appar och deras inställningar. Varje app får en egen katalog på sökvägen /data/data/<package_name>/. Inuti denna katalog skapar systemet automatiskt underkataloger: files/ för appfiler, cache/ för temporära filer, databases/ för SQLite-databaser, shared_prefs/ för SharedPreferences. Åtkomsträttigheterna till denna katalog ställs in vid installation av appen och kan inte ändras utan root-åtkomst. Partitionen /data formateras i F2FS på de flesta moderna enheter, vilket ger upp till 40% högre slumpmässig skrivhastighet jämfört med EXT4.

Partition /system och systemkomponenter

Partitionen /system innehåller operativsystemet, systemappar och bibliotek. Denna partition monteras skrivskyddad för att förhindra oavsiktlig eller skadlig ändring av systemfiler. På enheter med Android 10+ och Project Treble är partitionen /system dynamisk och kan uppdateras via OTA-paket utan fullständig omflashning. För appar är partitionen /system otillgänglig — ett skrivförsök orsakar ett SecurityException. Appar kan dock läsa vissa filer från /system, till exempel systemteckensnitt och konfigurationsfiler, om de har lämpliga behörigheter.

Monteringspunkt /sdcard

Monteringspunkten /sdcard är en symbolisk länk till partitionen för emulerad eller fysisk extern lagring. På enheter utan SD-kort pekar /sdcard på en underpartition inom /data som är avsatt för delad åtkomst. Denna partition är synlig för användaren när enheten ansluts till datorn via MTP-protokollet. Appar får åtkomst till /sdcard via behörigheterna READ_EXTERNAL_STORAGE och WRITE_EXTERNAL_STORAGE, och från Android 10 — via Scoped Storage med MediaStore API. Storleken på /sdcard är vanligtvis 60–80% av den totala flashminnesvolymen på enheten, och resten är reserverat för partitionen /data.

Katalogstruktur på iOS

På iOS är filsystemet organiserat genom Sandbox-containrar för appar. Varje app får en isolerad katalog vars åtkomst är begränsad på XNU-kärnnivå. Användarpartitionen använder filsystemet APFS (Apple File System), introducerat i iOS 10.3. APFS stöder ögonblicksbilder, filkloning och kryptering på filnivå, vilket gör det optimalt för mobila enheter.

Standardkataloger för Sandbox-containern

Sandbox-containern för iOS innehåller fyra huvudsakliga kataloger: Documents, Library, tmp och SystemData. Varje katalog har sin egen säkerhetskopieringspolicy, datalagringstid och åtkomstnivå. Documents inkluderas automatiskt i iCloud- och iTunes-säkerhetskopior. Library innehåller underkatalogerna Caches (säkerhetskopieras inte), Preferences (säkerhetskopieras) och Application Support (säkerhetskopieras). Katalogen tmp är avsedd för temporära filer — iOS kan ta bort dem vid utrymmesbrist och ingår inte i säkerhetskopiering. SystemData används av systemet självt och är inte tillgänglig för appen via standard-API:er.

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!

Varje katalog i Sandbox-containern har sin egen skyddsklass (protection class). iOS stöder fyra klasser: Complete Protection (filen är inte tillgänglig när enheten är låst), Protected Unless Open (redan öppna filer är tillgängliga vid låsning), Protected Until First User Authentication (filer är tillgängliga efter första upplåsningen) och No Protection (filer är alltid tillgängliga efter enhetens start). Som standard får alla filer i Documents och Library klassen Complete Protection, vilket garanterar maximalt skydd av användardata. När en fil skapas kan en annan skyddsklass explicit anges om en bakgrundsapp måste ha åtkomst till data när enheten är låst.

Åtkomsträttigheter och säkerhet för filsystem

Åtkomsthantering till filer på mobila enheter är en viktig skillnad mellan Android och iOS. Android använder den klassiska Linux-modellen för åtkomsträttigheter (läsning, skrivning, exekvering) med utökningar för appisolering. iOS tillämpar en striktare Sandbox-modell där varje app körs i en isolerad container och utan särskilda mekanismer inte har åtkomst till andra appars filer.

Behörigheter på Android

På Android körs varje app med ett separat UID (User ID). Alla filer som skapas av appen i dess sandlåda tillhör detta UID och är inte synliga för andra appar. För åtkomst till delade kataloger (extern lagring) måste appen begära behörigheterna READ_EXTERNAL_STORAGE och WRITE_EXTERNAL_STORAGE. Från Android 11 måste behörigheter begäras vid körning, och en app med targetSdkVersion 30+ måste använda SAF för åtkomst till andra appars filer. Brott mot behörighetsmodellen leder till SecurityException, som hanteras av ett standard try-catch-block. Google Play kontrollerar automatiskt appens överensstämmelse med behörighetspolicyn före publicering.

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

Sandbox på iOS och Keychain

iOS Sandbox är implementerad på XNU-kärnnivå och tillåter inte appen att lämna sin container. Även om appen får åtkomst till URI för en extern fil via Document Picker, skapar operativsystemet en temporär kopia i appens container istället för att ge direkt åtkomst till originalet. För fildelning mellan appar använder iOS mekanismerna Share Sheet och UIActivityViewController, som kopierar filen från en apps container till en annans. För säker lagring av inloggningsuppgifter (tokens, lösenord, nycklar) tillhandahåller iOS Keychain — en krypterad lagringsplats som är tillgänglig för systemet på kärnnivå. Keychain är inte en del av Sandbox-containern och hanteras av en separat securityd-demon, vilket ger ett extra skyddslager även om appen skulle äventyras.

Egenskaper hos filsystem: EXT4, APFS, F2FS

Valet av filsystem påverkar direkt prestanda och tillförlitlighet hos datalagring. Varje filsystem har sin egen arkitektur, optimeringar och begränsningar. Det är användbart för utvecklaren att förstå dessa skillnader för att förutsäga appens beteende på olika enheter.

• EXT4 — standard Linux-filsystem med journalföring, stöd för filer upp till 16 TB och volymer upp till 1 EB. Används på Android som huvudsakligt före införandet av F2FS. Ger tillförlitlighet tack vare journalen, men är sämre än F2FS när det gäller slumpmässig skrivhastighet på grund av behovet att uppdatera inoder och blockbitmappar vid varje operation
• F2FS — filsystem utvecklat av Samsung 2012 specifikt för NAND-flashminne. Tar hänsyn till flash-arrayens geometri, använder loggstrukturerad arkitektur och ger 25–40% högre slumpmässig skrivprestanda jämfört med EXT4. Från Android 11 rekommenderas F2FS av Google som det primära filsystemet för partitionen /data
• APFS — Apples filsystem, introducerat 2017. Stöder ögonblicksbilder, filkloning (copy-on-write), kryptering på filnivå och strikt dataintegritetskontroll via kontrollsummor. APFS är optimerat för SSD och använder TRIM-kommandon för att upprätthålla prestanda under hela lagringsenhetens livslängd
• exFAT — Microsofts filsystem, som används på SD-kort och USB-enheter. Stöder filer större än 4 GB och volymer upp till 128 PB. Har ingen journalföring, så ett plötsligt strömavbrott kan leda till dataskador. Rekommenderas för flyttbara media, men inte för systempartitioner

Vid apputveckling, beakta att olika filsystem har olika begränsningar för filnamnslängd (255 byte för EXT4 och F2FS, 255 Unicode-tecken för APFS), maximal filstorlek och stöd för specialtecken. Till exempel tillåter APFS Unicode-tecken i filnamn, inklusive emojis, medan EXT4 är begränsat till ASCII. Om appen skapar filer med namn på olika språk, testa funktionen på alla målenheter — ett filnamn som skapats korrekt på APFS kan trunkeras på EXT4.

Rekommendationer för arbete med filsystem

Tillförlitligt arbete med en mobil enhets filsystem kräver att flera viktiga regler följs. De baseras på analys av typiska utvecklarfel och rekommendationer från officiell dokumentation.

• Använd inte hårdkodade sökvägar till kataloger. Hämta alltid sökvägar via system-API:er: context.filesDir på Android, NSSearchPathForDirectoriesInDomains på iOS. Hårda sökvägar ändras mellan operativsystemversioner och enheter
• Hantera undantag för filoperationer: IOException, FileNotFoundException, SecurityException. På iOS kan alla FileManager-operationer kasta fel — omge dem med do-catch. På Android kan operationer med extern lagring misslyckas på grund av att media saknas
• Kontrollera tillgängligt utrymme före skrivning. Använd File.getUsableSpace() på Android och URLResourceValues.volumeAvailableCapacityKey på iOS. Varna användaren om det inte finns tillräckligt med ledigt utrymme
• Undvik att lagra stora filer i kataloger som ingår i säkerhetskopiering. På iOS, uteslut cache från säkerhetskopiering via isExcludedFromBackup. På Android, föredra cacheDir för temporära filer
• Testa beteendet vid full lagring och plötsligt strömavbrott. Använd transaktionsskrivning: skriv till en temporär fil, byt sedan atomärt namn

Ägna särskild uppmärksamhet åt plattformsskillnader. Sökvägar till filer på Android byggs med snedstreck (/data/data/.../files/), på iOS — via URL-schema (file:///var/mobile/.../Documents/). Om din app använder ett multiplattformsramverk (Flutter, React Native, Kotlin Multiplatform), enhetliggör filoperationer via plattformsadaptrar. Till exempel tillhandahåller Flutter paketet path_provider, som returnerar rätt sökväg till Documents eller filesDir på båda plattformarna utan att skriva plattformsberoende kod. Sammanfoga aldrig sökvägar med strängoperationer — använd File.join() eller URL.appendingPathComponent(), som korrekt hanterar avgränsare på olika plattformar.