Cache och datasynkronisering i mobil utveckling: vad det är, vilka strategier och hur det fungerar

Datahantering i Mobila Applikationer: Repository-mönster och Data Source

Repository-mönstret är ett arkitekturmönster där en enda repository-klass hanterar alla dataoperationer och abstraherar fjärr-REST API:er och lokal lagring Room eller SwiftData. Detta sätt att hantera data gör att applikationen först kan hämta information från Memory Cache eller Disk Cache och sedan från nätverket, vilket minskar svarstiden. I mobil utveckling har Repository blivit de facto-standard tack vare rekommendationer från Google och Apple.

Remote Data Source och Local Data Source

Remote Data Source tillhandahåller aktuell information från servern via HTTP-förfrågningar. Local Data Source är lokal lagring på enheten, implementerad via Room på Android eller SwiftData på iOS. Repositoryt kombinerar båda källorna: det kontrollerar först den lokala cachen och vid frånvaro av data begär det från det fjärranslutna API:et. Denna organisation av datahantering gör att applikationen kan fungera i offline-läge och minskar serverbelastningen.

Repository-exempel i Kotlin

class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUsers(): List<User> {
        localDataSource.getCachedUsers()?.let { return it }
        val users = remoteDataSource.fetchUsers()
        localDataSource.cacheUsers(users)
        return users
    }
}

Repository-exempel i Swift

class UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource
    
    func getUsers() async throws -> [User] {
        if let cached = await local.getCached() { return cached }
        let users = try await remote.fetch()
        await local.save(users)
        return users
    }
}

Datacachning: LRU Cache, Disk Cache och Memory Cache

LRU Cache (Least Recently Used) är en cachalgoritm där, när gränsen nås, elementet som inte har använts under längst tid tas bort. I mobila applikationer används LRU Cache för bilder, API-svar och serialiserade objekt. Korrekt datacachning minskar antalet nätverksförfrågningar och snabbar upp inläsning av innehåll. Cache i mobila applikationer är en väsentlig komponent för hög prestanda.

Memory Cache vs Disk Cache

Memory Cache lagrar data i RAM — åtkomsten är extremt snabb, men kapaciteten begränsas av applikationens heapstorlek. Disk Cache sparar information på filsystemet — långsammare men kan lagra mer och består mellan sessioner. Den optimala strategin i mobil utveckling är en tvånivåcache: Memory Cache för heta data och Disk Cache för kalla data. Vid datahantering kontrolleras först cachen på första nivån i minnet, följt av cachen på andra nivån på disken.

LRU Cache Implementeringsexempel

class MemoryCache<K, V>(
    private val maxSize: Int = 100
) {
    private val cache = LinkedHashMap<K, V>(0, 0.75f, true)

    fun get(key: K): V? = cache[key]

    fun put(key: K, value: V) {
        if (cache.size >= maxSize) {
            cache.remove(cache.keys.first())
        }
        cache[key] = value
    }
}

Cache-invalideringsstrategier

TTL-cache (Time To Live) tar automatiskt bort en post efter ett angivet tidsintervall — lämplig för API-data. Händelsestyrd invalidering rensar cachen vid mottagande av ett push-meddelande om ändringar. I mobila applikationer beror valet av cachningsstrategi på datatypen: bilder cachas under lång tid, medan en nyhetsflöde kräver frekvent invalidering. Coil på Android och Kingfisher på iOS har redan integrerat LRU Cache för att arbeta med bilder.

Offlinekö: Offline Queue och Sync Manager

Offline Queue är en datastruktur som lagrar användaroperationer (skapa, uppdatera, ta bort) i en lokal databas när enheten är offline. När anslutningen återställs tillämpar Sync Manager dessa operationer sekventiellt på servern. Denna typ av datasynkronisering säkerställer att ingen ändring går förlorad under tillfällig nätverksförlust. I mobil utveckling är Offline Queue en kritisk komponent för applikationer med instabila anslutningar.

Offline Queue Arkitektur

Kön byggs på en tabell i Room eller SwiftData med fält: operationstyp, JSON-förfrågekropp, tidsstämpel och status. Sync Manager är en bakgrundstjänst som bearbetar väntande operationer, skickar dem till servern, uppdaterar status och tar bort lyckade poster. Datasynkronisering via WorkManager på Android eller BGTaskScheduler på iOS fortsätter även efter omstart av enheten. Att använda Offline Queue tillsammans med korrekt datahantering säkerställer en sömlös användarupplevelse.

Offline Queue-exempel i Kotlin

@Entity
data class SyncOperation(
    @PrimaryKey val id: Long,
    val endpoint: String,
    val method: String,
    val body: String,
    val createdAt: Long
)

class SyncManager(
    private val dao: SyncOperationDao,
    private val api: ApiService
) {
    suspend fun syncPending() {
        dao.getPendingOperations().forEach { op ->
            try {
                api.execute(op.endpoint, op.method, op.body)
                dao.delete(op.id)
            } catch (e: Exception) {
                // retry on next cycle
            }
        }
    }
}

Försökspolicy och Timeouts

Exponentiell backoff mellan försök (1s, 2s, 4s, 8s) skyddar servern från plötslig överbelastning och förhindrar oändliga försök. Gränsen på 5 försök förhindrar att kön svämmar över. Datasynkronisering i mobila applikationer med stöd för idempotens på serversidan möjliggör säkra försök och undviker duplicering. Detta är särskilt viktigt för finansiella transaktioner och beställningar.

Datasynkronisering: Conflict Resolution och Schema Migration

Conflict Resolution är en uppsättning strategier för situationer där samma data ändras på olika enheter samtidigt. Grundläggande datasynkronisering kräver val av en metod: Last-Write-Wins (den senaste skrivningen vinner), versionshantering (högre version vinner) eller manuell lösning. I komplexa scenarier används CRDT (Conflict-Free Replicated Data Types), som garanterar matematisk konvergens av data.

Konfliktlösningsstrategier

Last-Write-Wins är enklast att implementera men kan förlora användarändringar. Version Vector — varje post lagrar ett versionsnummer och enhets-ID; en konflikt uppstår när versionerna inte matchar. CRDT är den mest pålitliga men komplexa strategin: data konvergerar matematiskt till ett enda tillstånd utan centraliserad koordinator. Datasynkronisering i mobila applikationer baserad på CRDT används i samarbetsredigering i Google Docs och anteckningssynkronisering i Notion.

Schema Migration: Säker Databasuppdatering

När en applikation uppdateras ändras den lokala databasstrukturen: kolumner, tabeller, index läggs till. Schema Migration är processen att omvandla en befintlig databas till ett nytt schema utan dataförlust. Room stöder migreringar via klassen Migration med gammal och ny version. SwiftData använder VersionedSchema för att beskriva ändringar. Korrekt datasynkronisering mellan applikationsversioner kräver att migreringar testas idempotent.

Schema Migration-exempel i Room

val migration1to2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN avatar_url TEXT")
    }
}

@Database(
    entities = [User::class],
    version = 2
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Conflict Resolution-exempel i Swift

enum ConflictStrategy {
    case lastWriteWins
    case versionVector
    case crdt
}

struct VersionedDocument {
    let id: String
    let version: Int
    let data: Data
    let editedBy: String
    
    func resolve(with remote: VersionedDocument) -> VersionedDocument {
        return version >= remote.version ? self : remote
    }
}

Room och SwiftData för Lokal Lagring

Room är ett Google-bibliotek för lokal lagring på Android, byggt på SQLite och tillhandahåller annotationer för deklarativ frågebeskrivning. SwiftData är ett Apple-ramverk för iOS, macOS, watchOS och visionOS, efterföljare till Core Data med en koncis Swift Macro-syntax. Båda verktygen löser uppgiften att hantera data på enheten, men med olika metoder för kodorganisation. Cache i mobila applikationer byggs ofta just på dessa teknologier.

Room: DAO, Entities och Type Converters

Room använder @Entity-annotationer för tabeller och @Dao för frågor. DAO inkapslar alla SQL-operationer med kompileringskontroll — SQL-syntaxfel upptäcks före körning. Type Converter konverterar komplexa typer (Date, List) till SQLite-primitiver. Modern datahantering i Android-applikationer bygger på Room + Flow, vilket ger reaktiva UI-uppdateringar när cachen eller den lokala databasen ändras.

SwiftData: @Model och @Query

SwiftData använder makrot @Model för att definiera entiteter och @Query för att observera data. Ramverket spårar automatiskt beroenden och uppdaterar gränssnittet vid ändringar. Schema-migrering använder VersionedSchema som beskriver alla versioner. Datasynkronisering mellan SwiftData och servern implementeras via en anpassad Sync Manager som prenumererar på uppdateringar via @Query.

SwiftData Modelexempel

@Model
final class UserModel {
    var id: String
    var name: String
    var email: String
    var updatedAt: Date
    
    init(id: String, name: String, email: String) {
        self.id = id
        self.name = name
        self.email = email
        self.updatedAt = Date()
    }
}

Jämförelse Room vs SwiftData