Geliştirmede donma — nedir, nedenleri ve optimizasyon yöntemleri

Mobil geliştirmede “donma” ne anlama gelir

Donma, kullanıcıların öznel olarak yavaş uygulama performansını tanımlamak için kullandıkları resmi olmayan bir terimdir. Sabit bir gecikme olarak ortaya çıkan lag'ın aksine, donma düzensiz takılmalardan oluşur: uygulama birkaç saniye mükemmel çalışabilir ve ardından aniden 1–3 saniye “düşünebilir”.

Olayın teknik açıklaması

Profilleme perspektifinden bakıldığında, donma, tepe gecikmeleri 100 ms'yi aşan bir dizi atlanmış kare (jank) olarak kendini gösterir. Bir FPS grafiğinde bu, keskin düşüşler olarak görünür: saniyede 60 → 20 → 55 → 10 kare. Düşük FPS'li bir lag'ın aksine, donma belirgin bir değişkenliğe sahiptir.

Kullanıcı algısı

Bir uygulama donduğunda, kullanıcı yavaşlamanın mantığını anlayamaz: ekran pürüzsüz kayabilir ve ardından aniden bir saniyeliğine durabilir. Bu hayal kırıklığına neden olur ve uygulamaya olan güveni azaltır. Google'a göre, kullanıcıların %53'ü yükleme 3 saniyeden uzun sürerse bir siteyi veya uygulamayı terk eder.

Uygulamalarda ani yavaşlamaların nedenleri

Donmanın aralıklı doğası, sorunun sürekli aşırı yükten değil, olay odaklı faktörlerden kaynaklandığını gösterir. Tipik senaryoları inceleyelim.

Nesne ayırma sırasında GC duraklamaları

Android'de, ART çalışma zamanında, çöp toplama tüm uygulama iş parçacıklarını durdurur. Kod çok sayıda geçici nesne oluşturuyorsa — örneğin, her onBindViewHolder çağrısında birleştirme yoluyla yeni bir String oluşturma — GC daha sık çalışır. Bir duraklama, yığın boyutuna ve nesne nesline bağlı olarak 5–50 ms sürebilir. Kullanıcı bunu ani bir “düşünme” olarak algılar.

UI iş parçacığında senkron SQL sorguları

Android'de Room ve iOS'ta Core Data, asenkron sorguları destekler, ancak geliştiriciler basitlik için genellikle getValue() çağrısı yapar veya runBlocking aracılığıyla sorguları çalıştırır. 10.000 satırlık bir tabloda birleştirmeleri olan ağır bir SELECT 200–500 ms sürebilir ve bu süre zarfında UI'yı tamamen bloke eder.

Küçültme olmadan görüntü kod çözme

Bir kamera görüntüsünü (12 MP, 4000x3000 piksel) ölçeklemeden yüklemek, Bitmap kod çözme için 200 ms'ye kadar sürer. Görüntüler asenkron olarak ancak sınırlı bir iş parçacığı havuzu olmadan yükleniyorsa, 5–6 kod çözmenin aynı anda çalıştırılması CPU'yu aşırı yükleyerek göç eden yavaşlamalara neden olabilir.

• Android — döngülerde dize birleştirme, sıcak yollarda nesne oluşturma, inSampleSize olmadan Bitmap
• iOS — çok sayıda nesne içeren autorelease havuzları, ölçeklemesiz imageWithContentsOfFile, senkron URLSession
• Platformlar arası — UI iş parçacığında JSON ayrıştırma, sunucu yanıtı beklerken ana iş parçacığında veri yükleme

Android ve iOS'ta donmalar nasıl teşhis edilir

Aralıklı yavaşlamaları teşhis etmek, sabit lag'ları teşhis etmekten daha zordur çünkü sorun her çalıştırmada tekrarlanmayabilir. Uzun bir süre boyunca istatistik toplanması gerekir.

GC olay kaydı ile Memory Profiler

Android Studio Memory Profiler yalnızca bellek kullanımını değil, aynı zamanda GC olaylarını da gösterir: sıklık, tür (Concurrent, Full), süre. Boşta durumda GC 5 saniyede bir defadan fazla meydana geliyorsa — bu aşırı ayırmanın bir işaretidir. Donma anında bir yığın dökümü almak, hangi nesnelerin belleği işgal ettiğini ortaya çıkarır.

Allocation Tracking ile Xcode Instruments

iOS'ta, nesne oluşturma ve serbest bırakmayı izlemek için Instruments'ta Allocations şablonunu kullanın. Generations'ı etkinleştirin — eylemler arasında yığın anlık görüntüleri almanıza ve bellekte hangi nesnelerin kaldığını görmenize olanak tanır. Serbest bırakılmayan kalıcı nesneler, bellek birikiminin ve sonraki duraklamaların kaynağıdır.

Android'de JankStats API

JankStats, gerçek zamanlı olarak atlanan kare metriklerini toplayan bir Android kitaplığıdır. Her jank'ı geçerli senaryoya (örneğin, “liste kaydırma”, “ekran açma”) bağlayarak hangi belirli eylemin donmayı tetiklediğini anlamayı sağlar.

Android'de donmaları izlemek için JankStats entegrasyonu örneği:

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

Yavaş performansı ortadan kaldırma yöntemleri

Donmayı ortadan kaldırmak, her neden üzerinde hedefe yönelik çalışma gerektirir. Evrensel bir çözüm yoktur — belirli performans profillerinin analizi gerekir.

Paging 3 aracılığıyla sayfalama uygulaması

Bir liste 1000+ öğe içeriyorsa ve tümü aynı anda yükleniyorsa — bu garantili donmadır. Android'de Paging 3 ve iOS'ta NSFetchedResultsController, kullanıcı kaydırdıkça verileri bölümler halinde yükler. Kullanıcı yalnızca ilk 10–20 öğeyi görür; geri kalanı arka planda yüklenir.

SQL sorgularını ve indeksleri optimize etme

Room, Android Studio'daki Denetim Aracı aracılığıyla sorguları profillemeye olanak tanır: yürütme süresi, döndürülen satır sayısı ve sorgu planı görülebilir. WHERE ve ORDER BY sütunlarına indeks eklemek, sorgu süresini 300 ms'den 5 ms'ye düşürebilir. iOS'ta, Instruments'taki Core Data Profiler benzer bir kontrol gerçekleştirir.

Görevleri WorkManager'e aktarma

Arka plan senkronizasyonları, dosya indirmeleri, veri işleme — tüm bunlar WorkManager (Android) veya Background Tasks (iOS) aracılığıyla yürütülmelidir. Senkronizasyon UI iş parçacığında çalışırsa, uygulama yürütme sırasında donacaktır. WorkManager, pil ve ağ durumunun farkında olarak bir arka plan iş parçacığında yürütmeyi garanti eder.

Android'de WorkManager aracılığıyla arka plan senkronizasyonu örneği:

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "Syncing data in background thread")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Geliştirme aşamasında donmayı önleme

Donma, verimli bellek ve iş parçacığı yönetimi ilkelerini izleyerek kodlama aşamasında önlenebilir.

AOT derlemesi için Baseline Profiles

Baseline Profiles, Android'in JIT yerine önceden (AOT) derlediği sınıflar ve yöntemler listesidir. Profil olmadan, her yeni ekran ilk açılışta derlenir ve 100–500 ms gecikmeye neden olur. Ana ekranlar için bir Baseline Profile hazırlayın ve baseline-profile-gradle-plugin aracılığıyla Gradle'da oluşturmayı etkinleştirin.

Sıcak yollarda ayırmaları en aza indirme

Sıcak yol, her karede yürütülen koddur: onBindViewHolder, draw, layoutSubviews. Bu yöntemlerde nesne oluşturmaktan kaçının: nesne havuzları kullanın, birleştirme yerine StringBuilder kullanın, biçimlendirilmiş dizeleri ve biçimlendiricileri önbelleğe alın. Her ekstra ayırma bir sonraki GC'yi yaklaştırır.

CI'da Baseline Profiles aracılığıyla profilleme

CI hattınıza bir liste kaydırma ve ekran açma senaryosuyla Macrobenchmark ekleyin. Bir eşik belirleyin: kare süresinin 99. yüzdelik dilimi 16 ms'yi geçmemelidir. Eşik aşılırsa — optimizasyon yapılana kadar yapı reddedilir.

• Android — Baseline Profiles, Macrobenchmark, JankStats, penaltyDeath ile StrictMode
• iOS — MetricKit, os_signpost, XCTMetric, Debug şemasında Main Thread Checker
• Genel yaklaşım — düzenli profilleme, sıcak yollarda ayırmalara odaklanan kod incelemeleri