Geliştirmede Donmalar — özü, nedenleri ve önleme

Mobil Geliştirmede Donma Nedir

Donma (takılma), mobil uygulamada uygulamanın birkaç saniye veya daha uzun süre giriş olaylarını işlemeyi ve arayüzü güncellemeyi durdurması durumudur. Teknik olarak bu, ana iş parçacığının bloke olduğu ve bir sonraki çalıştırma döngüsü yinelemesini gerçekleştiremediği anlamına gelir.

Donma, Lag ve ANR Arasındaki Fark

Lag, kullanıcının yavaşlama fark ettiği ancak uygulamanın çalışmaya devam ettiği 500 ms'ye kadar olan gecikmedir. Donma 1 saniyeden onlarca saniyeye kadar sürer. Android'de ANR, 5 saniyeden uzun süren ve sistem tarafından tespit edilen özel bir donma durumudur. Her donma ANR'ye yol açmaz, ancak her ANR sistem tarafından belgelenmiş bir donmadır.

Donmaların Sonuçları

Android'te, 5 saniyeden uzun süren donma, uygulamayı kapatmayı öneren bir ANR diyaloğu tetikler. iOS'ta, sistemin bir watchdog'u vardır — uygulama 10–20 saniye boyunca olaylara yanıt vermezse, Watchdog işlemi 0x8badf00d (ate bad food) koduyla sonlandırır. Kullanıcı yalnızca uygulamanın aniden ana ekrana kapanmasını görür.

Android ve iOS'ta Donma Nedenleri

100 ms'den uzun süren ve ana iş parçacığında başlatılan herhangi bir işlem potansiyel olarak donmaya neden olabilir. Blokajların ana kaynaklarına bakalım.

UI İş Parçacığında Senkron G/Ç

Büyük bir dosya okumak, eşzamansızlık olmadan ağ isteği, senkron apply yöntemi ve ardından commit ile SharedPreferences'a veri kaydetmek — tüm bu işlemler ana iş parçacığını bloke eder. Android'te, 10 MB'lık bir dosyayı senkron okumak, flash bellek hızına bağlı olarak 200–500 ms sürebilir. iOS'ta, completionHandler olmadan senkron URLSession yüklemesi, sunucu yanıt süresi boyunca UI'yı bloke eder.

Çok İş Parçacıklı Kodda Deadlock

İki iş parçacığı birbirinin tuttuğu kaynakları beklediğinde deadlock oluşur. Mobil uygulamalarda tipik senaryo, A iş parçacığının Lock1'i kilitleyip Lock2'yi beklemesi, B iş parçacığının ise Lock2'yi kilitleyip Lock1'i beklemesidir. Her iki iş parçacığı da sonsuza kadar donar. Bunlardan biri ana iş parçacığıysa, uygulama tamamen donar.

Sonsuz Döngü veya Özyineleme

Bir mantık hatası — örneğin, çıkış koşulu olmayan while(true) veya temel durumu olmayan özyineleme — ana iş parçacığında sonsuz yürütmeye yol açar. Android bunu 5 saniye sonra ANR ile tespit eder, iOS — sonsuz tekrarlanan çağrı yığınını yakalayan Stackshot ile tespit eder.

• Android — Kapatılmayan Cursor, enqueue() yerine execute() ile senkron istek, UI iş parçacığında FileInputStream.read()
• iOS — performSelectorOnMainThread:withObject:waitUntilDone:YES, NSURLConnection sendSynchronousRequest başlatma, dataWithContentsOfURL ile resim yükleme
• Platformlar arası — Ayrılmış isolate olmadan Flutter compute, senkron React Native NativeModule

Donmalar Nasıl Teşhis Edilir

Donma teşhisi, blokaj anında tüm iş parçacıklarının durumunu yakalayabilen araçlar gerektirir.

Android'de ANR Günlükleri

Her ANR'de, Android sistemi her uygulama iş parçacığının yığın dökümünü içeren bir dosya /data/anr/traces.txt kaydeder. Bu dosyayı analiz etmek ana teşhis yöntemidir: main iş parçacığını bulun ve hangi yöntemde durduğunu görün. Yığın Thread.sleep, InputStream.read veya Lock.lock ile bitiyorsa — neden bulunmuştur.

iOS'ta Stackshot

Xcode, uygulama donduğunda (SIGSTOP sinyali) bir Stackshot — tüm iş parçacığı yığınlarının anlık görüntüsü — alabilir. Şemada “Logging” → “Include Stackshot Logs” seçeneğini etkinleştirin. 0x8badf00d koduyla çökme durumunda, Devices & Simulators'dan crash günlüğünü çıkarın ve sıkışmış yığınla com.apple.main-thread'i bulun.

Xcode'da Main Thread Checker

Main Thread Checker, uygulama çalışırken arka plan iş parçacıklarından UIKit çağrılarını otomatik olarak algılar. Şemada etkinleştirin (Diagnostics → Main Thread Checker). Her uyarı, özellikle bir ağ isteği completionHandler closure'ında meydana gelirse, donmanın potansiyel bir nedenidir.

Android'de StrictMode ile blokaj tespiti örneği:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        StrictMode.setVmPolicy(StrictMode.VmPolicy.Builder()
            .detectLeakedSqlLiteObjects()
            .detectLeakedClosableObjects()
            .penaltyLog()
            .build())
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyDeath()
            .build())
    }
}

UI Blokajlarını Giderme Yöntemleri

Donmaları giderme, potansiyel olarak uzun tüm işlemleri arka plan iş parçacıklarına taşımakla başlar. Her platform için belirli tekniklere bakalım.

Coroutine ile Yapılandırılmış Eşzamanlılık

Kotlin Coroutines viewModelScope.launch(Dispatchers.IO) ile ağ işlemlerinin veya veritabanı okumalarının arka plan iş parçacığında yürütülmesini sağlar. Dispatchers.Main yalnızca UI güncellemeleri için kullanılır. Önemli: tüm suspend işlevleri yapılandırılmış olmalıdır — alt coroutine'ler üst iptal edildiğinde iptal edilir, iş parçacığı sızıntılarını önler.

iOS'ta Zaman Uyumsuz Kuyruklar

Grand Central Dispatch arka plan görevleri için DispatchQueue.global(qos: .userInitiated) ve UI güncellemeleri için DispatchQueue.main.async ile standart desendir. Ana kuyrukta sync()'ten kaçının — bu garantili bir deadlock'tur. MainActor aracılığıyla ana iş parçacığına otomatik dönüşle daha okunabilir zaman uyumsuz kod için async/await (Swift 5.5+) kullanın.

UI İş Parçacığında synchronized'dan Kaçınma

Ana iş parçacığında Kotlin'de synchronized blokları ve Swift'te @synchronized tehlikelidir: başka bir iş parçacığı bu kilidi zaten almışsa, ana iş parçacığı beklerken donar. Kilitler yerine atomik türler (AtomicInteger, Swift'te atomik özellikler) veya sıralı kuyruklar kullanın.

Android'de coroutine ile zaman uyumsuz veri yükleme örneği:

class DataViewModel : ViewModel() {
    private val _data = MutableStateFlow<List<Item>>(emptyList())
    val data: StateFlow<List<Item>> = _data.asStateFlow()

    fun loadData() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = fetchFromNetwork()
            _data.emit(result)
        }
    }
}

Geliştirme Aşamasında Donmaları Önleme

Araçlar, mimari ilkeler ve kod inceleme süreçlerinin bir kombinasyonu, donmaları sistematik olarak önlemeye yardımcı olur.

penaltyDeath ile StrictMode

İş parçacığı politikaları için StrictMode'u penaltyDeath ile yapılandırın — bu, ana iş parçacığında bir ağ çağrısı veya disk G/Ç tespit edildiğinde uygulamanın anında çökmesine neden olur. Geliştirici sorunu görmezden gelemez. Üretim yapılarında, çökme olmadan istatistik toplamak için penaltyLog kullanın.

Debug Şemasında Main Thread Checker

iOS'ta, Debug şemasında Main Thread Checker'ı etkinleştirin ve CI'yi bu seçenekle testleri çalıştıracak şekilde yapılandırın. Bir test, arka plan iş parçacığından bir UIKit çağrısı içeriyorsa — başarısız olmalıdır. TestFlight'a göndermeden önce sorunu belirlemenin tek güvenilir yolu budur.

Çoklu İş Parçacığı Denetimiyle Eş İncelemesi

Kod inceleme sürecine zorunlu bir madde ekleyin: herhangi bir ağ çağrısı, dosya işlemi, veritabanı erişimi veya ağır hesaplamanın arka plan iş parçacığında çalıştığını kontrol edin. Deadlock, statik analizörlerle tespit edilebilir: Facebook'tan Infer ve Xcode'dan Thread Safety Checker, çalışma zamanından önce potansiyel kilitleri bulur.

• Android — StrictMode, Infer, Android Lint Multithread, viewModelScope ile Kotlin Coroutines
• iOS — Main Thread Checker, TSAN (Thread Sanitizer), Xcode Analyze, MainActor ile Swift async/await
• Platformlar arası — Flutter compute isolate, requestAnimationFrame ile React Native interaction manager