Bu sayfada sorun giderme yardımı ve Crashlytics'i kullanmayla ilgili sık sorulan sorulara yanıtlar bulunmaktadır. Aradığınızı bulamıyorsanız veya daha fazla yardıma ihtiyacınız varsa Firebase destek ekibiyle iletişime geçin.
Genel sorun giderme/SSS
Sorunlar tablosundaki bazı sorunlar için farklı biçimler (ve bazen "varyantlar") görme
Firebase konsolundaki Sorunlar tablonuzda listelenen sorunlar için iki farklı biçim görebilirsiniz. Bazı sorunlarınız içinde "varyantlar"
olarak adlandırılan bir özellik de fark edebilirsiniz. İşte nedeni!
2023'ün başlarında, etkinlikleri gruplandırmak için iyileştirilmiş bir analiz motorunu kullanıma sunduk. Ayrıca, güncellenmiş bir tasarımı ve yeni sorunlar (varyantlar gibi) için bazı gelişmiş özellikleri kullanıma sunduk. Tüm ayrıntılar için en son blog yayınımıza göz atın. Öne çıkan özellikler için aşağıdaki yayınları da okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (kilitlenmeler, önemli olmayanlar ve ANR'ler gibi) analiz eder ve sorunlar adı verilen etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.
Geliştirilmiş analiz motoru, etkinlikleri bu sorunlara göre gruplandırmak için artık yığın izlemedeki kareler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil olmak üzere etkinliğin birçok özelliğini inceler.
Ancak bu etkinlikler grubunda hataya yol açan yığın izlemeler farklı olabilir. Farklı bir yığın izleme (stack trace), farklı bir temel neden anlamına gelebilir.
Bir sorun içindeki bu olası farkı temsil etmek için artık sorunların içinde varyantlar oluşturuyoruz. Her varyant, aynı hata noktasına ve benzer yığın izlemeye sahip bir sorundaki etkinliklerin alt grubudur. Varyantları kullanarak, bir sorundaki en yaygın yığın izlemelerde hata ayıklayabilir ve hataya farklı temel nedenlerin yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle elde edeceğiniz sonuçlar aşağıda belirtilmiştir:
Sorun satırında gösterilen meta veriler yenilendi Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık daha kolay.
Yinelenen sorunların daha az olması Satır numarası değişikliği yeni bir soruna yol açmaz.
Çeşitli temel nedenlere sahip karmaşık sorunlarda daha kolay hata ayıklama Bir sorun içinde en yaygın yığın izlemelerde (stack trace) hata ayıklamak için varyantları kullanın.
Daha anlamlı uyarılar ve sinyaller Yeni bir sorun aslında yeni bir hatayı ifade eder.
Daha güçlü arama Her sorun, istisna türü ve paket adı gibi daha aranabilir meta veriler içerir.
Bu iyileştirmelerin kullanıma sunulma şekli:
Uygulamanızdan yeni etkinlikler aldığımızda, bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol ederiz.
Eşleşme olmazsa etkinliğe otomatik olarak akıllı etkinlik gruplaması algoritmamızı uygular ve yenilenen meta veri tasarımıyla yeni bir sorun oluştururuz.
Bu, etkinlik gruplandırmamızda yaptığımız ilk büyük güncellemedir. Geri bildirimde bulunmak isterseniz veya herhangi bir sorunla karşılaşırsanız lütfen
rapor oluşturarak
bize bildirin.
Kilitlenme sorunu yaşamayan metrikleri ve/veya hız uyarılarını görmeme
Kilitlenme sorunu yaşamayan kullanıcılar ve oturumlar gibi metrikler ve/veya hız uyarıları görmüyorsanız
İçerik haritası günlükleri görünmüyor
İçerik haritası günlüklerini görmüyorsanız uygulamanızın Google Analytics yapılandırmasını kontrol etmenizi öneririz.
Aşağıdaki koşulları karşıladığınızdan emin olun:
Crashlytics kontrol panelinde Android uygulamaları için sembolik olmayan yığın izlemeleri görme
Unity IL2CPP kullanıyor ve sembolik olmayan yığın izlemeler görüyorsanız aşağıdakileri deneyin:
Crashlytics Unity SDK'nın v8.6.1 veya sonraki bir sürümünü kullandığınızdan emin olun.
Sembol dosyanızı oluşturup yüklemek için Firebase CLI crashlytics:symbols:upload komutunu kullanmaya hazır olduğunuzdan ve bu komutu çalıştırdığınızdan emin olun.
Firebase konsolunda simgeselleştirilmiş yığın izlemeleri görmek istediğiniz bir sürüm derlemesi veya derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporları alma sayfasından daha fazla bilgi edinebilirsiniz.
Crashlytics, IL2CPP kullanan uygulamalarla kullanılabilir mi?
Evet, Crashlytics, IL2CPP kullanan uygulamalarınız için sembolik yığın izlemeleri görüntüleyebilir. Bu özellik, Android veya Apple platformlarında yayınlanan uygulamalarda kullanılabilir. Yapmanız gerekenler:
Crashlytics Unity SDK'nın v8.6.0 veya sonraki bir sürümünü kullandığınızdan emin olun.
Platformunuz için gerekli görevleri tamamlayın:
Apple platform uygulamaları için: Özel bir işlem gerekmez. Firebase Unity Editor eklentisi Apple platform uygulamaları için Xcode projenizi otomatik olarak sembol yükleyecek şekilde yapılandırır.
Android uygulamaları için: Simge dosyanızı oluşturmak ve yüklemek için Firebase CLI crashlytics:symbols:upload komutunu kullanmaya hazır olduğunuzdan ve bu komutu çalıştırdığınızdan emin olun.
Firebase konsolunda simgeselleştirilmiş yığın izlemeleri görmek istediğiniz bir sürüm derlemesi veya derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporları alma sayfasından daha fazla bilgi edinebilirsiniz.
Kilitlenme sorunu yaşamayan kullanıcılar nasıl hesaplanır?
Kilitlenme sorunu yaşanmayan kullanım değeri, uygulamanızla etkileşime geçen ancak belirli bir dönemde çökmeyen kullanıcıların yüzdesini temsil eder.
Kilitlenme sorunu yaşamayan kullanıcıların yüzdesini hesaplama formülünü aşağıda bulabilirsiniz. Giriş değerleri Google Analytics tarafından sağlanır.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Bir kilitlenme gerçekleştiğinde Google Analytics bir app_exception etkinlik türü gönderir ve CRASHED_USERS, söz konusu etkinlik türüyle ilişkilendirilmiş kullanıcıların sayısını temsil eder.
ALL_USERS, Crashlytics kontrol panelinin sağ üst tarafındaki açılır menüden seçtiğiniz dönemde uygulamanızla etkileşimde bulunan toplam kullanıcı sayısını temsil eder.
Kilitlenme sorunu yaşamayan kullanıcı yüzdesi bir ortalama değil, zaman içindeki toplama değeridir.
Örneğin, uygulamanızda üç kullanıcı olduğunu düşünün. Bunlara A Kullanıcısı, B Kullanıcısı ve C Kullanıcısı diyoruz. Aşağıdaki tabloda, her gün uygulamanızla etkileşimde bulunan kullanıcılar ve o gün kilitlenme yaşayan kullanıcılar gösterilmektedir:
Pazartesi
Salı
Çarşamba
Uygulamanızla etkileşimde bulunmuş kullanıcılar
A, B, C
A, B, C
A, B
Kilitlenen kullanıcı
C
B
A
Çarşamba günü kilitlenme sorunu yaşamayan kullanıcıların yüzdesi %50'dir (2 kullanıcıdan 1'inde kilitlenme sorunu yaşanmamıştır). İki kullanıcınız Çarşamba günü uygulamanızla etkileşimde bulundu ancak yalnızca bir tanesi (B Kullanıcısı) hiç kilitlenme yaşamadı.
Son 2 gün içinde kilitlenme sorunu yaşamayan kullanıcıların yüzdesi %33, 3'tür (her 3 kullanıcıda 1'inde kilitlenme sorunu yaşanmamıştır). Son iki gün içinde kullanıcılarınızdan üçü uygulamanızla etkileşim kurdu ancak yalnızca bir tanesi (C Kullanıcısı) hiç kilitlenme yaşamadı.
Son 3 gün içinde kilitlenme sorunu yaşamayan kullanıcıların yüzdesi %0'dır (3 kullanıcıda 0'da kilitlenme sorunu yaşanmamıştır). Son üç gün içinde kullanıcılarınızdan üçü uygulamanızla etkileşimde bulundu ancak hiç kilitlenme yaşamadı.
Kilitlenme sorunu yaşamayan kullanıcıların değeri farklı dönemler için karşılaştırılmamalıdır.
Tek bir kullanıcının uygulamanızı kullanma sayısı arttıkça, tek bir kullanıcının kilitlenme yaşama olasılığı da artar. Bu nedenle, kilitlenme sorunu yaşamayan kullanıcıların değeri uzun süre boyunca muhtemelen daha küçük olur.
Kimler bir sorunla ilgili notları görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar hakkında yorum yapmasına olanak tanır.
Proje üyesi bir not yayınladığında, bu not, Google hesabının e-postasıyla etiketlenir. Notu görüntüleme erişimi olan tüm proje üyeleri, notla birlikte bu e-posta adresini görebilir.
Aşağıda notları görüntülemek, yazmak ve silmek için gereken erişim açıklanmaktadır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri mevcut notları görüntüleyebilir, silebilir ve bir sorun hakkında yeni notlar yazabilir.
Kimler bir sorunla ilgili notları görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli sorunlar hakkında yorum yapmasına olanak tanır.
Proje üyesi bir not yayınladığında, bu not, Google hesabının e-postasıyla etiketlenir. Notu görüntüleme erişimi olan tüm proje üyeleri, notla birlikte bu e-posta adresini görebilir.
Aşağıda notları görüntülemek, yazmak ve silmek için gereken erişim açıklanmaktadır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri mevcut notları görüntüleyebilir, silebilir ve bir sorun hakkında yeni notlar yazabilir.
Uygulama aynı zamanda Google Mobile Ads SDK'sını kullanıyor ancak kilitlenme almıyor
Projeniz Google Mobile Ads SDK'sı ile birlikte Crashlytics kullanıyorsa istisna işleyicileri kaydederken kilitlenme raporu verenler müdahale ediyor olabilir. Sorunu düzeltmek için disableSDKCrashReporting yöntemini çağırarak Mobile Ads SDK'sında kilitlenme raporlarını devre dışı bırakın.
BigQuery veri kümem nerede bulunuyor?
Crashlytics'i BigQuery'ye bağladıktan sonra, oluşturduğunuz yeni veri kümeleri Firebase projenizin konumundan bağımsız olarak otomatik olarak ABD'de yerleştirilir.
Geri çekilen sorunlar
Geri çekilen sorun nedir?
Daha önce sorunu kapattığınızda ise Crashlytics, sorunun yeniden oluştuğuna dair yeni bir rapor alıyor.
Crashlytics, geri çekilen bu sorunları otomatik olarak yeniden açar. Böylece bu sorunları uygulamanıza uygun şekilde ele alabilirsiniz.
Aşağıda, Crashlytics'in bir sorunu regresyon olarak nasıl sınıflandırdığını açıklayan bir örnek senaryo verilmiştir:
Crashlytics ilk kez Crash "A" ile ilgili bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili sorunu ("A" sorunu) açar.
Bu hatayı hızlı bir şekilde düzeltir, "A" Sorunu'nu kapatır ve ardından uygulamanızın yeni bir sürümünü yayınlarsınız.
Crashlytics, siz sorunu kapattıktan sonra "A" sorunuyla ilgili bir rapor daha alır.
Rapor, sorunu kapattığınızda bildiği bir uygulama sürümünden geliyorsa (yani sürümde herhangi bir kilitlenme için kilitlenme raporu gönderilmişse) Crashlytics, sorunu regresyon olarak değerlendirmez. Sorun kapalı kalacaktır.
Rapor, sorunu kapattığınızda hiçbir zaman Crashlytics'in bilmediği bir uygulama sürümünden geliyorsa (yani sürümde, herhangi bir kilitlenme için hiçhiç kilitlenme raporu göndermediyse) Crashlytics sorunun geri çekileni kabul eder ve sorunu yeniden açar.
Bir sorun geri çekildiğinde, regresyon algılama uyarısı gönderir ve Crashlytics'in sorunu yeniden açtığını bildirmek için soruna bir regresyon sinyali ekleriz. Bir sorunun, regresyon algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sesi kapatın".
Neden eski uygulama sürümlerinde geri çekilen sorunlar görüyorum?
Rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics, sorunun geri alındığını dikkate alarak sorunu yeniden açar.
Bu durum, şu durumda meydana gelebilir: Bir hatayı düzelttiniz ve uygulamanızın yeni bir sürümünü yayınladınız ancak hata düzeltmesi yapılmadan eski sürümlerini kullanmaya devam eden kullanıcılarınız var. Şans eseri, bu eski sürümlerden biri sorunu kapattığınızda hiç kilitlenme raporu göndermediyse ve bu kullanıcılar hatayla karşılaşmaya başladıysa bu kilitlenme raporları geri çekilen bir sorunu tetikler.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sesi kapatın".
Yakalanamayan istisnaları önemli olarak bildirme
Crashlytics, yakalanmamış istisnaları önemli hatalar olarak bildirebilir (Unity SDK'nın v10.4.0 sürümünden itibaren). Aşağıdaki SSS'ler, bu özelliği kullanmayla ilgili gerekçeyi ve en iyi uygulamaları açıklamaya yardımcı olur.
Bir uygulama neden yakalanmamış istisnaları önemli hata olarak bildirmelidir?
Yakalanmayan istisnaları önemli durumlar olarak bildirdiğinizde, uygulama çalışmaya devam etse bile oyunu oynanamamasına yol açabilecek istisnaları daha gerçekçi bir şekilde görebilirsiniz.
Önemli işlemleri raporlamaya başlarsanız kilitlenme sorunu yaşamayan kullanıcı yüzdesinin (CFU) muhtemelen düşeceğini ancak CFU metriğinin son kullanıcıların uygulamanızdaki deneyimlerini daha iyi temsil edeceğini unutmayın.
Hangi istisnalar önemli
olarak bildirilecek?
Crashlytics'in yakalanmamış bir istisnayı önemli olarak bildirmesi için aşağıdaki iki koşulun her ikisinin de karşılanması gerekir:
Uygulamanız (veya dahil olan bir kitaplık) yakalanmamış bir istisna oluşturuyor. Oluşturulan ancak atanmayan bir istisna yakalanmamış olarak kabul edilmez.
Yakalanmayan istisnaların önemli hatalar olarak raporlanmasını etkinleştirdikten sonra artık birçok yeni önemli hatam var. Bu istisnaları nasıl düzgün bir şekilde ele alabilirim?
Yakalanmamış istisnalarınızın önemli durumlar olarak değerlendirildiği raporları almaya başladığınızda, yakalanmamış bu istisnaları ele almak için yararlanabileceğiniz bazı seçenekler şunlardır:
İstisnalar, beklenmeyen veya istisnai durumları yansıtacak şekilde oluşturulur ve atılır.
Atılan istisnanın yansıttığı sorunların çözülmesi, programın bilinen bir duruma (istisna işleme olarak bilinen) geri döndürülmesini içerir.
En iyi uygulama, program bilinen bir duruma döndürülemediği sürece öngörülen tüm istisnaları yakalayıp ele almaktır.
Hangi istisna türlerinin hangi kod tarafından yakalanıp işleneceğini kontrol etmek için try-catch bloğunda istisna oluşturabilecek kodu sarmalayın.
catch ifadelerindeki koşulların, belirli istisnaları uygun şekilde işlemek için mümkün olduğunca dar olduğundan emin olun.
Unity veya Crashlytics'te istisnaları günlüğe kaydedin
Sorunu ayıklamaya yardımcı olması için Unity veya Crashlytics'te istisnaları kaydetmenin birden fazla yolu vardır.
Crashlytics'i kullanırken en yaygın ve önerilen iki seçenek aşağıda verilmiştir:
1. Seçenek: Unity konsolunda yazdırın ancak geliştirme veya sorun giderme sırasında Crashlytics'e bildirmeyin
İstisna içeriğini Unity konsoluna yazdıran ve istisna tekrar uygulanmayan Debug.Log(exception), Debug.LogWarning(exception) ve Debug.LogError(exception) kullanarak Unity konsoluna yazdırma yapın.
2. Seçenek: Aşağıdaki durumlarda Crashlytics kontrol panelinde birleştirilmiş raporlama için Crashlytics'e yükleyin:
İstisna olarak, sonraki olası bir Crashlytics etkinliğindeki hataları ayıklamak için günlüğe kaydetmeye değerse Crashlytics.Log(exception.ToString()) özelliğini kullanın.
Bir istisnanın yakalanıp ele alınmasına rağmen Crashlytics'e bildirilmesi gerekiyorsa bunu önemli olmayan bir etkinlik olarak günlüğe kaydetmek için Crashlytics.LogException(exception) kullanın.
Ancak önemli bir etkinliği Unity Cloud Teşhis'e manuel olarak bildirmek istiyorsanız Debug.LogException işlevini kullanabilirsiniz. Bu seçenek, istisnayı 1. Seçenek gibi Unity konsoluna yazdırır ancak istisnayı da atar (henüz atılmış veya yakalanmış olup olmadığına bakılmaz). Hatayı yerel olmayan
bir şekilde verir. Bu, etrafındaki Debug.LogException(exception) ve try-catch engellemesi bile yakalanmamış bir istisnaya neden olur.
Bu nedenle, yalnızca aşağıdakilerin tümünü yapmak istiyorsanız Debug.LogException yöntemini çağırın:
İstisnayı Unity konsoluna yazdırmak için.
İstisnayı Crashlytics'e önemli bir etkinlik olarak yüklemek için.
İstisnayı iptal etmek için yakalanmamış istisna olarak değerlendirilmesini ve Unity Cloud Teşhis'e bildirilmesini sağlayın.
Yakalanan bir istisnayı Unity konsoluna yazdırmak ve Crashlytics'e önemli olmayan bir etkinlik olarak yüklemek istiyorsanız aşağıdaki işlemi uygulayın:
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}
