Uygulama Çökmesi: Nedir, Kapanma Nedenleri ve Tespit Yöntemleri

Uygulama çökmesi nedir

Çökme — kodun işlemediği istisnai bir durumun neden olduğu programın beklenmedik şekilde sonlanmasıdır. Mobil işletim sistemlerinde çökme, uygulamanın anında kapanmasına yol açar ve “Uygulama durduruldu” ekranını gösterir veya ana ekrana döner.

Çökmeler iki büyük sınıfa ayrılır. İşlenmiş hatalar — try/catch blokları istisnayı yakalar, uygulama çalışmaya devam eder, muhtemelen işlevsellik kaybıyla. İşlenmemiş çökmeler — istisna işletim sistemi seviyesine kadar yükselir ve sistem süreci sonlandırır. İkinci tür özellikle tehlikelidir çünkü kullanıcı verileri kaydedemez.

İki milyon kullanıcısı ve %0.1 çökme oranı olan bir sistem, her sürümde 2.000 kullanıcı kaybeder. Google Play Console (2024)'ye göre, çökme oranı %1.5'in üzerinde olan uygulamalar önerilerden çıkarılır ve organik trafiğin %30'una kadar kaybeder.

Mobil uygulamalarda çökmelerin ana nedenleri

NullPointerException (NPE) — Java/Kotlin'de çökmelerin kralı. Bir null nesne üzerinde metot çağırma girişimi. Kotlin'de null safety sayesinde NPE daha az yaygındır, ancak !! operatörünü kullanırken veya Java koduyla etkileşime girerken hala mümkündür. Google (2024), NPE'nin tüm Android uygulaması çökmelerinin %25'ini oluşturduğunu tahmin etmektedir.

IndexOutOfBoundsException — var olmayan bir dizinle liste öğesine erişim. Yaygın neden: veriler sunucudan beklenmedik bir biçimde gelir ve kullanıcı arayüzü var olmayan bir konumu görüntülemeye çalışır. Çözüm — dizinle erişmeden önce her zaman koleksiyon boyutunu kontrol edin.

ANR (Application Not Responding) — Android'e özgü bir sorun. Kullanıcı arayüzü iş parçacığı 5 saniyeden fazla bloke olur. Ana nedenler: ana iş parçacığındaki ağ istekleri, ağır hesaplamalar, veritabanı senkronizasyonu. Android'de StrictMode, geliştirme sırasında kullanıcı arayüzü iş parçacığı blokajını tespit etmeye yardımcı olur.

OutOfMemoryError (OOM) — uygulama bellek sınırını aştı. 2–4 GB RAM'e sahip mobil cihazlarda, büyük görüntülerle veya sayfalama olmadan sonsuz listelerle çalışırken OOM yaygın bir sorundur. Çözüm — görüntü yükleme için Glide/Coil, önbelleğe alma için LruCache, RecyclerView'de ViewHolder.

Çalışma zamanı istisnaları ve ölümcül hatalar

Çalışma zamanı istisnaları — derleyicinin derleme zamanında kontrol etmediği hatalar. Yalnızca kod belirli bir cihazda belirli verilerle çalıştırıldığında ortaya çıkarlar. Java'da bunlar RuntimeException ve alt sınıflarıdır: NullPointerException, IllegalArgumentException, ArithmeticException.

Ölümcül hatalar (FATAL) — çalışma zamanı değil, sistem arızalarıdır. Signal 11 (SIGSEGV) — yerel kodda bellek segmentasyon ihlali. Signal 6 (SIGABRT) — abort() yoluyla uygulamanın kendisi tarafından tetiklenen anormal sonlandırma. Bu tür çökmeleri teşhis etmek zordur çünkü yığın izi genellikle net bir bağlam göstermez.

iOS'ta ana nedenler NSInvalidArgumentException (bir parametrede beklenmeyen nil) ve EXC_BAD_ACCESS'tir (serbest bırakılmış belleğe erişim). Swift, Objective-C'ye kıyasla çökme sayısını azaltmıştır, ancak ObjC çalışma zamanı ve C kitaplıklarındaki hatalar hala çökmelere yol açar.

Çökme izleme ve günlük toplama

Firebase Crashlytics — mobil uygulamalar için standart. Otomatik olarak yığın izleri toplar, günlükler, kullanıcı kimlikleri ve cihaz meta verileri ekler. Çökmeleri imzaya (hata sınıfı + satır) göre gruplar. Gerçek zamanlı uyarılar — çökme oranı belirlenen bir eşiği aştığında (örneğin, saatte >%0.1) bildirimler.

Sentry — daha esnek yeteneklere sahip bir alternatif. Özel bağlamlar oluşturmaya, ekmek kırıntıları (önceki olaylar) eklemeye, önemsiz hataları hariç tutmak için uygulama içi filtreleme yapılandırmaya olanak tanır. Kotlin ve Swift için Kaynak haritaları, karartılmış adlar yerine kaynak kodunu görmeyi sağlar.

Günlükler için en iyi uygulamalar: tehlikeli bir işlem gerçekleştirmeden önce anahtar meta verileri gönderin — böylece günlük, kullanıcının çökmeden önce ne yaptığını gösterecektir. Özel anahtarlar ekleyin (API sürüm numarası, son ekran, giriş verisi boyutu). Bu, işe yaramaz bir yığın izini eyleme dönüştürülebilir bilgiye dönüştürür.

Örnek: Android'de Crashlytics'i ayarlama

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Çökme önleme stratejileri

İsteğe bağlı bağlama ve null safety — Kotlin'de null yapılabilir türler için `?` kullanın, null'ın güvenli işlenmesi için `let` ve `?:` kullanın. Swift'te — optionals ve guard let kullanın. Modern Kotlin (2024), Contract ek açıklamaları ekledi: `@ContractsDsl`, bir işlevin null döndürmediğini bildirmeye olanak tanır ve derleyici bunu kontrol eder.

Ağda hata işleme — her ağ isteği, zaman aşımı, ayrıştırma hataları ve sunucu arızalarını işlemelidir. Result türüyle Retrofit — hatanın işleneceğini garanti eden mühürlü bir sınıf. İstisnasız stil: try/catch yerine, açık başarı ve hata işleme için mühürlü Result kullanın.

Özellik bayrakları — yeni bir sürüm yayınlamadan sorunlu işlevselliği uzaktan devre dışı bırakın. Bir sunucu tarafı işlemi eski cihazlarda çökmeye neden oluyorsa, bayrak bunu bu grup için devre dışı bırakır. Firebase Remote Config, mağazada yayınlamadan uygulama davranışını değiştirmeye olanak tanır.

Kademeli dağıtım — yeni bir sürümü kullanıcıların %5'ine yayınlayın ve çökme oranını izleyin. Oran hedefin altında kalırsa (genellikle <%0.1), %25'e, ardından %50'ye ve %100'e genişletin. Google Play Console ve App Store Connect, eşik aşıldığında otomatik durdurma için aşamalı dağıtımları destekler.

Hata tespitinde eylem planı

Adım 1: Sınıflandırma — ciddiyeti belirleyin: Kritik (kullanıcıların >%1'inde çökme), Yüksek (%0.1–1%), Orta (<%0.1). Kritik çökmeler için — anında müdahale. Diğerleri için — mevcut sprintte standart hata düzeltme süreci. Google Play Console, çökmeleri etkilenen kullanıcı sayısına göre otomatik olarak sınıflandırır.

Adım 2: Yığın izi analizi — Crashlytics'te günlüğü açın, çökmenin tam konumunu kontrol edin. Özel anahtarları kontrol edin: hangi ekran, hangi veriler, işletim sistemi sürümü. En son dağıtımla ilişkilendirin — genellikle bir çökme, beklenmeyen bir kullanım senaryosunu etkileyen yakın tarihli bir kod değişikliğinden kaynaklanır.

Adım 3: Yeniden üretme — çökmeyi benzer parametrelere sahip bir cihazda veya öykünücüde yeniden üretmeyi deneyin. Başarısız olursanız, çökme günlüğünü desenler açısından kontrol edin: belirli modeller (Samsung A10), Android sürümleri (API < 26), yerel ayarlar. Çözüm — senaryoyu kapsayan koruyucu bir koşul ekleyin.

Adım 4: Düzeltme ve izleme — öncelikli olarak bir acil düzeltme yayınlayın. Yayından sonra, bu tür için çökme oranının sıfıra düştüğünden emin olun. Çökme senaryosunu kapsayan bir regresyon testi yazın. Test olmadan, aynı hata bir sonraki yeniden düzenlemede geri gelebilir.