Bu sayfada, sorun giderme yardımı ve Crashlytics kullanımıyla ilgili sık sorulan soruların yanıtları yer almaktadır. Aradığınızı bulamıyorsanız veya daha fazla yardıma ihtiyacınız varsa Firebase Destek Ekibi ile iletişime geçin.
Genel sorun giderme/SSS
Sorunlar tablosunda 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. Ayrıca bazı sorunlarınızda "varyantlar" adlı bir özellik görebilirsiniz. Bunun nedeni:
2023'ün başlarında, etkinlikleri gruplandırmak için geliştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlar için bazı gelişmiş özellikler (varyantlar gibi) kullanıma sunduk. Tüm ayrıntılar için son blog yayınımıza göz atın. Önemli noktaları aşağıda bulabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (ör. kilitlenmeler, ölümcül olmayan hatalar ve ANR'ler) analiz eder ve sorun adlı etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.
İyileştirilmiş analiz motoru, etkinlikleri bu sorunlara göre gruplandırmak için artık yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri gibi etkinliğin birçok yönünü inceliyor.
Ancak bu etkinlik grubunda, hataya yol açan yığın izlemeler farklı olabilir. Farklı bir yığın izleme, farklı bir temel neden anlamına gelebilir.
Bir sorundaki bu olası farkı temsil etmek için artık sorunlarda varyantlar oluşturuyoruz. Her varyant, bir sorundaki aynı hata noktasına ve benzer yığın izlemeye sahip etkinliklerin alt grubudur. Varyantlar sayesinde, bir sorundaki en yaygın yığın izlemelerinden hata ayıklama yapabilir ve farklı temel nedenlerin hataya yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmeler sayesinde şunları deneyimleyebilirsiniz:
Sorun satırında gösterilen meta veriler yenilendi Artık uygulamanızdaki sorunları daha kolay anlayabilir ve önceliklendirebilirsiniz.
Daha az yinelenen sorun Satır numarası değişikliği yeni bir soruna neden olmaz.
Çeşitli kök nedenleri olan karmaşık sorunların daha kolay hata ayıklanması Bir sorundaki en yaygın yığın izlemelerinden hata ayıklamak için varyantları kullanın.
Daha anlamlı uyarılar ve sinyaller Yeni bir sorun aslında yeni bir hatayı temsil eder.
Daha güçlü arama Her sorun, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.
Bu iyileştirmeler şu şekilde kullanıma sunulacaktır:
Uygulamanızdan yeni etkinlikler aldığımızda bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol ederiz.
Eşleşme yoksa daha akıllı etkinlik gruplandırma algoritmamızı etkinliğe otomatik olarak uygular ve yenilenmiş 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 bildiriminiz veya karşılaştığınız bir sorun varsa lütfen
bir bildirim göndererek bize bildirin.
Kilitlenme sorunu ile karşılaşmayan kullanıcı sayısı metriklerini ve/veya hız uyarılarını görememe
Kilitlenmesiz metrik (ör. kilitlenmesiz kullanıcılar ve oturumlar) ve/veya hız uyarıları görmüyorsanız
Crashlytics SDK 11.7.0 veya sonraki bir sürümünü kullandığınızdan emin olun.
İçerik haritası günlüklerini görememe
Breadcrumb 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şılamanız gerekir:
Crashlytics Unity SDK'sının 8.6.1 veya sonraki bir sürümünü kullandığınızdan emin olun.
Simge dosyanızı oluşturup yüklemek için Firebase CLIcrashlytics:symbols:upload komutunu çalıştırmaya hazır olduğunuzdan emin olun.
Her yayın derlemesi veya Firebase konsolunda sembolize edilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma sayfasını inceleyin.
Crashlytics, IL2CPP kullanan uygulamalarda kullanılabilir mi?
Evet, Crashlytics, IL2CPP kullanan uygulamalarınız için sembolize edilmiş yığın izlemeleri gösterebilir. Bu özellik, Android veya Apple platformlarında yayınlanan uygulamalarda kullanılabilir. Yapmanız gerekenler şunlardır:
Crashlytics Unity SDK'sının 8.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: Herhangi bir özel işlem yapmanız gerekmez. Apple platform uygulamaları için Firebase Unity Editor eklentisi, Xcode projenizi sembol yükleyecek şekilde otomatik olarak yapılandırır.
Android uygulamaları için: Simge dosyanızı oluşturmak ve yüklemek üzere Firebase CLI crashlytics:symbols:upload komutunu çalıştırmaya hazır olduğunuzdan emin olun.
Her yayın derlemesi veya Firebase konsolunda sembolize edilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma sayfasını inceleyin.
Kilitlenme sorunu yaşamayan kullanıcı sayısı nasıl hesaplanır?
Kilitlenme sorunu yaşamayan kullanıcıların yüzdesi, uygulamanızla etkileşime geçen ancak belirli bir dönemde kilitlenme yaşamayan kullanıcıların yüzdesini gösterir.
Kilitlenme yaşamayan kullanıcıların yüzdesini hesaplamak için kullanılan formül aşağıda verilmiştir. Giriş değerleri Google Analytics tarafından sağlanır.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Kilitlenme olduğunda Google Analytics bir app_exception etkinlik türü gönderir ve CRASHED_USERS bu etkinlik türüyle ilişkili kullanıcı sayısını temsil eder.
ALL_USERS, Crashlytics kontrol panelinin sağ üst kısmındaki açılır menüden seçtiğiniz dönemde uygulamanızla etkileşime geçen toplam kullanıcı sayısını temsil eder.
Kilitlenme yaşamayan kullanıcıların yüzdesi, ortalama değil zaman içindeki bir toplama işlemidir.
Örneğin, uygulamanızda üç kullanıcı olduğunu varsayalım. Bu kullanıcıları A, B ve C olarak adlandıralım. Aşağıdaki tabloda, her gün uygulamanızla etkileşim kuran kullanıcılar ve bu kullanıcılardan hangilerinin o gün kilitlenme yaşadığı gösterilmektedir:
Pazartesi
Salı
Çarşamba
Uygulamanızla etkileşime geçen kullanıcılar
A, B, C
A, B, C
A, B
Kilitlenme yaşayan kullanıcı
C
B
A
Çarşamba günü, kilitlenme yaşamayan kullanıcı yüzdeniz %50'dir (2 kullanıcıdan 1'i kilitlenme yaşamamıştır). Çarşamba günü kullanıcılarınızdan ikisi uygulamanızla etkileşime geçti, ancak bunlardan yalnızca biri (B kullanıcısı) kilitlenme yaşamadı.
Son 2 gün içinde kilitlenme sorunu yaşamayan kullanıcıların yüzdesi %33, 3'tür (3 kullanıcıdan 1'i kilitlenme sorunu yaşamamıştır). Son iki gün içinde kullanıcılarınızdan üçü uygulamanızla etkileşime geçti ancak bunlardan yalnızca biri (Kullanıcı C) kilitlenme yaşamadı.
Son 3 gün içinde kilitlenme sorunu yaşamayan kullanıcı yüzdeniz %0'dır (3 kullanıcıdan 0'ı kilitlenme sorunu yaşamamıştır). Son üç gün içinde uygulamanızla etkileşime geçen üç kullanıcınız oldu ancak hiçbirinde kilitlenme yaşanmadı.
Kilitlenme sorunu yaşamayan kullanıcıların oranı değeri, farklı dönemlere göre karşılaştırılmamalıdır.
Tek bir kullanıcının uygulamanızı ne kadar çok kullandığına bağlı olarak kilitlenme yaşama olasılığı artar. Bu nedenle, kilitlenme yaşamayan kullanıcı sayısı değeri uzun süreler için daha düşük olabilir.
Bir sorunla ilgili notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin belirli sorunlarla ilgili soru, durum güncellemesi vb. yorumlar yapmasına olanak tanır.
Proje üyeleri tarafından eklenen notlar, ilgili üyenin Google Hesabı e-posta adresiyle etiketlenir. Bu e-posta adresi, notu görüntüleme erişimi olan tüm proje üyelerine notla birlikte gösterilir.
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üleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, bir sorunla ilgili olarak yayınlanan notları görüntüleyebilir ancak notları silebilir veya not yazamaz.
Bir sorunla ilgili notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin belirli sorunlarla ilgili soru, durum güncellemesi vb. yorumlar yapmasına olanak tanır.
Proje üyeleri tarafından eklenen notlar, ilgili üyenin Google Hesabı e-posta adresiyle etiketlenir. Bu e-posta adresi, notu görüntüleme erişimi olan tüm proje üyelerine notla birlikte gösterilir.
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üleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, bir sorunla ilgili olarak yayınlanan notları görüntüleyebilir ancak notları silebilir veya not yazamaz.
Uygulama, Google Mobile Ads SDK'sını da kullanıyor ancak kilitlenmiyor
Projenizde Google Mobile Ads SDK'sının yanı sıra Crashlytics kullanılıyorsa istisna işleyicileri kaydederken kilitlenme raporlayıcılarının müdahale ediyor olması muhtemeldir. Sorunu düzeltmek için disableSDKCrashReporting numaralı telefondan Mobile Ads SDK'sında kilitlenme raporlamayı devre dışı bırakın.
BigQuery veri kümem nerede bulunur?
Crashlytics'yi BigQuery'ye bağladıktan sonra, oluşturduğunuz yeni veri kümeleri Firebase projenizin konumundan bağımsız olarak otomatik olarak ABD'de konumlandırılır.
Geri çekilen sorunlar
Gerileyen sorun nedir?
Daha önce kapattığınız bir sorunla ilgili olarak Crashlytics, sorunun tekrar ortaya çıktığına dair yeni bir rapor alır.
Crashlytics, gerileyen bu sorunları otomatik olarak yeniden açar. Böylece, uygulamanıza uygun şekilde ele alabilirsiniz.
Crashlytics'ün bir sorunu nasıl gerileme olarak sınıflandırdığını açıklayan örnek bir senaryo aşağıda verilmiştir:
Crashlytics, "A" kilitlenmesiyle ilgili ilk kez bir kilitlenme raporu alır. Crashlytics, bu kilitlenmeyle ilgili ilgili sorunu açar ("A" sorunu).
Bu hatayı hızlıca düzeltir, "A" sorununu kapatır ve ardından uygulamanızın yeni bir sürümünü yayınlarsınız.
Crashlytics, sorunu kapattıktan sonra "A" sorunuyla ilgili başka bir rapor alır.
Rapor, sorunu kapattığınızda Crashlytics'nin bildiği bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için kilitlenme raporu göndermişse) Crashlytics, sorunun gerilediği sonucuna varmaz. Sorun kapatılır.
Rapor, sorunu kapattığınızda Crashlytics'in bilmediği bir uygulama sürümünden geliyorsa (yani sürüm, hiçbir kilitlenme için hiçbir kilitlenme raporu göndermediyse) Crashlytics, sorunun geri geldiğini düşünür ve sorunu yeniden açar.
Bir sorun gerilediğinde, Crashlytics'ün sorunu yeniden açtığını size bildirmek için bir gerileme algılama uyarısı gönderir ve soruna bir gerileme sinyali ekleriz. Bir sorunun, gerileme algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize alın".
Eski uygulama sürümlerinde neden gerileme sorunları görüyorum?
Bir rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics sorunun geri geldiğini düşünür ve sorunu yeniden açar.
Bu durum aşağıdaki durumda ortaya çıkabilir: Bir hatayı düzelttiniz ve uygulamanızın yeni sürümünü yayınladınız, ancak uygulamanızın eski sürümlerini kullanan ve bu hatayı düzeltme almayan kullanıcılarınız hâlâ var. 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şlarsa bu kilitlenme raporları, geriye giden bir sorunu tetikler.
Bir sorunun, gerileme algoritmamız nedeniyle yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "devre dışı bırakın".
Yakalanmayan istisnaları kritik olarak bildirme
Crashlytics, yakalanmayan istisnaları önemli olarak bildirebilir (Unity SDK'sının v10.4.0 sürümünden itibaren). Aşağıdaki SSS'ler, bu özelliği kullanmanın nedenini ve en iyi uygulamalarını açıklamaya yardımcı olur.
Bir uygulama neden yakalanmayan istisnaları önemli olarak bildirmelidir?
Yakalanmadıkları için işlenmeyen istisnaları kritik olarak bildirerek, uygulama çalışmaya devam etse bile hangi istisnaların oyunun oynanamaz hale gelmesine neden olabileceğine dair daha gerçekçi bir gösterge elde edersiniz.
Ölümcül kilitlenmeleri bildirmeye başlarsanız kilitlenme yaşamayan kullanıcı (CFU) yüzdenizin muhtemelen düşeceğini ancak CFU metriğinin son kullanıcıların uygulamanızla ilgili deneyimlerini daha iyi yansıtacağını unutmayın.
Hangi istisnalar önemli olarak raporlanır?
Crashlytics'ün yakalanmayan bir istisnayı ölümcül olarak bildirmesi için aşağıdaki iki koşulun da karşılanması gerekir:
Uygulamanız (veya dahil edilen bir kitaplığınız) yakalanmayan bir istisna atıyor. Oluşturulan ancak atılmayan bir istisna, yakalanmamış olarak kabul edilmez.
Yakalanmayan istisnaların önemli olarak raporlanmasını etkinleştirdikten sonra birçok yeni önemli hata aldım. Bu istisnaları nasıl düzgün şekilde ele alırım?
Elde edilmeyen istisnalarınızın kritik olarak raporlandığını fark ettiğinizde, bu istisnaları işleme koymak için aşağıdaki seçeneklerden yararlanabilirsiniz:
İstisnalar, beklenmedik veya istisnai durumları yansıtmak için oluşturulur ve atılır.
Atılan bir istisnayla yansıtılan sorunları çözmek, programı bilinen bir duruma döndürmeyi (istisna işleme olarak bilinen bir işlem) içerir.
Program bilinen bir duruma döndürülemezse öngörülen tüm istisnaları yakalayıp işlemek en iyi uygulamadır.
Hangi tür istisnaların hangi kod tarafından yakalanıp işleneceğini kontrol etmek için istisna oluşturabilecek kodu bir try-catch bloğuna sarın.
Belirli istisnaları uygun şekilde ele almak için catch ifadelerindeki koşulların mümkün olduğunca dar olduğundan emin olun.
Unity veya Crashlytics'da istisnaları günlüğe kaydetme
Sorunu gidermeye yardımcı olmak için Unity veya Crashlytics'te istisnaları kaydetmenin birden fazla yolu vardır.
Crashlytics kullanırken en yaygın ve önerilen iki seçenek şunlardır:
1. seçenek: Geliştirme veya sorun giderme sırasında Unity konsolunda yazdırın ancak Crashlytics'e bildirmeyin
Debug.Log(exception), Debug.LogWarning(exception) ve Debug.LogError(exception) kullanarak Unity konsoluna yazdırın. Bu işlevler, istisnanın içeriğini Unity konsoluna yazdırır ve istisnayı yeniden atmaz.
2. seçenek: Aşağıdaki durumlarda Crashlytics kontrol panelinde birleştirilmiş raporlama için Crashlytics'e yükleyin:
Olası bir sonraki Crashlytics etkinliğinde hata ayıklama için bir istisnanın günlüğe kaydedilmesi gerekiyorsa Crashlytics.Log(exception.ToString()) değerini kullanın.
Bir istisna yakalanıp ele alınmasına rağmen Crashlytics'e bildirilmeye devam etmelidir. Bu durumda, Crashlytics.LogException(exception)'ü kullanarak istisnayı ölümcül olmayan bir etkinlik olarak günlüğe kaydedin.
Ancak Unity Cloud Diagnostics'e kritik bir etkinliği manuel olarak bildirmek istiyorsanız Debug.LogException değerini kullanabilirsiniz. Bu seçenek, 1. seçenek gibi istisnayı Unity konsoluna yazdırır ancak istisnayı da atar (henüz atılmış veya yakalanmış olsun olmasın). Hata yerel olmayan bir yerde atılır. Bu, try-catch blokları içeren bir Debug.LogException(exception) bile yakalanmayan bir istisnayla sonuçlandığı anlamına gelir.
Bu nedenle, yalnızca aşağıdakilerin tümünü yapmak istiyorsanız Debug.LogException işlevini çağırın:
İstisnayı Unity konsoluna yazdırmak için.
İstisnayı Crashlytics'e önemli bir etkinlik olarak yüklemek için.
İstisnayı yakalanmamış istisna olarak işleyin ve Unity Cloud Teşhis'e bildirin.
Tespit edilen bir istisnayı Unity konsoluna yazdırmak veCrashlytics'e ölümcül olmayan bir etkinlik olarak yüklemek istiyorsanız bunun yerine aşağıdakileri yapmanız gerektiğini unutmayın:
try{methodThatThrowsMyCustomExceptionType();}catch(MyCustomExceptionTypeexception){// 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//}
