Bu sayfada sorun giderme yardımı ve Crashlytics'in kullanımıyla ilgili sık sorulan soruların yanıtları sağlanmaktadır. Aradığınızı bulamıyorsanız veya ek yardıma ihtiyacınız varsa Firebase desteğiyle iletişime geçin.
Genel sorun giderme/SSS
Firebase konsolundaki Sorunlar tablonuzda listelenen sorunlar için iki farklı biçim fark edebilirsiniz. Ayrıca bazı sorunlarınızda "varyantlar" adı verilen bir özelliği de fark edebilirsiniz. İşte nedeni!
2023'ün başlarında, etkinlikleri gruplamak için iyileştirilmiş bir analiz motorunun yanı sıra güncellenmiş bir tasarım ve yeni sorunlar için bazı gelişmiş özellikleri (varyantlar gibi!) kullanıma sunduk. Tüm ayrıntılar için son blog gönderimize göz atın, ancak öne çıkanları aşağıda okuyabilirsiniz.
Crashlytics, uygulamanızdaki tüm etkinlikleri (çökmeler, ölümcül olmayanlar ve ANR'ler gibi) analiz eder ve sorun adı verilen etkinlik grupları oluşturur; bir sorundaki tüm olayların ortak bir başarısızlık noktası vardır.
Olayları bu sorunlar halinde gruplandırmak için, gelişmiş analiz motoru artık yığın izlemedeki çerçeveler, istisna mesajı, hata kodu ve diğer platform veya hata türü özellikleri dahil olmak üzere olayın birçok yönüne bakıyor.
Ancak bu olay grubu içinde hataya yol açan yığın izleri farklı olabilir. Farklı bir yığın izleme, farklı bir temel neden anlamına gelebilir. Bir sorun içindeki bu olası farklılığı temsil etmek için artık sorunlar içinde değişkenler oluşturuyoruz; her değişken, aynı hata noktasına ve benzer yığın izine sahip bir sorundaki olayların bir alt grubudur. Varyantlarla, bir sorun içindeki en yaygın yığın izlerinde hata ayıklayabilir ve hataya farklı temel nedenlerin yol açıp açmadığını belirleyebilirsiniz.
Bu iyileştirmelerle karşılaşacağınız deneyimler şunlardır:
Sorun satırında görüntülenen yenilenen meta veriler
Artık uygulamanızdaki sorunları anlamak ve önceliklendirmek daha kolay.Daha az yinelenen sorun
Satır numarası değişikliği yeni bir sayıya yol açmaz.Çeşitli kök nedenlere sahip karmaşık sorunların daha kolay hata ayıklanması
Bir sorundaki en yaygın yığın izlerinde hata ayıklamak için değişkenleri kullanın.Daha anlamlı uyarılar ve sinyaller
Yeni bir sorun aslında yeni bir hatayı temsil eder.Daha güçlü arama
Her sayı, istisna türü ve paket adı gibi daha fazla aranabilir meta veri içerir.
Bu iyileştirmelerin nasıl sunulduğu aşağıda açıklanmıştır:
Uygulamanızdan yeni etkinlikler aldığımızda bunların mevcut bir sorunla eşleşip eşleşmediğini kontrol edeceğiz.
Eşleşme olmazsa, daha akıllı olay gruplandırma algoritmamızı etkinliğe otomatik olarak uygulayacağız ve yenilenen meta veri tasarımıyla yeni bir sorun yaratacağız.
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 bir rapor göndererek bize bildirin.
Kilitlenme yaşanmayan ölçümleri (kilitlenme yaşanmayan kullanıcılar ve oturumlar gibi) ve/veya hız uyarılarını göremiyorsanızCrashlytics SDK 11.7.0+.
İçerik haritası günlüklerini göremiyorsanız uygulamanızın Google Analytics yapılandırmasını kontrol etmenizi öneririz. Aşağıdaki gereksinimleri karşıladığınızdan emin olun:
Firebase projenizde Google Analytics'i etkinleştirdiniz .
Google Analytics için Veri paylaşımını etkinleştirdiniz. Analytics veri paylaşımı ayarlarınızı yönetme bölümünde bu ayar hakkında daha fazla bilgi edinin
Google Analytics için Firebase SDK'sını eklediuygulamanıza. Bu SDK, Crashlytics SDK'ya ek olarak eklenmelidir.
Uygulamanızda kullandığınız tüm ürünler içinen son Firebase SDK sürümlerinikullanıyorsunuz.
Unity IL2CPP kullanıyorsanız ve sembolik olmayan yığın izleri görüyorsanız aşağıdakileri deneyin:
Crashlytics Unity SDK'nın v8.6.1 veya üstünü kullandığınızdan emin olun.
Sembol dosyanızı oluşturmak ve yüklemek için Firebase CLI
crashlytics:symbols:uploadkomutunu kurduğunuzdan ve çalıştırdığınızdan emin olun.Bir yayın yapısı oluşturduğunuzda veya Firebase konsolunda sembolik yığın izlerini görmek istediğiniz herhangi bir yapı oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporlarını alın sayfasında daha fazla bilgi edinin.
Evet, Crashlytics, IL2CPP kullanan uygulamalarınız için sembolik yığın izlerini görüntüleyebilir. Bu özellik, Android veya Apple platformlarında yayınlanan uygulamalar için kullanılabilir. İşte yapmanız gerekenler:
Crashlytics Unity SDK'nın v8.6.0 veya üstünü kullandığınızdan emin olun.
Platformunuz için gerekli görevleri tamamlayın:
Apple platformu uygulamaları için : Özel bir işlem yapılmasına gerek yoktur. Apple platformu uygulamaları için 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 için Firebase CLI
crashlytics:symbols:uploadkomutunu kurduğunuzdan ve çalıştırdığınızdan emin olun.Bir yayın yapısı oluşturduğunuzda veya Firebase konsolunda sembolik yığın izlerini görmek istediğiniz herhangi bir yapı oluşturduğunuzda bu CLI komutunu çalıştırmanız gerekir. Okunabilir kilitlenme raporlarını alın sayfasında daha fazla bilgi edinin.
Kilitlenmeme değeri, uygulamanızla etkileşime giren ancak belirli bir süre boyunca kilitlenme yaşamayan kullanıcıların yüzdesini temsil eder.
İşte kilitlenme yaşanmayan kullanıcı yüzdesini hesaplamak için kullanılan formül. Giriş değerleri Google Analytics tarafından sağlanır.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Bir kilitlenme meydana geldiğinde, Google Analytics bir
app_exceptionetkinlik 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öşesindeki açılır menüden seçtiğiniz dönem boyunca uygulamanızla etkileşime geçen toplam kullanıcı sayısını temsil eder.
Kilitlenme yaşamayan kullanıcı yüzdesi, ortalama değil, zaman içinde elde edilen bir toplamdır .
Örneğin, uygulamanızın üç kullanıcısı olduğunu düşünün; bunlara A Kullanıcısı, B Kullanıcısı ve C Kullanıcısı adını vereceğiz. Aşağıdaki tablo, her gün hangi kullanıcıların uygulamanızla etkileşim kurduğunu ve o gün bu kullanıcılardan hangisinin kilitlenme yaşadığını gösterir:
| Pazartesi | Salı | Çarşamba | |
|---|---|---|---|
| Uygulamanızla etkileşim kuran kullanıcılar | A, B, C | A, B, C | A, B |
| Kaza geçiren 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şamadı).
Kullanıcılarınızdan ikisi Çarşamba günü uygulamanızla etkileşime geçti ancak yalnızca birinde (Kullanıcı B) herhangi bir kilitlenme yaşanmadı.Son 2 gün içinde kilitlenme yaşamayan kullanıcı yüzdeniz %33,3 (3 kullanıcıdan 1'i kilitlenme yaşamadı).
Kullanıcılarınızdan üçü son iki gün içinde uygulamanızla etkileşimde bulundu, ancak yalnızca birinde (Kullanıcı C) herhangi bir kilitlenme yaşanmadı.Son 3 gün içinde kilitlenme yaşamayan kullanıcı yüzdeniz %0 (3 kullanıcıdan 0'ı kilitlenme yaşamadı).
Kullanıcılarınızdan üçü son üç gün içinde uygulamanızla etkileşimde bulundu ancak sıfırında herhangi bir kilitlenme yaşanmadı.
Kilitlenme yaşanmayan kullanıcıların değeri farklı zaman dilimlerinde karşılaştırılmamalıdır. Tek bir kullanıcının kilitlenme yaşama olasılığı, uygulamanızı ne kadar çok kullanırsa o kadar artar; dolayısıyla kilitlenme yaşamayan kullanıcıların değeri muhtemelen daha uzun süreler boyunca daha küçük olacaktır.
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli konular hakkında yorum yapmasına olanak tanır.
Bir proje üyesi bir not yayınladığında, bu not kendi Google hesabının e-posta adresiyle etiketlenir. Bu e-posta adresi, notla birlikte, notu görüntüleme erişimi olan tüm proje üyeleri tarafından görülebilir.
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 sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip olan proje üyeleri, bir konuya gönderilen notları görüntüleyebilir ancak notu silemez veya yazamaz.
Bkz. Kilitlenmesiz ölçümleri anlama .
Notlar, proje üyelerinin sorular, durum güncellemeleri vb. ile belirli konular hakkında yorum yapmasına olanak tanır.
Bir proje üyesi bir not yayınladığında, bu not kendi Google hesabının e-posta adresiyle etiketlenir. Bu e-posta adresi, notla birlikte, notu görüntüleme erişimi olan tüm proje üyeleri tarafından görülebilir.
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 sorunla ilgili yeni notlar yazabilir.
Aşağıdaki rollerden herhangi birine sahip olan proje üyeleri, bir konuya gönderilen notları görüntüleyebilir ancak notu silemez veya yazamaz.
Entegrasyonlar
Projeniz Google Mobile Ads SDK'sının yanı sıra Crashlytics kullanıyorsa kilitlenme raporlayıcılarının istisna işleyicileri kaydederken müdahale etmesi muhtemeldir. Sorunu düzeltmek için, Mobile Ads SDK'sındaki kilitlenme raporlamasını disableSDKCrashReporting çağırarak kapatın.
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 bulunur.
Gerileyen sorunlar
Daha önce konuyu kapattığınızda bir sorun geriledi ancak Crashlytics, sorunun yeniden oluştuğuna dair yeni bir rapor alıyor. Crashlytics, bu gerileyen sorunları otomatik olarak yeniden açar; böylece bunları uygulamanıza uygun şekilde giderebilirsiniz.
Crashlytics'in bir sorunu regresyon olarak nasıl kategorize ettiğini açıklayan örnek bir senaryoyu burada bulabilirsiniz:
- Crashlytics ilk kez Crash "A" hakkında bir kilitlenme raporu alıyor. Crashlytics söz konusu kilitlenmeyle ilgili bir sorun açar ("A Sorunu").
- Bu hatayı hızlı bir şekilde düzeltir, "A" Sorununu kapatır ve ardından uygulamanızın yeni bir sürümünü yayınlarsınız.
- Sorunu kapattıktan sonra Crashlytics, "A" Sorunu hakkında başka bir rapor alır.
- Rapor, sorunu kapattığınızda Crashlytics'in bildiği bir uygulama sürümüne aitse (yani sürüm herhangi bir kilitlenme için bir kilitlenme raporu göndermişse), Crashlytics sorunu geriletilmiş olarak değerlendirmez. Konu kapalı kalacaktır.
- Rapor, sorunu kapattığınızda Crashlytics'in bilmediği bir uygulama sürümüne aitse (bu, sürümün herhangi bir kilitlenme için hiçbir zaman kilitlenme raporu göndermediği anlamına gelir), Crashlytics sorunun gerilediğini varsayar ve sorunu yeniden açar. .
Bir sorun gerilediğinde, Crashlytics'in sorunu yeniden açtığını size bildirmek için bir gerileme algılama uyarısı göndeririz ve soruna bir gerileme sinyali ekleriz. Regresyon algoritmamız nedeniyle bir konunun yeniden açılmasını istemiyorsanız, konuyu kapatmak yerine "sessizleştirin".
Bir rapor, sorunu kapattığınızda hiç kilitlenme raporu göndermemiş eski bir uygulama sürümünden geliyorsa Crashlytics sorunun gerilediğini varsayar ve 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 hâlâ eski sürümlerde hata düzeltmesi olmayan kullanıcılarınız var. Şans eseri, sorunu kapattığınızda bu eski sürümlerden biri hiç kilitlenme raporu göndermediyse ve bu kullanıcılar hatayla karşılaşmaya başlarsa, bu kilitlenme raporları gerileyen bir sorunu tetikleyecektir.
Regresyon algoritmamız nedeniyle bir konunun yeniden açılmasını istemiyorsanız, konuyu kapatmak yerine "sessizleştirin".
Yakalanmayan istisnaları ölümcül olarak raporlama
Crashlytics, yakalanmayan istisnaları ölümcül olarak bildirebilir (Unity SDK'nın v10.4.0'ından başlayarak). Aşağıdaki SSS'ler bu özelliği kullanmanın mantığını ve en iyi uygulamaları açıklamaya yardımcı olur.
Yakalanmayan istisnaları ölümcül 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 durumları bildirmeye başlarsanız kilitlenme yaşanmayan kullanıcı (CFU) yüzdenizin muhtemelen azalacağını, ancak CFU metriğinin son kullanıcıların uygulamanızla ilgili deneyimlerini daha iyi temsil edeceğini unutmayın.
Crashlytics'in yakalanmamış bir istisnayı ölümcül olarak raporlaması için aşağıdaki iki koşulun her ikisinin de karşılanması gerekir:
Uygulamanızda başlatma sırasında
ReportUncaughtExceptionsAsFatalözelliğitrueolarak ayarlanmalıdır .Uygulamanız (veya dahil edilen bir kitaplık) yakalanmayan bir istisna atıyor. Oluşturulan ancak atılmayan bir istisna, yakalanmamış olarak kabul edilmez.
Yakalanmamış istisnalarınızın ölümcül olarak raporlarını almaya başladığınızda, bu yakalanmamış istisnaları ele almak için bazı seçenekleri burada bulabilirsiniz:
- Bu yakalanmamış istisnaları nasıl yakalayıp ele alabileceğinizi düşünün.
- Unity hata ayıklama konsoluna ve Crashlytics'e istisnaları günlüğe kaydetmek için farklı seçenekleri göz önünde bulundurun.
Atılan istisnaları yakalayın ve yönetin
Beklenmedik veya istisnai durumları yansıtacak şekilde istisnalar oluşturulur ve atılır. Atılan bir istisnanın yansıttığı sorunların çözümü, programın bilinen bir duruma geri döndürülmesini içerir ( istisna yönetimi olarak bilinen bir süreç).
Program bilinen bir duruma döndürülemediği sürece, öngörülen tüm istisnaları yakalayıp ele almak en iyi uygulamadır.
Hangi tür istisnaların hangi kod tarafından yakalandığını ve işlendiğini kontrol etmek için, istisna oluşturabilecek kodu 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'te istisnaları günlüğe kaydedin
Sorunun hatalarını ayıklamaya yardımcı olmak 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 şunlardır:
Seçenek 1: Unity konsolunda yazdırın ancak geliştirme veya sorun giderme sırasında Crashlytics'e rapor vermeyin
- İstisnanın içeriğini Unity konsoluna yazdıran ve istisnayı yeniden atmayan
Debug.Log(exception),Debug.LogWarning(exception)veDebug.LogError(exception)kullanarak Unity konsoluna yazdırın.
- İstisnanın içeriğini Unity konsoluna yazdıran ve istisnayı yeniden atmayan
2. Seçenek: Aşağıdaki durumlarda Crashlytics kontrol panelinde birleştirilmiş raporlama için Crashlytics'e yükleme yapın:
- Sonraki olası bir Crashlytics olayında hata ayıklamak için günlüğe kaydetmeye değer bir istisna varsa
Crashlytics.Log(exception.ToString())kullanın. - Yakalanıp ele alınmasına rağmen hala Crashlytics'e bir istisna bildirilmesi gerekiyorsa, bunu ölümcül olmayan bir olay olarak günlüğe kaydetmek için
Crashlytics.LogException(exception)kullanın.
- Sonraki olası bir Crashlytics olayında hata ayıklamak için günlüğe kaydetmeye değer bir istisna varsa
Ancak önemli bir olayı Unity Cloud Diagnostics'e manuel olarak bildirmek istiyorsanız Debug.LogException kullanabilirsiniz. Bu seçenek, istisnayı Seçenek 1 gibi Unity konsoluna yazdırır, ancak aynı zamanda istisnayı da atar (henüz atılmış veya yakalanmamış olsun veya olmasın). Hatayı yerel olmayan bir şekilde atar. Bu, try-catch bloklarına sahip çevreleyen bir Debug.LogException(exception) bile yine de yakalanmamış bir istisnayla sonuçlanacağı anlamına gelir.
Bu nedenle, yalnızca aşağıdakilerin tümünü yapmak istiyorsanız Debug.LogException arayın:
- İstisnayı Unity konsoluna yazdırmak için.
- İstisnayı Crashlytics'e ölümcül bir olay olarak yüklemek için.
- İstisnayı atmak için, bunun yakalanmamış bir istisna olarak değerlendirilmesini ve bunun Unity Cloud Diagnostics'e bildirilmesini sağlayın.
Yakalanan bir istisnayı Unity konsoluna yazdırmak ve Crashlytics'e ölümcül olmayan bir olay olarak yüklemek istiyorsanız bunun yerine aşağıdakileri yapı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
//
}