Устранение неполадок Crashlytics и часто задаваемые вопросы

Чтобы Crashlytics сообщал о неперехваченном исключении как о фатальном, должны быть выполнены оба следующих двух условия:

• Во время инициализации приложения для свойства ReportUncaughtExceptionsAsFatal должно быть установлено значение true .

• Ваше приложение (или включенная библиотека) выдает исключение, которое не перехватывается. Исключение, созданное, но не выброшенное , не считается неперехваченным.

Когда вы начнете получать отчеты о неперехваченных исключениях как о неустранимых, вот несколько вариантов обработки этих неперехваченных исключений:

• Подумайте, как можно начать перехватывать и обрабатывать эти неперехваченные исключения.
• Рассмотрим разные варианты протоколирования исключений в консоли отладки Unity и в Crashlytics .

Перехватывать и обрабатывать возникающие исключения

Исключения создаются и выдаются для отражения неожиданных или исключительных состояний . Решение проблем, вызванных выброшенным исключением, включает в себя возврат программы в известное состояние (процесс, известный как обработка исключений ).

Лучше всего перехватывать и обрабатывать все предусмотренные исключения, за исключением случаев, когда программу невозможно вернуть в известное состояние.

Чтобы контролировать, какие типы исключений перехватываются и обрабатываются каким кодом, оберните код, который может генерировать исключение, в блок try-catch . Убедитесь, что условия в операторах catch максимально узки для правильной обработки конкретных исключений.

Зарегистрируйте исключения в Unity или Crashlytics

Существует несколько способов записи исключений в Unity или Crashlytics , которые помогут устранить проблему.

При использовании Crashlytics вот два наиболее распространенных и рекомендуемых варианта:

• Вариант 1. Печатайте в консоли Unity, но не отправляйте отчеты в Crashlytics во время разработки или устранения неполадок.

  • Выполните печать на консоли Unity, используя Debug.Log(exception) , Debug.LogWarning(exception) и Debug.LogError(exception) которые печатают содержимое исключения на консоли Unity и не выдают повторно исключение.

• Вариант 2. Загрузите в Crashlytics консолидированную отчетность на панели управления Crashlytics в следующих ситуациях:

  • Если исключение стоит зарегистрировать для отладки возможного последующего события Crashlytics , используйте Crashlytics.Log(exception.ToString()) .
  • Если об исключении все же следует сообщить в Crashlytics , несмотря на то, что оно было перехвачено и обработано, используйте Crashlytics.LogException(exception) , чтобы зарегистрировать его как нефатальное событие.

Однако если вы хотите вручную сообщить о фатальном событии в Unity Cloud Diagnostics, вы можете использовать Debug.LogException . Этот параметр выводит исключение на консоль Unity, как вариант 1, но также генерирует исключение (независимо от того, было ли оно уже создано или перехвачено). Он выдает ошибку нелокально. Это означает, что даже окружение Debug.LogException(exception) с блоками try-catch по-прежнему приводит к неперехваченному исключению.

Поэтому вызывайте Debug.LogException тогда и только тогда, когда вы хотите выполнить все следующее:

• Чтобы распечатать исключение в консоли Unity.
• Загрузить исключение в Crashlytics как фатальное событие.
• Чтобы создать исключение, его следует рассматривать как неперехваченное исключение и сообщить о нем в Unity Cloud Diagnostics.

Обратите внимание: если вы хотите распечатать перехваченное исключение в консоли Unity и загрузить его в Crashlytics как нефатальное событие, вместо этого сделайте следующее:

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
    //
}

Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase . И вы также можете заметить функцию под названием «варианты» в некоторых ваших задачах. Вот почему!

В начале 2023 года мы представили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, вариантов!). Подробности читайте в нашем недавнем сообщении в блоге , а основные моменты вы можете прочитать ниже.

Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные ошибки и ошибки ANR) и создает группы событий, называемых проблемами — все события в проблеме имеют общую точку сбоя.

Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь анализирует многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.

Однако в этой группе событий трассировки стека, приводящие к сбою, могут быть разными. Другая трассировка стека может означать другую основную причину. Чтобы представить эту возможную разницу внутри проблемы, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку отказа и аналогичную трассировку стека. С помощью вариантов вы можете отладить наиболее распространенные трассировки стека внутри проблемы и определить, приводят ли к сбою различные основные причины.

Вот что вы получите благодаря этим улучшениям:

• Обновленные метаданные, отображаемые в строке проблемы.
  Теперь стало проще понимать и сортировать проблемы в вашем приложении.

• Меньше повторяющихся проблем
  Изменение номера строки не приводит к возникновению новой проблемы.

• Упрощенная отладка сложных проблем с различными первопричинами.
  Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.

• Более содержательные оповещения и сигналы
  Новая проблема на самом деле представляет собой новую ошибку.

• Более мощный поиск
  Каждая проблема содержит больше метаданных, доступных для поиска, таких как тип исключения и имя пакета.

Вот как эти улучшения реализуются:

• Когда мы получаем новые события из вашего приложения, мы проверяем, соответствуют ли они существующей проблеме.

• Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую проблему с обновленным дизайном метаданных.

Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или возникли какие-либо проблемы, сообщите нам об этом, отправив отчет.

Если вы не видите навигационные журналы , рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что вы соответствуете следующим требованиям:

• Вы включили Google Analytics в своем проекте Firebase.

• Вы включили обмен данными для Google Analytics . Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».

• У тебя естьдобавлен Firebase SDK для Google Analyticsв ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.

• Вы используетепоследние версии Firebase SDKдля всех продуктов, которые вы используете в своем приложении.

Если вы не видите оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK 11.7.0+.

Если вы не видите показателей отсутствия сбоев (например, пользователей и сеансов без сбоев) или видите ненадежные показатели, проверьте следующее:

• Убедитесь, что вы используетеCrashlytics SDK 11.7.0+.

• Убедитесь, что настройки сбора данных не влияют на качество показателей безотказности:

  • Если вы включите возможность создания отчетов о сбоях, отключив автоматические отчеты о сбоях, информация о сбоях может быть отправлена ​​в Crashlytics только от пользователей, которые явно согласились на сбор данных. Таким образом, это повлияет на точность показателей отсутствия сбоев, поскольку Crashlytics собирает информацию о сбоях только от этих согласившихся пользователей (а не от всех ваших пользователей). Это означает, что ваши показатели отсутствия сбоев могут быть менее надежными и менее отражающими общую стабильность вашего приложения.

  • Если у вас отключен автоматический сбор данных, вы можете использовать sendUnsentReports для отправки кэшированных отчетов на устройстве в Crashlytics . При использовании этого метода в Crashlytics будут отправляться данные о сбоях , но не данные сеансов , из-за чего на диаграммах консоли будут отображаться низкие или нулевые значения для показателей без сбоев.

См. раздел Общие сведения о показателях отсутствия сбоев .

Если вы используете Unity IL2CPP и видите не только растерянные трассировки стека, попробуйте следующее:

1. Убедитесь, что вы используете V8.6.1 или выше Crashlytics Unity SDK.

2. Убедитесь, что вы настроили и запускаете CHASTLYTICS CLI Firebase crashlytics:symbols:upload команду для генерации и загрузки файла символов.

   Вам нужно запустить эту команду CLI каждый раз, когда вы создаете сборку выпуска, или любую сборку, для которой вы хотите видеть следы символицированных стеков в консоли Firebase . Узнайте больше на странице Get Readable отчеты о сбоях .

Да, Crashlytics может отображать следы символического стека для ваших приложений, которые используют IL2CPP. Эта возможность доступна для приложений, выпущенных на платформах Android или Apple. Вот что вам нужно сделать:

1. Убедитесь, что вы используете V8.6.0 или выше Crashlytics Unity SDK.

2. Выполните необходимые задачи для вашей платформы:

   • Для приложений Apple Platform : никаких специальных действий не требуется. Для приложений Apple Platform плагин редактора Firebase Unity автоматически настраивает ваш проект XCode для загрузки символов.

   • Для приложений Android : убедитесь, что вы настроили и запускаете Firebase crashlytics:symbols:upload команду для генерации и загрузки файла символов.

     Вам нужно запустить эту команду CLI каждый раз, когда вы создаете сборку выпуска, или любую сборку, для которой вы хотите видеть следы символицированных стеков в консоли Firebase . Узнайте больше на странице Get Readable отчеты о сбоях .

Примечания позволяют участникам проекта комментировать конкретные вопросы с вопросами, обновлениями статуса и т. Д.

Когда участник проекта публикует заметку, она помечена электронной почтой их учетной записи Google. Этот адрес электронной почты видна, наряду с примечанием для всех участников проекта с доступом для просмотра примечания.

Следующее описывает доступ, необходимый для просмотра, записи и удаления примечаний:

• Члены проекта с любой из следующих ролей могут просмотреть и удалять существующие заметки и писать новые заметки по вопросу.

  • Владелец проекта или редактор , администратор Firebase , Quality Admin или Crashlytics Admin

• Члены проекта с любыми из следующих ролей могут просмотреть заметки, опубликованные по вопросу, но они не могут удалить или написать заметку.

  • Зритель проекта, зритель Firebase , качественный просмотр или Crashlytics Viewer

Если ваш проект использует Crashlytics вместе с SDK Google Mobile Ads , вполне вероятно, что репортеры с аварией вмешиваются при регистрации обработчиков исключений. Чтобы решить проблему, отключите отчеты о сбоях в Mobile Ads SDK, позвонив в disableSDKCrashReporting .

После того, как вы связываете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически расположены в Соединенных Штатах, независимо от места вашего проекта Firebase.

Вопрос возникла регрессия, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о том, что проблема повторно зарегистрировалась. Crashlytics автоматически вновь открывает эти регрессивные проблемы, чтобы вы могли решать их как необходимые для вашего приложения.

Вот пример сценария, в котором объясняется, как Crashlytics классифицирует проблему как регрессию:

1. Впервые Crashlytics получает отчет о аварии о Crash "A". Crashlytics открывает соответствующую проблему для этого сбоя (выпуск «a»).
2. Вы быстро исправляете эту ошибку, закрываете проблему «A», а затем выпускаете новую версию вашего приложения.
3. Crashlytics получает еще один отчет о выпуске «A» после того, как вы закрыли проблему.
   • Если отчет взят из версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя), то Crashlytics не рассматривает эту проблему как регрессированную. Проблема останется закрытой.
   • Если отчет взят из версии приложения, о которой Crashlytics не знал о том, когда вы закрыли проблему (это означает, что версия никогда не отправляла никакого отчета о сбое для какого-либо сбоя), то Crashlytics рассматривает вопрос об регрессивности и повторно откроет проблему.

Когда проблема регрессирует, мы посылаем оповещение о обнаружении регрессии и добавляем сигнал регрессии в проблему, чтобы вы знали, что Crashlytics вновь открыла проблему. Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.

Если отчет взят из старой версии приложения, которая вообще никогда не отправляла отчеты о сбоях, когда вы закрыли проблему, то Crashlytics рассматривает проблему, регрессирующая и вновь откроет проблему.

Эта ситуация может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию вашего приложения, но у вас все еще есть пользователи на старых версиях без исправления ошибки. Если случайно одна из этих старых версий никогда не отправляла никаких отчетов о сбоях вообще, когда вы закрыли проблему, и эти пользователи начинают встречаться с ошибкой, то эти отчеты об аварии вызывают регрессивную проблему.

Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.

Сообщая об исключениях от Uncaught как фаталы, вы получаете более реалистичное указание на то, что исключения могут привести к тому, что игра не играет - даже если приложение продолжает работать.

Обратите внимание, что если вы начнете сообщать о смертельных фататах, процент ваших пользователей без сбоев (КОЕ), вероятно, уменьшится, но показатель КОЕ будет более репрезентативным для опыта конечных пользователей с вашим приложением.

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
    //
}

На этой странице предоставлена ​​помощь и ответы на часто заданные вопросы об использовании Crashlytics . Если вы не можете найти то, что ищете, или нужна дополнительная помощь, свяжитесь с поддержкой Firebase .

Общие устранения неполадок/FAQ

Интеграции

Regressed issues

Reporting uncaught exceptions as fatals

Crashlytics can report uncaught exceptions as fatals (starting with v10.4.0 of the Unity SDK). The following FAQs help to explain the rationale and best practices for using this feature.

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
    //
}

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
    //
}