Android Vitals Rehberi: Crash, ANR ve Performans Sorunları Nasıl Takip Edilir?
Bir uygulamanın “benim telefonumda çalışıyor” olması üretim kalitesinin garantisi değildir. Farklı cihazlar, Android sürümleri, bağlantı koşulları ve kullanıcı davranışları yeni hataları ortaya çıkarabilir. Bu nedenle Android uygulamasında kaliteyi tek bir son test yerine sürekli bir gözlem ve düzeltme döngüsü olarak düşünmek gerekir.
UygulamaTest Editörlüğü · Yayınlandı: 6 Ekim 2026 · Güncellendi: 6 Ekim 2026
Crash ile ANR arasındaki fark
Crash, uygulamanın beklenmedik biçimde sonlanmasıdır. ANR ise uygulamanın kullanıcı etkileşimlerine yeterli sürede yanıt vermemesiyle ilgilidir. İki sorun da kullanıcı deneyimini ciddi biçimde etkileyebilir, fakat kök nedenleri aynı olmak zorunda değildir.
Bir ekranın ağ isteğini ana iş parçacığında uzun süre beklemesi ANR riskini artırabilir. Buna karşılık null veri, yanlış tip dönüşümü veya beklenmeyen SDK davranışı doğrudan crash üretebilir. Teşhis için stack trace, Android sürümü ve cihaz bilgisi gibi bağlamları birlikte inceleyin.
Yayın öncesinde hangi sinyalleri izlemeli?
Gerçek cihaz testleri, otomatik testler ve Play Console Pre-launch Report birlikte kullanılabilir. Özellikle giriş, kayıt, ödeme, reklam, bildirim, veri kaydetme, veri silme ve bağlantı kesintisi gibi kritik kullanıcı yollarını tekrar tekrar deneyin.
Yeni bir SDK eklediğinizde yalnızca ilgili özelliği değil uygulamanın başlangıç süresini, bellek kullanımını ve genel kararlılığını da kontrol edin.
Android Vitals neden önemlidir?
Google Play’in Android Vitals yaklaşımı, uygulamanın kullanıcı cihazlarındaki teknik sağlığını izlemek için çeşitli kalite sinyallerinden yararlanır. Geliştiriciler burada sorunların cihaz veya Android sürümü gibi bağlamlarını inceleyip önceliklendirme yapabilir.
Bir hatanın yalnızca az sayıda kullanıcıyı etkilediğini görmek onu önemsiz hale getirmez. Kritik bir ödeme veya giriş akışında ortaya çıkan düşük oranlı bir sorun bile iş açısından yüksek öneme sahip olabilir.
Sorun çözme döngüsünü sistematikleştirin
Önce sorunu yeniden üretin. Sonra stack trace ve koşulları belirleyin. Sorunun hangi sürümde başladığını karşılaştırın. Değişikliği mümkün olduğunca küçük bir parçaya indirin, düzeltmeyi test edin ve yeni build ile yeniden ölçün. Bu yaklaşım özellikle Gradle, Firebase veya reklam SDK’ları gibi birden fazla bağımlılığın bulunduğu projelerde çok işe yarar.
Performans için en sık unutulan alanlar
Aşırı büyük görseller, ana thread üzerinde ağır işlemler, gereksiz Firestore sorguları, sınırsız liste okumaları, ekran açılır açılmaz başlatılan çok sayıda ağ çağrısı ve gereksiz tekrar render işlemleri performansı etkileyebilir. Önce ölçün, sonra en etkili darboğaza odaklanın; rastgele optimizasyon yapmak yerine kanıta dayalı ilerleyin.
Resmi kaynaklar
Bu içerik bilgilendirme amacıyla hazırlanmıştır. Google Play, Android ve Firebase gereksinimleri zaman içinde değişebilir. Yayın veya politika kararı vermeden önce ilgili resmi dokümantasyonun güncel sürümünü kontrol edin.