Bir Çökme Raporunu Nasıl Okurum?

Kullanıcı çöken bir uygulamayı size bildirmez. Siler ve bir daha açmaz. Bu yüzden yayın sonrasında elinizdeki en değerli veri çökme raporlarıdır — ve çoğu geliştirici bu raporlara ya hiç bakmaz ya da yanlış sırayla bakar.

Aşağıda, uygulamalarımda yayın sonrası uyguladığım rutini anlatıyorum.

1. Önce raporun okunabilir olduğundan emin olun

Bu, atlandığında geri kalan her şeyi anlamsız kılan adım. Yayın için derlenen uygulama küçültülmüş ve karartılmış oluyor; çökme izleri de öyle geliyor. Elinizde şuna benzer bir şey varsa raporu okuyamazsınız:

at a.b.c.d(Unknown Source:2)
at a.b.e.f(Unknown Source:11)

Bunu çözmek için sembol dosyalarını yüklemek gerekiyor: Android'de mapping dosyası (R8/ProGuard çıktısı), iOS'ta dSYM. İkisi de her sürüm için ayrı üretiliyor ve o sürüme özel.

2. Çökme sayısına değil, etkilenen kullanıcı sayısına bakın

Bu, önceliklendirmedeki en yaygın hata. Panelde "1.240 çökme" yazan bir hata, tek bir kullanıcının döngüye girmiş cihazından geliyor olabilir. "38 çökme" yazan başka bir hata ise 38 ayrı kullanıcıyı etkiliyor olabilir.

Baktığım sıralama şu:

1. Etkilenen kullanıcı sayısı — kaç kişinin canı yandı?
2. Çökmesiz kullanıcı oranı — sürümün genel sağlığı.
3. Yeni mi, eski mi — son sürümle gelen bir çökme her zaman önceliklidir.
4. Nerede oluyor — açılışta çöken bir hata, derinlerdeki bir ekranda çöken hatadan çok daha ağırdır.

Açılışta çökme her şeyin önüne geçer. Kullanıcı uygulamayı hiç kullanamıyor demektir; o sürümün yayınını durdurup düzeltme çıkarmak gerekir.

3. Kümelenmeye bakın: ortak nokta ne?

Bir çökme raporunun yanındaki dağılım tablosu, yığın izinden bazen daha çok şey söyler. Baktığım kırılımlar:

"Sadece belirli bir ülkede" satırı bende özel bir yere sahip — daha önce bir hatanın tamamen cihazın dilinden kaynaklandığını bu şekilde bulmuştum.

4. Yığın izini sondan değil, kendi kodunuzdan okuyun

Yığın izinin en üstü genellikle sistem kütüphanesidir ve size bir şey söylemez. İzde ilk kez sizin paket adınızın geçtiği satırı bulun — hata orada tetiklenmiştir.

Ondan sonra o satıra nasıl gelindiğine bakın. Çökmenin sebebi genelde çöken satır değil, oraya yanlış bir değerin ulaşmasıdır.

5. Tekrar üretemiyorsanız iz bırakın

Bazı çökmeler yerelde bir türlü tekrar üretilemiyor. Bu durumda tahminle kod değiştirmek yerine uygulamaya iz bırakmak daha hızlı sonuç veriyor.

// Kullanıcının hangi adımlardan geçtiğini rapora ekle
Crashlytics.log("Sipariş ekranı açıldı, id=" + siparisId)
Crashlytics.setCustomKey("odeme_yontemi", secilenYontem)

Bir sonraki çökme raporunda bu izler yığın izinin yanında görünüyor ve kullanıcının hangi yoldan geçtiği ortaya çıkıyor. Kişisel veri yazmamaya dikkat etmek gerekiyor — e-posta, ad, konum gibi bilgiler bu izlere girmemeli.

6. Çökmeyen hataları da kaydedin

Uygulamayı çökertmeyen ama işlevi bozan hatalar var: başarısız bir ağ isteği, boş dönen bir veri, sessizce yutulan bir istisna. Bunları da rapora göndermek, kullanıcının neden şikâyet ettiğini anlamayı kolaylaştırıyor.

try {
    veriyiKaydet()
} catch (e: Exception) {
    // Uygulama devam ediyor ama olan biteni bilmek istiyoruz
    Crashlytics.recordException(e)
    kullaniciyaHataGoster()
}

Haftalık rutinim

Yayında uygulamam varken haftada bir kez şunlara bakıyorum:

• Çökmesiz kullanıcı oranı geçen haftaya göre düştü mü?
• Son sürümle gelen yeni bir çökme var mı?
• En çok kullanıcıyı etkileyen ilk üç hata ne?
• Mağaza yorumlarında bir çökmeden bahsedilmiş mi?

Bu, yarım saat süren bir iş. Ama atlanınca kullanıcı kaybı sessizce ilerliyor ve indirmelerin neden düştüğünü aylar sonra anlıyorsunuz.

Çökme raporu, kullanıcının size yazmadığı şikâyet mektubudur. Okumadığınız sürece gönderilmiş sayılmaz.

• Crashlytics
• Çökme analizi
• Hata ayıklama
• Yayın sonrası
• Kalite