Alkalmazás belső memóriája: mi ez, adattárolási módok és hogyan működik a fejlesztésben

Mi az alkalmazás belső memóriája?

Az alkalmazás belső memóriája egy izolált könyvtár, amelyet az operációs rendszer minden alkalmazás számára kijelöl a telepítésekor. Ehhez a könyvtárhoz más alkalmazások és a felhasználó sem férhet hozzá a szokásos fájlkezelőkön keresztül. A rendszer garantálja, hogy az ebben a könyvtárban lévő adatok teljes mértékben törlődnek az alkalmazás eltávolításakor. Ez a megközelítés képezi a mobil operációs rendszerek biztonsági modelljének alapját, megakadályozva a bizalmas információk kiszivárgását a programok között.

A külső tárhelytől (SD-kártya) eltérően a belső memória mindig elérhető, és nem igényli a tárolóeszköz meglétének ellenőrzését. Az olvasási és írási sebesség a modern eszközök NAND-flash memóriájában eléri a 800–900 MB/s szekvenciális olvasást és a 200–300 MB/s szekvenciális írást, ami összehasonlítható egy SATA SSD-vel. A kijelölt terület mérete az eszköz teljes kapacitásától és a gyártói politikától függ: a 64 GB flash memóriával rendelkező eszközökön az alkalmazás 16–64 MB kezdeti helyet kap, lehetőséggel a bővítésre szükség szerint.

A belső tároló architektúrája eltér Androidon és iOS-en. Androidon minden alkalmazás kap egy /data/data/<package_name>/ könyvtárat, amelyen belül a rendszer létrehozza a files/, cache/ és databases/ alkönyvtárakat. iOS-en az alkalmazás egy Sandbox-konténerben működik Documents/, Library/ és tmp/ könyvtárakkal, amelyek mindegyikének saját rendeltetése és biztonsági mentési politikája van.

Adattárolási módok a belső memóriában

A fejlesztők számára több módszer áll rendelkezésre az adatok mentésére az alkalmazás belső memóriájában. Minden módszer megold egy adott feladatot, és bizonyos adattípusokhoz illik. A megfelelő módszer kiválasztása közvetlenül befolyásolja az alkalmazás teljesítményét, a fejlesztés kényelmét és a felhasználói adatok biztonságát.

Izolált fájltároló

A legalacsonyabb szintű módszer a fájlok közvetlen írása a files könyvtárba. Az alkalmazás bármilyen fájlt és könyvtárat létrehozhat a saját homokozóján belül. Ez a módszer alkalmas médi fájlok, felhasználói dokumentumok és bármilyen bináris adat tárolására, amely nem igényel strukturált szervezést. Androidon a könyvtár elérése a Context.getFilesDir() híváson keresztül történik, amely visszaadja az alkalmazás fájlkönyvtárának abszolút elérési útját. iOS-en hasonló funkciót lát el a NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) függvény.

SharedPreferences és DataStore

Kulcs-érték párok tárolására az Android SharedPreferences-t és a modernebb DataStore-t kínálja Kotlin-korutinok és protobuf protokoll alapján. A SharedPreferences XML-fájlban tárolja az adatokat a /data/data/<package>/shared_prefs/ könyvtárban. Az egyszerű használat ellenére a SharedPreferences hátrányokkal rendelkezik: a szinkron írás késleltetést okozhat az UI-szálon, a típusbiztonság hiánya pedig növeli a hibák kockázatát. A DataStore megoldja ezeket a problémákat aszinkron API-val Flow alapján és teljes típus-támogatással protobuf-sémákon keresztül.

SQLite adatbázis és Room

Strukturált, relációs kapcsolatokkal rendelkező adatokhoz az optimális választás az SQLite vagy a Room burkoló. Az adatbázis egyetlen fájlban tárolódik a databases/ könyvtárban, és támogatja a teljes SQL-szintaxist. A Room a hivatalos Jetpack könyvtár, amely típusbiztos API-t, automatikus séma-migrációt és korutin-támogatást nyújt. Az adatbázis mérete elérheti a több gigabájtot anélkül, hogy jelentős teljesítményveszteséget okozna megfelelő indexelés mellett. Az SQLite mobileszközökön akár 50 000 írási műveletet is kezel másodpercenként egy modern csúcskategóriás processzoron.

EncryptedSharedPreferences

Bizalmas adatok, például hitelesítési tokenek és titkosítási kulcsok tárolására az Android EncryptedSharedPreferences-t biztosít. Ez a burkoló a szabványos SharedPreferences felett automatikusan titkosítja a kulcsokat és az értékeket AES256-GCM-None használatával. A titkosítás fájlszinten történik a lemezre írás előtt, így még fizikai hozzáférés esetén sem olvashatja a tartalmat egy támadó. Az EncryptedSharedPreferences az AndroidX Security könyvtár része, amely tartalmazza az EncryptedFile-t is a teljes fájlok titkosításához.

Hogyan dolgozzunk a belső memóriával Androidon

Android SDK metódusok készletét biztosítja a belső memóriával való munkához a Context osztályon keresztül. Minden metódus visszaadja az alkalmazás homokozóján belüli adott rendszerkönyvtár elérési útját. Tekintsük át az alapvető fájlírási és -olvasási műveleteket Kotlin példán keresztül.

Hozzáférés a filesDir-hez Context-en keresztül

A belső fájlkönyvtár elérési útjának lekéréséhez a fő metódus a context.filesDir. Ez egy File objektumot ad vissza, amely a /data/data/<package>/files/ könyvtárra mutat. Az első híváskor a rendszer automatikusan létrehozza az összes szükséges szülőkönyvtárat. A belső memóriában lévő fájlok mérete nincs explicit korlátozva, de az adatok teljes mennyisége nem haladhatja meg a /data partíció rendelkezésre álló területét, amely általában az eszköz flash memóriájának 60–80%-át teszi ki.

val context = getApplicationContext()
val file = File(context.filesDir, "notes.txt")

file.writeText("Jegyzet tartalma")

val content = file.readText()
println("Olvasva: $content")

A writeText és readText metódusok a Kotlin szabványos könyvtárának kiterjesztési függvényei. Automatikusan kezelik a streamek megnyitását és bezárását, ami kizárja a memóriaszivárgást. Bináris adatokhoz használja a writeBytes és readBytes függvényeket, amelyek nem igényelnek kódolást és ByteArray tömbökkel dolgoznak. Nagy fájlok esetén javasolt pufferelt streamek használata: BufferedReader és BufferedWriter szöveghez, BufferedInputStream és BufferedOutputStream bináris adatokhoz.

Alkönyvtárak létrehozása a belső memóriában

A fájlok hierarchikus szervezéséhez hozzon létre alkönyvtárakat a filesDir-en belül. Ez segít strukturálni az adatokat típus szerint: képek, dokumentumok, export fájlok. A mkdirs() metódus létrehozza az összes hiányzó könyvtárat az elérési útvonalon, beleértve a beágyazottakat is. Győződjön meg arról, hogy a létrehozási művelet sikeres volt — a metódus csak új könyvtárak létrehozásakor ad vissza true-t. A létrehozási hiba leggyakrabban a /data partíció helyhiányával vagy a fájlrendszer inode-ok kimerülésével kapcsolatos.

val imagesDir = File(context.filesDir, "images")
if (imagesDir.mkdirs()) {
    println("Könyvtár létrehozva")
}

val imageFile = File(imagesDir, "photo.jpg")
imageFile.writeBytes(byteArray)

A rendelkezésre álló terület ellenőrzéséhez nagy fájlok írása előtt használja a File.getFreeSpace() vagy File.getUsableSpace() függvényeket. A második metódus visszaadja a jelenlegi alkalmazás számára elérhető bájtok számát a biztonsági kvóták figyelembevételével — ez pontosabb többfelhasználós eszközök esetén. Ha a rendelkezésre álló terület kisebb a várt fájlméretnél, jelenítsen meg egy üzenetet a felhasználónak, és javasolja hely felszabadítását az eszköz beállításaiban.

Hogyan dolgozzunk a belső memóriával iOS-en

iOS-en minden alkalmazás egy izolált Sandbox-konténerben működik. A rendszer nem biztosít API-t a határainak elhagyásához külön jogosultságok nélkül. A fájlrendszerrel való munkához a fő eszköz a FileManager osztály a Foundation keretrendszerből. A Sandbox-konténer több szabványos könyvtárat tartalmaz, amelyek mindegyikének saját biztonsági mentési politikája van.

Hozzáférés a Documents könyvtárhoz FileManager-en keresztül

A Documents könyvtár felhasználói adatok számára készült, amelyeknek meg kell maradniuk az alkalmazás indításai között és vissza kell állítaniuk a biztonsági mentésből. Az iOS automatikusan belefoglalja ezt a könyvtárat az iCloud és iTunes biztonsági mentésbe. A urls(for:in:) metódus visszaadja a kért könyvtár URL-címeinek tömbjét — a tömb első eleme az elsődleges.

let fm = FileManager.default
let docs = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let fileURL = docs.appendingPathComponent("data.plist")
try data.write(to: fileURL)

FileManager támogatja a fájlműveletek teljes skáláját: létrehozás, másolás, áthelyezés, törlés és átnevezés. Minden művelet hibát dobhat, ezért az összes hívást do-catch szerkezetbe kell csomagolni. Különös figyelmet fordítson a fájlok törlésére — a művelet visszafordíthatatlan, és az adatok removeItem(at:) után nem állíthatók vissza előzetes biztonsági mentés nélkül.

Kivételek kezelése a biztonsági mentésből

Nem minden adat a Sandbox-konténerben kerülhet bele az iCloud biztonsági mentésbe. Például a letöltött képek gyorsítótárát vagy az ideiglenes feldolgozó fájlokat nem kell visszaállítani — ezek a következő használatkor újrateremtődnek. Egy könyvtár vagy fájl biztonsági mentésből való kizárásához állítsa az isExcludedFromBackup attribútumot true értékre. Az Apple azt javasolja, hogy mindig zárja ki a biztonsági mentésből azokat az adatokat, amelyek távolról újra letölthetők, hogy minimalizálja az iCloud tárhely méretét és csökkentse a helyreállítási időt.

var cacheURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!
cacheURL.hasExcludedFromBackupKey = true

var values = URLResourceValues()
values.isExcludedFromBackup = true
try cacheURL.setResourceValues(values)

A belső memória, a gyorsítótár és a külső tárhely közötti különbségek

Minden tárolótípusnak a mobileszközön megvan a saját rendeltetése és használati szabályai. E különbségek megértése segít a fejlesztőnek kiválasztani a megfelelő helyet minden adattípus számára. Az alábbiakban három fő tárolótípus összehasonlítása látható, amelyek az alkalmazás számára elérhetők.

Belső memória optimális az alkalmazás konfigurációinak, adatbázisfájloknak és felhasználói dokumentumoknak a tárolására, amelyeknek nem szabad elérhetőnek lenniük más programok számára. A gyorsítótár-könyvtár ideiglenes fájlok számára készült, amelyek a következő használatkor újrateremthetők: letöltött képek, API-válaszok, feldolgozási köztes adatok. A külső tárhely a legalkalmasabb nagy médi fájlok (fotók, videók, zene) és olyan adatok számára, amelyeket a felhasználó meg szeretne osztani más alkalmazásokkal közös hozzáférésen keresztül.

A tárolótípus kiválasztása befolyásolja az alkalmazás értékelését a Google Play-en és az App Store-ban is. Azok az alkalmazások, amelyek nagy mennyiségű adatot tárolnak a belső memóriában tisztítás nélkül, negatív visszajelzéseket kapnak: a felhasználók a helyhiányra panaszkodnak. Az App Annie kutatása szerint a felhasználók 62%-a törli az alkalmazást, ha az több mint 500 MB belső memóriát foglal el tisztítási lehetőség nélkül.

Javaslatok a belső memória használatához

A belső memória megfelelő kezelése növeli a teljesítményt, a biztonságot és a felhasználói élményt. Az alábbi javaslatok az Android és iOS hivatalos dokumentációján, valamint a milliós telepítésszámú alkalmazások fejlesztésének gyakorlati tapasztalatain alapulnak.

• Minimalizálja a tárolt adatok mennyiségét. Használja a belső memóriát csak a kritikus fontosságú fájlokhoz, a többit helyezze el a gyorsítótárban vagy a külső tárhelyen
• Rendszeresen tisztítsa az ideiglenes fájlokat. Ellenőrizze a cache könyvtárat minden indításkor, és törölje a 24 óránál régebbi fájlokat — ez csökkenti a rendszer terhelését és megakadályozza a /data partíció túltöltését
• Titkosítsa a bizalmas adatokat az EncryptedSharedPreferences vagy EncryptedFile segítségével az AndroidX Security könyvtárból. A tokenek és jelszavak nyílt szövegként való tárolása gyakori biztonsági rés, amelyet a root-hozzáféréssel rendelkező trójaiak kihasználnak
• Használjon migrációt a fájlszerkezet frissítésekor. Az alkalmazás új verziójának kiadásakor ellenőrizze a régi fájlok meglétét, és helyezze át őket az új könyvtárakba, mielőtt törölné a régieket

Külön figyelmet kell szentelni a határesetek tesztelésének. Ellenőrizze az alkalmazás viselkedését a belső memória túltöltése, a váratlan írásmegszakítás (alkalmazás összeomlása, hívás) és az iOS biztonsági mentésből való visszaállítás esetén. Mindegyik forgatókönyvben az adatoknak konzisztensnek kell maradniuk vagy vissza kell állniuk az utolsó stabil állapotba. Használjon tranzakciós fájlokat: írja az adatokat egy ideiglenes fájlba, majd atomikusan nevezze át a célfájllá. Ez megakadályozza a sérült adatok olvasását írási hiba esetén.

Ne feledkezzen meg a felhasználói kontrollról. Biztosítson lehetőséget az alkalmazás beállításaiban az ideiglenes adatok tisztítására és a felhasznált belső memória méretének megjelenítésére. A Google Play Console adatai szerint az ilyen funkcióval rendelkező alkalmazások 18%-kal több pozitív értékelést kapnak a "Teljesítmény" kategóriában.