SharedPreferences: vad det är, nyckel-värde-lager i Android

Vad är SharedPreferences?

SharedPreferences är en inbyggd Android-mekanism för lagring av nyckel-värde-par i en XML-fil på enhetens interna lagring. Den är tillgänglig från API Level 1 och kräver inga extra bibliotek. Huvudsyftet är att spara användarinställningar, gränssnittsstatus, first-launch-flaggor och andra enkla data som inte kräver en strukturerad databas.

Varje SharedPreferences-fil är kopplad till ett specifikt namn och åtkomstläge. Som standard används Context.MODE_PRIVATE, som begränsar åtkomsten till filen endast för den aktuella appen. Tidigare stödde Android lägena MODE_WORLD_READABLE och MODE_WORLD_WRITEABLE, men de förklarades föråldrade från API Level 17 och togs bort helt i Android 7.0 (API 24) av säkerhetsskäl.

Trots sin enkelhet används SharedPreferences i miljontals Android-appar. Enligt Google använder över 90% av apparna som publiceras på Google Play SharedPreferences för att lagra inställningar. För komplexa scenarier (stora datamängder, typsäkerhet, asynkronicitet) rekommenderar Google dock modernare lösningar som Preferences DataStore från Android Jetpack-biblioteket.

Lagringsformat: XML på enheten

Fysiskt lagras SharedPreferences som en XML-fil i appens katalog: /data/data/{package_name}/shared_prefs/{file_name}.xml. Filen innehåller rotelementet <map> med underordnade element <string>, <int>, <boolean>, <float> och <long> beroende på typen av lagrat värde. Filstorleken är inte begränsad, men för stora datamängder (över 100 KB) börjar läsprestandan och skrivprestandan märkbart minska.

SharedPreferences-filer är inte krypterade som standard. Data lagras i öppen form på enhetens filsystem. För lagring av känsliga data (token, lösenord) rekommenderas att använda EncryptedSharedPreferences från AndroidX Security-biblioteket, som automatiskt krypterar nycklar och värden med AES256-GCM.

Hur SharedPreferences fungerar i Android

SharedPreferences fungerar enligt principen om cachelagring i minnet med periodisk synkronisering till disk. Vid första åtkomst till filen (via getSharedPreferences) laddar Android XML-filen i RAM och parsar den till ett Map-objekt. Alla efterföljande läsoperationer utförs från minnet, utan att läsa om från disken. Detta säkerställer hög åtkomsthastighet till data.

Skrivoperationer använder Editor — en intern buffert för ändringar. När utvecklaren anropar putString eller putBoolean lagras ändringarna i Editor-objektet i minnet. Den faktiska skrivningen till disk sker vid anrop av metoden commit (synkront) eller apply (asynkront). Tills dessa metoder anropas sparas inte data, och vid oväntad avslutning av appen kan ändringarna gå förlorade.

Åtkomstlägen och kontext

För att få en SharedPreferences-instans används två metoder: getPreferences och getSharedPreferences. Den första är endast tillgänglig inom Activity och skapar en fil med Activitys namn. Den andra är mer flexibel, accepterar filnamn och åtkomstläge, och är tillgänglig från vilken kontext som helst (Application, Activity, Service). Det rekommenderas att använda getSharedPreferences med ett filnamn som motsvarar appens modul eller funktionalitet.

// Hämta SharedPreferences
val prefs = context.getSharedPreferences(
    "user_settings", Context.MODE_PRIVATE
)

// Skriva data
with(prefs.edit()) {
    putString("username", "Anna")
    putInt("age", 28)
    putBoolean("isLoggedIn", true)
    apply()
}

// Läsa data
val username = prefs.getString("username", "")
val age = prefs.getInt("age", 0)
val isLoggedIn = prefs.getBoolean("isLoggedIn", false)

Vid användning av MODE_MULTI_PROCESS (föråldrat) synkroniseras SharedPreferences mellan processer. Denna synkronisering garanterar dock inte atomicitet, och Google rekommenderar att undvika SharedPreferences i multi-process-scenarier. För sådana fall är det bättre att använda ContentProvider, Room med inter-process-åtkomst eller DataStore.

Huvudmetoder för SharedPreferences

SharedPreferences tillhandahåller en uppsättning metoder för att läsa data efter nyckel och Editor-gränssnittet för att skriva. Varje läshmetod accepterar två parametrar: nyckeln och ett standardvärde som returneras om nyckeln inte hittas. Standardvärdet bestämmer också typen av returvärde: getString returnerar String, getInt returnerar Int och så vidare.

Editor och apply vs commit

Editor är det interna SharedPreferences-objektet som samlar ändringar i en buffert. Efter att alla ändringar har gjorts anropar utvecklaren commit() (synkron skrivning) eller apply() (asynkron skrivning). Skillnaden är kritisk: commit blockerar den aktuella tråden tills fullständig skrivning till disken och returnerar boolean (framgång/misslyckande), medan apply utför skrivningen i bakgrunden och omedelbart återger kontrollen, men returnerar inget resultat.

Det rekommenderas att använda apply istället för commit i alla fall där resultatet av skrivningen inte behöver vara känt. apply är snabbare och blockerar inte UI-tråden. commit bör endast användas när det är kritiskt att veta om data sparades framgångsrikt eller vid arbete med multi-process-läge. För borttagning av enskilda nycklar används metoden remove, för fullständig rensning — clear. Alla borttagningsoperationer utförs också via Editor.

// Flera ändringar - en apply
prefs.edit {
    putString("theme", "dark")
    putBoolean("notifications", false)
    remove("old_key")
}

// Lyssnare på värdeändring
prefs.registerOnSharedPreferenceChangeListener { prefs, key ->
    Log.d("TAG", "Nyckel ändrades: $key")
}

Från Android 12 (API 31) har SharedPreferences utökats med stöd för registerOnSharedPreferenceChangeListener med automatisk avprenumeration via Lifecycle. Detta gör det möjligt att undvika minnesläckor relaterade till glömda lyssnare. I äldre versioner måste utvecklaren manuellt anropa unregisterOnSharedPreferenceChangeListener i komponentens onDestroy eller onStop.

SharedPreferences vs lagringsalternativ

Trots sin utbredda användning är SharedPreferences inte en universallösning för alla datalagringsscenarier i Android. Beroende på datamängd, krav på typsäkerhet och prestanda rekommenderar Google olika alternativ som ingår i Android Jetpack och standard Android-biblioteket.

DataStore — modernt alternativ

DataStore är ett Android Jetpack-bibliotek som presenterades av Google som ersättning för SharedPreferences. Det erbjuder två varianter: Preferences DataStore (nyckel-värde, som SharedPreferences) och Proto DataStore (typad lagring via Protocol Buffers). DataStore använder korutiner och Flow för asynkront arbete, garanterar typsäkerhet och hanterar automatiskt versionsmigreringar. Google rekommenderar DataStore för alla nya projekt.

Den största fördelen med DataStore är asynkronicitet på API-nivå. Alla läsoperationer returnerar Flow och skrivoperationer är suspend-funktioner. Detta eliminerar helt blockering av UI-tråden, vilket är möjligt vid synkron läsning av SharedPreferences. Dessutom garanterar DataStore datakonsistens: skrivning utförs i en transaktion och vid fel återställs alla ändringar.

Exempel på användning av SharedPreferences i en app

Låt oss titta på ett praktiskt exempel: temainställningar (ljus/mörker/system) i en Android-app. Användaren väljer ett tema och valet sparas i SharedPreferences. Vid efterföljande appstarter återställs temat från sparade inställningar. För reaktiv gränssnittsuppdatering används observation av ändringar via SharedPreferences.OnSharedPreferenceChangeListener.

Spara användarinställningar

Vi skapar en klass ThemePreferences som kapslar in allt arbete med SharedPreferences för temat. Klassen tillhandahåller metoderna getTheme (läsning), setTheme (skrivning) och observeTheme (observation). Inställningsfilens namn blir "app_preferences" med MODE_PRIVATE-läge. För enkelhetens skull är nycklar utbrutna till companion object som konstanter.

class ThemePreferences(context: Context) {
    companion object {
        private const val PREF_NAME = "app_preferences"
        private const val KEY_THEME = "theme_mode"
        const val THEME_LIGHT = "light"
        const val THEME_DARK = "dark"
        const val THEME_SYSTEM = "system"
    }

    private val prefs = context
        .getSharedPreferences(PREF_NAME, Context.MODE_PRIVATE)

    fun getTheme(): String =
        prefs.getString(KEY_THEME, THEME_SYSTEM) ?: THEME_SYSTEM

    fun setTheme(theme: String) {
        prefs.edit { putString(KEY_THEME, theme) }
    }

    fun observeTheme(callback: (String) -> Unit) {
        prefs.registerOnSharedPreferenceChangeListener { _, key ->
            if (key == KEY_THEME) {
                callback.invoke(getTheme())
            }
        }
    }
}

I Activity eller Fragment erhålls instansen av ThemePreferences via appkontexten. Vid initialisering anropas getTheme för att ställa in aktuellt tema. När användaren väljer ett nytt tema anropas setTheme, och via observeTheme uppdateras gränssnittet utan att starta om Activity. Det är viktigt att inte glömma att avregistrera lyssnaren i onDestroy för att förhindra minnesläckor, särskilt om Activity återskapas vid konfigurationsändringar.

För appar med minsta målversion Android 12+ rekommenderas att använda registerOnSharedPreferenceChangeListener tillsammans med LifecycleObserver. Detta hanterar automatiskt prenumeration och avprenumeration vid ändring av komponentens livscykel. För äldre versioner måste prenumeration och avprenumeration hanteras manuellt, vilket är en vanlig källa till fel i produktionsappar som använder SharedPreferences.