Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu sayfada, Crashlytics kullanımıyla ilgili sık sorulan soruların yanıtları ve sorun giderme yardımı sağlanmaktadı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 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. Ayrıca, bazı sorunlarınızda "varyantlar" adlı bir özellik de görebilirsiniz. İşte 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 (ör. varyantlar) için bazı gelişmiş özellikler kullanıma sunduk. Tüm ayrıntılar için son blog yayınımıza göz atın. Önemli noktaları ise aşağıda bulabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (ör. çökmeler, önemli olmayan hatalar ve ANR'ler) analiz eder ve sorun adı verilen etkinlik grupları oluşturur. Bir sorundaki tüm etkinliklerin ortak bir hata noktası vardır.
Etkinlikleri bu sorunlar halinde gruplandırmak için iyileştirilmiş analiz motoru artık etkinliklerin birçok yönünü (yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil) 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ı göstermek için artık sorunlar içinde varyantlar oluşturuyoruz. Her varyant, bir sorundaki aynı hata noktasına ve benzer yığın izlemeye sahip etkinliklerin alt grubudur. Varyantlarla,
bir sorundaki en yaygın yığın izlerinde hata ayıklayabilir ve farklı temel nedenlerin hataya yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle karşılaşacağınız deneyim:
Sorun satırında gösterilen meta veriler yenilendi Uygulamanızdaki sorunları anlamak ve önceliklendirmek artık daha kolay.
Daha az yinelenen sorun Satır numarası değişikliği yeni bir soruna neden olmaz.
Çeşitli temel nedenleri olan karmaşık sorunlarda daha kolay hata ayıklama Bir sorundaki en yaygın yığın izlerinde 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 sorunda, hata türü ve paket adı gibi daha fazla aranabilir meta veri bulunur.
Bu iyileştirmeler şu şekilde kullanıma sunuluyor:
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 etkinliğe otomatik olarak daha akıllı etkinlik gruplandırma algoritmamızı uygularız 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 bildiriminiz varsa veya herhangi bir sorunla karşılaşırsanız lütfen
rapor göndererek
bize bildirin.
İçerik haritası günlüklerini görmüyorsanız
İç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:
Google Analytics için Veri paylaşımı'nı etkinleştirmişsinizdir. Bu ayar hakkında daha fazla bilgi edinmek için Analytics veri paylaşım ayarlarınızı yönetme başlıklı makaleyi inceleyin.
Hız uyarılarını görmüyorsanız aşağıdakileri kullandığınızdan emin olun:
Crashlytics SDK 11.7.0 sürümü veya üzeri.
Kilitlenme içermeyen metrikleri görmeme (veya güvenilir olmayan metrikleri görme)
Kilitlenme sorunu ile karşılaşmayan kullanıcılar ve oturumlar gibi kilitlenme sorunu ile karşılaşmayan kullanıcılar ve oturumlar gibi metrikleri görmüyorsanız veya güvenilir olmayan metrikler görüyorsanız aşağıdakileri kontrol edin:
Aşağıdaki SDK'ları kullandığınızdan emin olun:
Crashlytics SDK 11.7.0+.
Veri toplama ayarlarınızın, hatasızlık metriklerinizin kalitesini etkilemediğinden emin olun:
Otomatik kilitlenme raporlamayı devre dışı bırakarak etkinleştirme raporlamayı etkinleştirirseniz kilitlenme bilgileri yalnızca veri toplamayı açıkça etkinleştirmiş kullanıcılardan Crashlytics'ye gönderilebilir. Bu nedenle, Crashlytics yalnızca bu kullanıcıların kilitlenme bilgilerine sahip olduğundan (tüm kullanıcılarınızın bilgilerine değil) kilitlenmesiz metriklerin doğruluğu etkilenir. Bu durumda, kilitlenme içermeyen metrikleriniz daha az güvenilir olabilir ve uygulamanızın genel kararlılığını daha az yansıtabilir.
Otomatik veri toplamayı devre dışı bıraktıysanız cihazda önbelleğe alınan raporları Crashlytics adresine göndermek için sendUnsentReports kullanabilirsiniz.
Bu yöntemi kullanmak kilitlenme verilerini Crashlytics'e gönderir ancak oturum verilerini göndermez. Bu durum, konsol grafiklerinin kilitlenmesiz metrikler için düşük veya sıfır değerler göstermesine neden olur.
Kilitlenme sorunu yaşamayan kullanıcılar nasıl hesaplanır?
Bu CLI komutunu, yayın derlemesi veya Firebase konsolunda sembolleştirilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma sayfasını inceleyin.
Crashlytics, IL2CPP kullanan uygulamalarla kullanılabilir mi?
Evet, Crashlytics, IL2CPP kullanan uygulamalarınız için sembolleştirilmiş yığın izlemelerini gösterebilir. Bu özellik, Android veya Apple platformlarında yayınlanan uygulamalarda kullanılabilir. Yapmanız gerekenler:
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 platformu uygulamaları için: Herhangi bir özel işlem yapmanız gerekmez. Apple platformu uygulamalarında Firebase Unity Editor eklentisi, Xcode projenizi sembolleri yükleyecek şekilde otomatik olarak yapılandırır.
Android uygulamaları için: Sembol dosyanızı oluşturmak ve yüklemek üzere Firebase CLI crashlytics:symbols:upload komutunu ayarladığınızdan ve çalıştırdığınızdan emin olun.
Bu CLI komutunu, yayın derlemesi veya Firebase konsolunda sembolleştirilmiş yığın izlemelerini görmek istediğiniz herhangi bir derleme oluşturduğunuzda çalıştırmanız gerekir. Daha fazla bilgi için Okunabilir kilitlenme raporları alma sayfasını inceleyin.
Bir sorundaki notları kimler görüntüleyebilir, yazabilir ve silebilir?
Notlar, proje üyelerinin belirli sorunlarla ilgili sorular, durum güncellemeleri vb. hakkında yorum yapmasına olanak tanır.
Proje üyeleri not yayınladığında, notlar Google Hesaplarının e-posta adresiyle etiketlenir. Bu e-posta adresi, notu görüntüleme erişimi olan tüm proje üyelerine notla birlikte gösterilir.
Notları görüntülemek, yazmak ve silmek için gereken erişim aşağıda açıklanmıştır:
Aşağıdaki rollerden herhangi birine sahip proje üyeleri, mevcut notları görüntüleyip silebilir ve bir sorunla ilgili yeni notlar yazabilir.
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 kilitlenme raporlayıcılar, istisna işleyicileri kaydedilirken çakışıyor olabilir. Sorunu düzeltmek için disableSDKCrashReporting işlevini çağırarak Mobile Ads SDK'sında kilitlenme raporlamayı 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 yer alır.
Geri çekilen sorunlar
Regresyona uğramış sorun nedir?
Daha önce kapattığınız bir sorun, Crashlytics yeni bir rapor aldığında gerileme yaşamış demektir. Bu rapor, sorunun tekrar ortaya çıktığını belirtir.
Crashlytics, bu gerileme sorunlarını otomatik olarak yeniden açar. Böylece, uygulamanıza uygun şekilde bu sorunları giderebilirsiniz.
Crashlytics'nın bir sorunu regresyon olarak nasıl sınıflandırdığını açıklayan örnek bir senaryoyu aşağıda bulabilirsiniz:
Crashlytics, ilk kez "A" kilitlenmesiyle ilgili bir kilitlenme raporu alıyor. Crashlytics, bu kilitlenme için ilgili bir sorun açar (A sorunu).
Bu hatayı hızlıca düzeltir, "A" sorununu kapatır ve 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 Crashlyticsbilgisi dahilinde olan
bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için kilitlenme raporu göndermişse) Crashlytics sorunu gerilemiş olarak değerlendirmez. Destek kaydı kapalı kalır.
Rapor, sorunu kapattığınızda Crashlyticsbilinmeyen bir uygulama sürümünden geliyorsa (yani sürüm, herhangi bir kilitlenme için hiçbir kilitlenme raporu göndermediyse) , Crashlytics sorunun gerilediğini düşünür ve sorunu yeniden açar.
Bir sorun gerilediğinde, gerileme algılama uyarısı göndeririz ve Crashlytics kullanıcısının sorunu yeniden açtığını bildirerek soruna gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize" alın.
Neden eski uygulama sürümlerinde 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 gerilediğini düşünür ve sorunu yeniden açar.
Bu durum şu senaryoda yaşanabilir: Bir hatayı düzelttiniz ve uygulamanızın yeni bir sürümünü yayınladınız ancak uygulamanızın eski sürümlerini kullanan ve hata düzeltmesini içermeyen kullanıcılarınız var. Eski sürümlerden biri, sorunu kapattığınızda hiçbir kilitlenme raporu göndermediyse ve bu sürümü kullananlar hatayla karşılaşmaya başlarsa bu kilitlenme raporları, gerileme sorununun tetiklenmesine neden olur.
Regresyon algoritmamız nedeniyle bir sorunun yeniden açılmasını istemiyorsanız sorunu kapatmak yerine "sessize alın".
Yakalanmamış istisnaları ölümcül hatalar olarak bildirme
Crashlytics, yakalanmamış istisnaları ölümcül 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çeleri ve en iyi uygulamaları açıklamaya yardımcı olur.
Bir uygulama neden yakalanmamış istisnaları ölümcül olarak bildirmelidir?
Yakalanmamış istisnaları ölümcül olarak bildirerek, uygulama çalışmaya devam etse bile hangi istisnaların oyunun oynanamamasına neden olabileceğine dair daha gerçekçi bir gösterge elde edersiniz.
Önemli hataları bildirmeye başlarsanız kilitlenme yaşamayan kullanıcı (CFU) yüzdesinin düşeceğini ancak CFU metriğinin, son kullanıcıların uygulamanızla ilgili deneyimlerini daha iyi yansıtacağını unutmayın.
Crashlytics içinde bildirilen ölümcül hatalar, yalnızca sizin tarafınızdan görülebilir. Böylece uygulamalarınızdaki ve oyunlarınızdaki sorunları keşfedip düzeltebilirsiniz.
Hangi istisnalar önemli hata olarak bildirilir?
Crashlytics'nın yakalanmamış 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ık) yakalanmayan bir istisna oluşturuyor. Oluşturulan ancak oluşturulmayan istisnalar yakalanmamış olarak kabul edilmez.
Yakalanmamış 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 şekilde ele alabilirim?
Yakalanmayan istisnalarınızla ilgili raporları ölümcül hatalar olarak almaya başladığınızda, bu yakalanmayan istisnaları işlemek için kullanabileceğiniz bazı seçenekler şunlardır:
Beklenmedik veya istisnai durumları yansıtmak için istisnalar oluşturulur ve gönderilir.
Atılan bir istisnanın yansıttığı sorunları çözmek için programı bilinen bir duruma döndürmek gerekir (bu işleme istisna işleme adı verilir).
Program bilinen bir duruma döndürülemediği sürece, öngörülen tüm istisnaları yakalamak ve 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 try-catch bloğuna sarın.
catch ifadelerindeki koşulların, belirli istisnaları uygun şekilde ele almak için mümkün olduğunca dar olduğundan emin olun.
Unity veya Crashlytics'de günlük istisnaları
Sorunun hata ayıklamasına yardımcı olmak için Unity veya Crashlytics'da 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'a bildirmeyin.
Debug.Log(exception), Debug.LogWarning(exception) ve Debug.LogError(exception) kullanarak Unity konsoluna yazdırın. Bu yöntemler, istisnanın içeriğini Unity konsoluna yazdırır ve istisnayı yeniden oluşturmaz.
2. seçenek: Aşağıdaki durumlarda Crashlytics kontrol panelinde birleştirilmiş raporlama için Crashlytics'ya yükleyin:
Olası bir sonraki etkinliğin hata ayıklaması için bir istisnanın günlüğe kaydedilmesi gerekiyorsa Crashlytics.Log(exception.ToString()) kullanın.Crashlytics
Yakalanıp işlenmesine rağmen bir istisnanın yine de Crashlytics'e raporlanması gerekiyorsa Crashlytics.LogException(exception) kullanarak bunu ölümcül olmayan bir etkinlik olarak günlüğe kaydedin.
Ancak, ölümcül bir etkinliği Unity Cloud Diagnostics'e manuel olarak bildirmek isterseniz Debug.LogException kullanabilirsiniz. Bu seçenek, 1. seçenekte olduğu gibi istisnayı Unity konsoluna yazdırır ancak istisnayı da oluşturur (henüz oluşturulmuş veya yakalanmış olsun ya da olmasın). Hata yerel olarak değil, başka bir yerde oluşur. Bu, Debug.LogException(exception)
ile try-catch bloklarının bulunduğu bir çevre bile yakalanmamış bir istisnaya neden olur.
Bu nedenle, Debug.LogException işlevini yalnızca aşağıdaki işlemlerin tümünü yapmak istiyorsanız çağırın:
İstisnayı Unity konsoluna yazdırmak için.
Özel durumu Crashlytics'ya önemli bir etkinlik olarak yüklemek için.
İstisnayı oluşturmak için yakalanmamış bir istisna olarak ele alınmasını ve Unity Cloud Diagnostics'e bildirilmesini sağlayın.
Yakalanan bir istisnayı Unity konsoluna yazdırmak veCrashlytics'e ölümcül olmayan bir etkinlik olarak yüklemek istiyorsanız bunun yerine aşağıdakileri yapı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//}