Mobil geliştirmede önbellek ve veri senkronizasyonu: nedir, hangi stratejiler ve nasıl çalışır

Mobil Uygulamalarda Veri İşleme: Repository Deseni ve Data Source

Repository deseni, tek bir depo sınıfının tüm veri işlemlerini yönettiği, uzak REST API'lerini ve yerel depolama Room veya SwiftData'yı soyutladığı mimari bir yaklaşımdır. Veri işlemenin bu yolu, uygulamanın önce Memory Cache veya Disk Cache'ten bilgi almasını, ardından ağdan almasını sağlayarak yanıt süresini kısaltır. Mobil geliştirmede, Repository, Google ve Apple'ın önerileri sayesinde fiili standart haline gelmiştir.

Remote Data Source ve Local Data Source

Remote Data Source, HTTP istekleri aracılığıyla sunucudan güncel bilgi sağlar. Local Data Source, Android'de Room veya iOS'ta SwiftData aracılığıyla uygulanan cihazdaki yerel depolamadır. Depo, her iki kaynağı birleştirir: önce yerel önbelleği kontrol eder ve veri olmadığında uzak API'den istek yapar. Veri işlemenin bu organizasyonu, uygulamanın çevrimdışı modda çalışmasına izin verir ve sunucu yükünü azaltır.

Kotlin'de Repository Örneği

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

Swift'te Repository Örneği

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

Veri Önbelleğe Alma: LRU Cache, Disk Cache ve Memory Cache

LRU Cache (Least Recently Used), sınıra ulaşıldığında en uzun süredir erişilmeyen öğenin kaldırıldığı bir önbellek algoritmasıdır. Mobil uygulamalarda, LRU Cache görseller, API yanıtları ve serileştirilmiş nesneler için kullanılır. Doğru veri önbelleğe alma, ağ isteklerinin sayısını azaltır ve içerik yüklemeyi hızlandırır. Mobil uygulamalarda önbellek, yüksek performans için gerekli bir bileşendir.

Memory Cache ve Disk Cache

Memory Cache verileri RAM'de depolar — erişim son derece hızlıdır, ancak kapasite uygulamanın yığın boyutuyla sınırlıdır. Disk Cache bilgileri dosya sisteminde saklar — daha yavaştır ancak daha fazla tutabilir ve oturumlar arasında kalıcıdır. Mobil geliştirmede en uygun strateji iki seviyeli önbellektir: sıcak veriler için Memory Cache ve soğuk veriler için Disk Cache. Veri işlenirken, önce bellekteki birinci seviye önbellek, ardından diskteki ikinci seviye önbellek kontrol edilir.

LRU Cache Uygulama Örneği

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

Önbellek Geçersiz Kılma Stratejileri

TTL önbelleği (Time To Live), belirtilen zaman aralığından sonra bir girişi otomatik olarak kaldırır — API verileri için uygundur. Olay tabanlı geçersiz kılma, değişikliklerle ilgili bir push bildirimi alındığında önbelleği temizler. Mobil uygulamalarda, önbellek stratejisi seçimi veri türüne bağlıdır: görseller uzun süre önbelleğe alınırken, haber akışı sık geçersiz kılma gerektirir. Android'de Coil ve iOS'ta Kingfisher, görsellerle çalışmak için LRU Cache'i zaten entegre etmiştir.

Çevrimdışı Kuyruk: Offline Queue ve Sync Manager

Offline Queue, cihaz çevrimdışıyken kullanıcı işlemlerini (oluşturma, güncelleme, silme) yerel veritabanında depolayan bir veri yapısıdır. Bağlantı geri yüklendiğinde, Sync Manager bu işlemleri sırayla sunucuya uygular. Bu tür veri senkronizasyonu, geçici ağ kaybı sırasında hiçbir değişikliğin kaybolmamasını sağlar. Mobil geliştirmede, Offline Queue dengesiz bağlantılara sahip uygulamalar için kritik bir bileşendir.

Offline Queue Mimarisi

Kuyruk, Room veya SwiftData'da bir tablo üzerine inşa edilir ve alanları şunlardır: işlem türü, JSON istek gövdesi, zaman damgası ve durum. Sync Manager, bekleyen işlemleri işleyen, sunucuya gönderen, durumu güncelleyen ve başarılı girişleri kaldıran bir arka plan hizmetidir. Android'de WorkManager veya iOS'ta BGTaskScheduler aracılığıyla veri senkronizasyonu, cihaz yeniden başlatıldıktan sonra bile devam eder. Doğru veri işleme ile Offline Queue kullanımı kesintisiz bir kullanıcı deneyimi sağlar.

Kotlin'de Offline Queue Örneği

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

Yeniden Deneme Politikası ve Zaman Aşımları

Yeniden denemeler arasında üstel geri çekilme (1s, 2s, 4s, 8s), sunucuyu aşırı yüklenmeden korur ve sonsuz yeniden denemeleri önler. 5 deneme sınırı, kuyruk taşmasını önler. Sunucu tarafı idempotans desteği ile mobil uygulamalarda veri senkronizasyonu, yinelenenleri önleyerek güvenli yeniden denemelere izin verir. Bu, özellikle finansal işlemler ve siparişler için önemlidir.

Veri Senkronizasyonu: Conflict Resolution ve Schema Migration

Conflict Resolution, aynı verilerin farklı cihazlarda aynı anda değiştirildiği durumlar için bir strateji kümesidir. Temel veri senkronizasyonu bir yaklaşım seçmeyi gerektirir: Last-Write-Wins (son yazma kazanır), sürüm oluşturma (yüksek sürüm kazanır) veya manuel çözüm. Karmaşık senaryolarda, verilerin matematiksel olarak yakınsamasını garanti eden CRDT (Conflict-Free Replicated Data Types) kullanılır.

Çakışma Çözüm Stratejileri

Last-Write-Wins uygulaması en basitidir ancak kullanıcı değişikliklerini kaybedebilir. Version Vector — her kayıt bir sürüm numarası ve cihaz tanımlayıcısı saklar; sürümler eşleşmediğinde çakışma oluşur. CRDT en güvenilir ancak karmaşık stratejidir: veriler merkezi bir koordinatör olmadan matematiksel olarak tek bir duruma yakınsar. CRDT tabanlı mobil uygulamalarda veri senkronizasyonu, Google Docs'ta işbirlikçi düzenleme ve Notion not senkronizasyonunda kullanılır.

Schema Migration: Güvenli Veritabanı Güncellemesi

Bir uygulama güncellendiğinde, yerel veritabanı yapısı değişir: sütunlar, tablolar, dizinler eklenir. Schema Migration, veri kaybı olmadan mevcut bir veritabanını yeni bir şemaya dönüştürme sürecidir. Room, eski ve yeni sürümlerle Migration sınıfı aracılığıyla geçişleri destekler. SwiftData, değişiklikleri tanımlamak için VersionedSchema kullanır. Uygulama sürümleri arasında doğru veri senkronizasyonu, geçişlerin idempotent olarak test edilmesini gerektirir.

Room'da Schema Migration Örneği

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
}

Swift'te Conflict Resolution Örneği

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

Yerel Depolama için Room ve SwiftData

Room, Android'de yerel depolama için Google kütüphanesidir, SQLite üzerine inşa edilmiştir ve bildirimsel sorgu açıklamaları için ek açıklamalar sağlar. SwiftData, iOS, macOS, watchOS ve visionOS için Apple framework'üdür, özlü Swift Macro sözdizimi ile Core Data'nın halefidir. Her iki araç da cihazda veri işleme görevini çözer, ancak kod organizasyonu için farklı yaklaşımlarla. Mobil uygulamalarda önbellek genellikle bu teknolojiler üzerine inşa edilir.

Room: DAO, Entities ve Type Converters

Room, tablolar için @Entity ek açıklamalarını ve sorgular için @Dao kullanır. DAO, derleme zamanı denetimiyle tüm SQL işlemlerini kapsüller — SQL sözdizimi hataları çalışma zamanından önce tespit edilir. Type Converter, karmaşık türleri (Date, List) SQLite ilkel türlerine dönüştürür. Android uygulamalarında modern veri işleme, önbellek veya yerel veritabanı değiştiğinde reaktif UI güncellemeleri sağlayan Room + Flow etrafında inşa edilir.

SwiftData: @Model ve @Query

SwiftData, varlıkları tanımlamak için makro @Model ve verileri gözlemlemek için @Query kullanır. Framework, bağımlılıkları otomatik olarak izler ve değişikliklerde arayüzü günceller. Şema geçişi, tüm sürümleri tanımlayan VersionedSchema kullanır. SwiftData ve sunucu arasındaki veri senkronizasyonu, @Query aracılığıyla güncellemelere abone olan özel bir Sync Manager ile uygulanır.

SwiftData'da Model Örneği

@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 ve SwiftData Karşılaştırması