Cache und Datensynchronisation in der mobilen Entwicklung: was es ist, welche Strategien und wie es funktioniert

Datenverarbeitung in mobilen Apps: Repository-Muster und Data Source

Das Repository-Muster ist ein architektonischer Ansatz, bei dem eine einzelne Repository-Klasse alle Datenoperationen verwaltet und entfernte REST-APIs sowie lokalen Speicher (Room oder SwiftData) abstrahiert. Diese Art der Datenverarbeitung ermöglicht es der App, Informationen zuerst aus dem Memory Cache oder Disk Cache und dann aus dem Netzwerk abzurufen, was die Antwortzeit verkürzt. In der mobilen Entwicklung ist das Repository dank der Empfehlungen von Google und Apple zum De-facto-Standard geworden.

Remote Data Source und Local Data Source

Remote Data Source liefert aktuelle Informationen vom Server über HTTP-Anfragen. Local Data Source ist der lokale Speicher auf dem Gerät, implementiert über Room auf Android oder SwiftData auf iOS. Das Repository kombiniert beide Quellen: Es prüft zuerst den lokalen Cache und fordert bei fehlenden Daten von der entfernten API an. Diese Organisation der Datenverarbeitung ermöglicht es der App, im Offline-Modus zu funktionieren und die Serverlast zu reduzieren.

Repository-Beispiel in 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-Beispiel in 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
    }
}

Daten-Caching: LRU Cache, Disk Cache und Memory Cache

LRU Cache (Least Recently Used) ist ein Caching-Algorithmus, bei dem bei Erreichen des Limits das Element entfernt wird, auf das am längsten nicht zugegriffen wurde. In mobilen Apps wird LRU Cache für Bilder, API-Antworten und serialisierte Objekte verwendet. Richtiges Daten-Caching reduziert die Anzahl der Netzwerkanfragen und beschleunigt das Laden von Inhalten. Cache in mobilen Apps ist eine wesentliche Komponente für hohe Leistung.

Memory Cache vs Disk Cache

Memory Cache speichert Daten im RAM — der Zugriff ist extrem schnell, aber die Kapazität ist durch die Heap-Größe der App begrenzt. Disk Cache speichert Informationen im Dateisystem — er ist langsamer, kann aber mehr aufnehmen und bleibt zwischen Sitzungen erhalten. Die optimale Strategie in der mobilen Entwicklung ist ein zweistufiger Cache: Memory Cache für heiße Daten und Disk Cache für kalte Daten. Bei der Datenverarbeitung wird zuerst der Cache der ersten Ebene im Speicher und dann der Cache der zweiten Ebene auf der Festplatte überprüft.

LRU Cache Implementierungsbeispiel

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-Invalidierungsstrategien

TTL-Cache (Time To Live) entfernt einen Eintrag automatisch nach einem bestimmten Zeitintervall — geeignet für API-Daten. Ereignisgesteuerte Invalidierung leert den Cache beim Empfang einer Push-Benachrichtigung über Änderungen. In mobilen Apps hängt die Wahl der Caching-Strategie vom Datentyp ab: Bilder werden lange zwischengespeichert, während ein Nachrichtenfeed häufige Invalidierung erfordert. Coil auf Android und Kingfisher auf iOS haben bereits LRU Cache für die Arbeit mit Bildern integriert.

Offline-Warteschlange: Offline Queue und Sync Manager

Offline Queue ist eine Datenstruktur, die Benutzeroperationen (Erstellen, Aktualisieren, Löschen) in einer lokalen Datenbank speichert, wenn das Gerät offline ist. Bei Wiederherstellung der Verbindung wendet der Sync Manager diese Operationen nacheinander auf dem Server an. Diese Art der Datensynchronisation stellt sicher, dass bei einem vorübergehenden Netzwerkverlust keine Änderung verloren geht. In der mobilen Entwicklung ist die Offline Queue eine kritische Komponente für Apps mit instabilen Verbindungen.

Architektur der Offline Queue

Die Warteschlange wird auf einer Tabelle in Room oder SwiftData mit Feldern aufgebaut: Operationstyp, JSON-Anfragekörper, Zeitstempel und Status. Sync Manager ist ein Hintergrunddienst, der ausstehende Operationen verarbeitet, an den Server sendet, den Status aktualisiert und erfolgreiche Einträge entfernt. Die Datensynchronisation über WorkManager auf Android oder BGTaskScheduler auf iOS wird auch nach einem Geräteneustart fortgesetzt. Die Verwendung der Offline Queue in Verbindung mit korrekter Datenverarbeitung gewährleistet ein nahtloses Benutzererlebnis.

Offline Queue Beispiel in 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
            }
        }
    }
}

Wiederholungsrichtlinie und Timeouts

Exponentielles Backoff zwischen Wiederholungen (1s, 2s, 4s, 8s) schützt den Server vor Überlastung und verhindert unendliche Wiederholungen. Das Limit von 5 Versuchen verhindert ein Überlaufen der Warteschlange. Die Datensynchronisation in mobilen Apps mit serverseitiger Idempotenzunterstützung ermöglicht sichere Wiederholungen und vermeidet Duplikate. Dies ist besonders wichtig für Finanztransaktionen und Bestellungen.

Datensynchronisation: Conflict Resolution und Schema Migration

Conflict Resolution ist eine Reihe von Strategien für Situationen, in denen dieselben Daten auf verschiedenen Geräten gleichzeitig geändert werden. Die grundlegende Datensynchronisation erfordert die Wahl eines Ansatzes: Last-Write-Wins (der letzte Schreibvorgang gewinnt), Versionierung (höhere Version gewinnt) oder manuelle Auflösung. In komplexen Szenarien werden CRDT (Conflict-Free Replicated Data Types) verwendet, die mathematische Konvergenz der Daten gewährleisten.

Konfliktlösungsstrategien

Last-Write-Wins ist am einfachsten zu implementieren, kann aber Benutzeränderungen verlieren. Version Vector — jeder Datensatz speichert eine Versionsnummer und Gerätekennung; ein Konflikt entsteht, wenn die Versionen nicht übereinstimmen. CRDT ist die zuverlässigste, aber komplexe Strategie: Daten konvergieren mathematisch zu einem einzigen Zustand ohne zentralen Koordinator. Die auf CRDT basierende Datensynchronisation in mobilen Apps wird in der kollaborativen Bearbeitung in Google Docs und der Notizsynchronisation in Notion verwendet.

Schema Migration: Sichere Datenbankaktualisierung

Bei einem App-Update ändert sich die lokale Datenbankstruktur: Spalten, Tabellen, Indizes werden hinzugefügt. Schema Migration ist der Prozess der Umwandlung einer bestehenden Datenbank in ein neues Schema ohne Datenverlust. Room unterstützt Migrationen über die Migration-Klasse mit alter und neuer Version. SwiftData verwendet VersionedSchema zur Beschreibung von Änderungen. Die ordnungsgemäße Datensynchronisation zwischen App-Versionen erfordert, dass Migrationen idempotent getestet werden.

Schema Migration Beispiel in 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 Beispiel in 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 und SwiftData für lokale Speicherung

Room ist eine Google-Bibliothek für lokale Speicherung auf Android, die auf SQLite aufbaut und Annotationen für deklarative Abfragebeschreibungen bereitstellt. SwiftData ist ein Apple-Framework für iOS, macOS, watchOS und visionOS, der Nachfolger von Core Data mit einer prägnanten Swift-Macro-Syntax. Beide Tools lösen die Aufgabe der Datenverarbeitung auf dem Gerät, jedoch mit unterschiedlichen Ansätzen zur Code-Organisation. Cache in mobilen Apps wird oft auf diesen Technologien aufgebaut.

Room: DAO, Entitäten und Type Converter

Room verwendet @Entity-Annotationen für Tabellen und @Dao für Abfragen. DAO kapselt alle SQL-Operationen mit Kompilierzeitprüfung — SQL-Syntaxfehler werden vor der Laufzeit erkannt. Type Converter konvertiert komplexe Typen (Date, List) in SQLite-Primitive. Moderne Datenverarbeitung in Android-Apps basiert auf Room + Flow und bietet reaktive UI-Updates bei Änderungen des Caches oder der lokalen Datenbank.

SwiftData: @Model und @Query

SwiftData verwendet das Makro @Model zur Definition von Entitäten und @Query zur Datenbeobachtung. Das Framework verfolgt automatisch Abhängigkeiten und aktualisiert die Oberfläche bei Änderungen. Schema-Migration verwendet VersionedSchema, das alle Versionen beschreibt. Die Datensynchronisation zwischen SwiftData und dem Server wird über einen benutzerdefinierten Sync Manager implementiert, der Updates via @Query abonniert.

SwiftData Modellbeispiel

@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()
    }
}

Room vs SwiftData Vergleich