Pamięć podręczna i synchronizacja danych w rozwoju mobilnym: co to jest, jakie strategie i jak działa

Praca z danymi w aplikacjach mobilnych: wzorzec Repository i Data Source

Wzorzec Repository to podejście architektoniczne, w którym pojedyncza klasa repozytorium zarządza wszystkimi operacjami na danych, abstrahując zdalne REST API i lokalne przechowywanie Room lub SwiftData. Taki sposób pracy z danymi pozwala aplikacji pobierać informacje najpierw z Memory Cache lub Disk Cache, a następnie z sieci, skracając czas odpowiedzi. W rozwoju mobilnym Repository stało się standardem de facto dzięki rekomendacjom Google i Apple.

Remote Data Source i Local Data Source

Remote Data Source dostarcza aktualne informacje z serwera poprzez żądania HTTP. Local Data Source to lokalne przechowywanie na urządzeniu, zaimplementowane przez Room na Androidzie lub SwiftData na iOS. Repozytorium łączy oba źródła: najpierw sprawdza lokalną pamięć podręczną, a w przypadku braku danych żąda ze zdalnego API. Taka organizacja pracy z danymi pozwala aplikacji działać w trybie offline i zmniejsza obciążenie serwera.

Przykład Repository w 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
    }
}

Przykład Repository w 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
    }
}

Buforowanie danych: LRU Cache, Disk Cache i Memory Cache

LRU Cache (Least Recently Used) to algorytm buforowania, w którym po osiągnięciu limitu usuwany jest element, do którego najdłużej nie było dostępu. W aplikacjach mobilnych LRU Cache jest używany do obrazów, odpowiedzi API i serializowanych obiektów. Odpowiednie buforowanie danych zmniejsza liczbę żądań sieciowych i przyspiesza ładowanie treści. Pamięć podręczna w aplikacjach mobilnych jest niezbędnym komponentem wysokiej wydajności.

Memory Cache vs Disk Cache

Memory Cache przechowuje dane w pamięci RAM — dostęp jest niezwykle szybki, ale pojemność jest ograniczona rozmiarem sterty aplikacji. Disk Cache zapisuje informacje w systemie plików — działa wolniej, ale może pomieścić więcej i utrzymuje się między sesjami. Optymalna strategia w rozwoju mobilnym to dwupoziomowa pamięć podręczna: Memory Cache dla gorących danych i Disk Cache dla zimnych danych. Podczas pracy z danymi najpierw sprawdzana jest pamięć podręczna pierwszego poziomu w pamięci RAM, a następnie pamięć podręczna drugiego poziomu na dysku.

Przykład implementacji LRU Cache

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

Strategie unieważniania pamięci podręcznej

Pamięć podręczna TTL (Time To Live) automatycznie usuwa wpis po określonym czasie — odpowiednia dla danych API. Unieważnianie sterowane zdarzeniami czyści pamięć podręczną po otrzymaniu push notification o zmianach. W aplikacjach mobilnych wybór strategii buforowania zależy od typu danych: obrazy są buforowane długo, podczas gdy kanał informacyjny wymaga częstego unieważniania. Coil na Androidzie i Kingfisher na iOS już wbudowały LRU Cache do pracy z obrazami.

Kolejka offline: Offline Queue i Sync Manager

Offline Queue to struktura danych przechowująca operacje użytkownika (tworzenie, aktualizacja, usuwanie) w lokalnej bazie danych, gdy urządzenie jest offline. Po przywróceniu połączenia Sync Manager sekwencyjnie stosuje te operacje na serwerze. Ten rodzaj synchronizacji danych gwarantuje, że żadna zmiana nie zostanie utracona podczas tymczasowej utraty sieci. W rozwoju mobilnym Offline Queue jest krytycznym komponentem dla aplikacji z niestabilnym połączeniem.

Architektura Offline Queue

Kolejka jest budowana na tabeli w Room lub SwiftData z polami: typ operacji, treść żądania JSON, znacznik czasu i status. Sync Manager to usługa w tle, która przetwarza oczekujące operacje, wysyła je na serwer, aktualizuje status i usuwa udane wpisy. Synchronizacja danych przez WorkManager na Androidzie lub BGTaskScheduler na iOS jest kontynuowana nawet po ponownym uruchomieniu urządzenia. Użycie Offline Queue w połączeniu z odpowiednią pracą z danymi zapewnia bezproblemowe doświadczenie użytkownika.

Przykład Offline Queue w 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
            }
        }
    }
}

Polityka ponownych prób i limity czasu

Wykładnicze opóźnienie między ponownymi próbami (1s, 2s, 4s, 8s) chroni serwer przed lawinowym obciążeniem i zapobiega nieskończonym próbom. Limit 5 prób zapobiega przepełnieniu kolejki. Synchronizacja danych w aplikacjach mobilnych z obsługą idempotentności po stronie serwera pozwala na bezpieczne ponawianie operacji, unikając duplikatów. Jest to szczególnie ważne w przypadku transakcji finansowych i zamówień.

Synchronizacja danych: Conflict Resolution i Schema Migration

Conflict Resolution to zestaw strategii dla sytuacji, w których te same dane są modyfikowane na różnych urządzeniach jednocześnie. Podstawowa synchronizacja danych wymaga wyboru podejścia: Last-Write-Wins (wygrywa ostatni zapis), versionowanie (wygrywa wyższa wersja) lub ręczne rozwiązywanie. W złożonych scenariuszach stosuje się CRDT (Conflict-Free Replicated Data Types), gwarantujące matematyczną zbieżność danych.

Strategie rozwiązywania konfliktów

Last-Write-Wins jest najprostsze w implementacji, ale może utracić zmiany użytkownika. Version Vector — każdy rekord przechowuje numer wersji i identyfikator urządzenia; konflikt powstaje, gdy wersje nie są zgodne. CRDT to najbardziej niezawodna, ale złożona strategia: dane matematycznie zbiegają się do jednego stanu bez scentralizowanego koordynatora. Synchronizacja danych w aplikacjach mobilnych oparta na CRDT jest używana we wspólnej edycji w Google Docs i synchronizacji notatek w Notion.

Schema Migration: bezpieczna aktualizacja bazy danych

Podczas aktualizacji aplikacji struktura lokalnej bazy danych zmienia się: dodawane są kolumny, tabele, indeksy. Schema Migration to proces przekształcania istniejącej bazy danych do nowego schematu bez utraty danych. Room obsługuje migracje przez klasę Migration ze starą i nową wersją. SwiftData używa VersionedSchema do opisywania zmian. Prawidłowa synchronizacja danych między wersjami aplikacji wymaga, aby migracje były testowane idempotentnie.

Przykład Schema Migration w 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
}

Przykład Conflict Resolution w 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 i SwiftData do przechowywania lokalnego

Room to biblioteka Google do przechowywania lokalnego na Androidzie, zbudowana na SQLite i zapewniająca adnotacje do deklaratywnego opisywania zapytań. SwiftData to framework Apple dla iOS, macOS, watchOS i visionOS, następca Core Data z zwięzłą składnią Swift Macro. Oba narzędzia rozwiązują zadanie pracy z danymi na urządzeniu, ale z różnymi podejściami do organizacji kodu. Pamięć podręczna w aplikacjach mobilnych jest często budowana właśnie na tych technologiach.

Room: DAO, Entities i Type Converters

Room używa adnotacji @Entity dla tabel i @Dao dla zapytań. DAO enkapsuluje wszystkie operacje SQL ze sprawdzaniem w czasie kompilacji — błędy składni SQL są wykrywane przed uruchomieniem. Type Converter konwertuje złożone typy (Date, List) na prymitywy SQLite. Nowoczesna praca z danymi w aplikacjach Android jest budowana wokół Room + Flow, zapewniając reaktywne aktualizacje UI przy zmianach w pamięci podręcznej lub lokalnej bazie danych.

SwiftData: @Model i @Query

SwiftData używa makra @Model do definiowania jednostek i @Query do obserwowania danych. Framework automatycznie śledzi zależności i aktualizuje interfejs przy zmianach. Migracja schematu używa VersionedSchema opisującego wszystkie wersje. Synchronizacja danych między SwiftData a serwerem jest implementowana przez niestandardowy Sync Manager subskrybujący aktualizacje przez @Query.

Przykład modelu w SwiftData

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

Porównanie Room vs SwiftData