На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics. Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общее устранение неполадок/часто задаваемые вопросы
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase. И вы также можете заметить функцию под названием «варианты» в некоторых ваших задачах. Вот почему!
В начале 2023 года мы представили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, вариантов!). Подробности читайте в нашем недавнем сообщении в блоге , а основные моменты вы можете прочитать ниже.
Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные события и ошибки ANR) и создает группы событий, называемые проблемами — все события в проблеме имеют общую точку сбоя.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь анализирует многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировки стека, приводящие к сбою, могут быть разными. Другая трассировка стека может означать другую основную причину. Чтобы отобразить эту возможную разницу внутри проблемы, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку отказа и аналогичную трассировку стека. С помощью вариантов вы можете отладить наиболее распространенные трассировки стека внутри проблемы и определить, приводят ли к сбою различные основные причины.
Вот что вы получите благодаря этим улучшениям:
Обновленные метаданные, отображаемые в строке проблемы.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Упрощенная отладка сложных проблем с различными первопричинами.
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит больше метаданных, доступных для поиска, таких как тип исключения и имя пакета.
Вот как эти улучшения реализуются:
Когда мы получаем новые события из вашего приложения, мы проверяем, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую проблему с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или возникли какие-либо проблемы, сообщите нам об этом , отправив отчет.
Если вы не видите показатели без сбоев (например, без сбоев пользователей и сеансов) и/или оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK 11.7.0+.
Если вы не видите навигационные журналы , рекомендуем проверить конфигурацию вашего приложения для Google Analytics. Убедитесь, что вы соответствуете следующим требованиям:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили обмен данными для Google Analytics. Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».
Выдобавили Firebase SDK для Google Analytics.в ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.
Вы используетепоследние версии Firebase SDKдля всех продуктов, которые вы используете в своем приложении.
Если вы используете Unity IL2CPP и видите несимволические трассировки стека, попробуйте следующее:
Убедитесь, что вы используете версию 8.6.1 или более позднюю версию Crashlytics Unity SDK.
Убедитесь, что вы настроили и выполнили команду Firebase CLI
crashlytics:symbols:uploadдля создания и загрузки файла символов.Вам необходимо запускать эту команду CLI каждый раз, когда вы создаете сборку выпуска или любую сборку, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase. Узнайте больше на странице «Получить читаемые отчеты о сбоях» .
Да, Crashlytics может отображать символизированные трассировки стека для ваших приложений, использующих IL2CPP. Эта возможность доступна для приложений, выпущенных на платформах Android или Apple. Вот что вам нужно сделать:
Убедитесь, что вы используете версию 8.6.0 или более позднюю версию Crashlytics Unity SDK.
Выполните необходимые задачи для вашей платформы:
Для приложений платформы Apple : никаких специальных действий не требуется. Для приложений платформы Apple плагин Firebase Unity Editor автоматически настраивает ваш проект Xcode для загрузки символов.
Для приложений Android : убедитесь, что вы настроили и выполнили команду Firebase CLI
crashlytics:symbols:uploadдля создания и загрузки файла символов.Вам необходимо запускать эту команду CLI каждый раз, когда вы создаете сборку выпуска или любую сборку, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase. Узнайте больше на странице «Получить читаемые отчеты о сбоях» .
Значение без сбоев представляет собой процент пользователей, которые взаимодействовали с вашим приложением, но не столкнулись с сбоями в течение определенного периода времени.
Вот формула для расчета процента пользователей без сбоев. Его входные значения предоставляются Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Когда происходит сбой, Google Analytics отправляет событие типа
app_exception, а CRASHED_USERS представляет количество пользователей, связанных с этим типом события.ALL_USERS представляет собой общее количество пользователей, которые взаимодействовали с вашим приложением за период времени, который вы выбрали в раскрывающемся меню в правом верхнем углу панели управления Crashlytics.
Процент пользователей без сбоев представляет собой совокупность с течением времени , а не среднее значение.
Например, представьте, что в вашем приложении три пользователя; мы назовем их пользователем A, пользователем B и пользователем C. В следующей таблице показано, какие пользователи взаимодействовали с вашим приложением каждый день и у каких из этих пользователей в тот день произошел сбой:
| Понедельник | Вторник | Среда | |
|---|---|---|---|
| Пользователи, которые взаимодействовали с вашим приложением | А, Б, С | А, Б, С | А, Б |
| Пользователь, у которого произошел сбой | С | Б | А |
В среду ваш процент пользователей без сбоев составил 50 % (у 1 из 2 пользователей не было сбоев).
Двое из ваших пользователей взаимодействовали с вашим приложением в среду, но только у одного из них (пользователь Б) не было сбоев.За последние 2 дня процент ваших пользователей без сбоев составил 33,3% (у 1 из 3 пользователей не было сбоев).
Трое из ваших пользователей взаимодействовали с вашим приложением за последние два дня, но только у одного из них (пользователь C) не было сбоев.За последние 3 дня процент пользователей без сбоев составил 0 % (0 из 3 пользователей не имели сбоев).
Трое из ваших пользователей взаимодействовали с вашим приложением за последние три дня, но ни у одного из них не было сбоев.
Ценность пользователей без сбоев не следует сравнивать за разные периоды времени. Вероятность того, что у одного пользователя произойдет сбой, растет по мере того, как больше раз он использует ваше приложение, поэтому ценность пользователей без сбоев, вероятно, будет меньше в течение более длительных периодов времени.
Примечания позволяют участникам проекта комментировать конкретные проблемы с помощью вопросов, обновлений статуса и т. д.
Когда участник проекта публикует заметку, она помечается адресом электронной почты его учетной записи Google. Этот адрес электронной почты вместе с заметкой виден всем участникам проекта, имеющим доступ для просмотра заметки.
Ниже описан доступ, необходимый для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
См. раздел Общие сведения о показателях отсутствия сбоев .
Примечания позволяют участникам проекта комментировать конкретные проблемы с помощью вопросов, обновлений статуса и т. д.
Когда участник проекта публикует заметку, она помечается адресом электронной почты его учетной записи Google. Этот адрес электронной почты вместе с заметкой виден всем участникам проекта, имеющим доступ для просмотра заметки.
Ниже описан доступ, необходимый для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
Интеграции
Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вполне вероятно, что генераторы отчетов о сбоях мешают регистрировать обработчики исключений. Чтобы устранить эту проблему, отключите отчеты о сбоях в Mobile Ads SDK, вызвав disableSDKCrashReporting .
После того как вы свяжете Crashlytics с BigQuery, новые создаваемые вами наборы данных автоматически располагаются в США, независимо от местоположения вашего проекта Firebase.
Регрессирующие проблемы
Проблема была регрессирована, когда вы ранее закрыли ее, но Crashlytics получает новый отчет о том, что проблема повторилась. Crashlytics автоматически повторно открывает эти регрессировавшие проблемы, чтобы вы могли решить их соответствующим образом для вашего приложения.
Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:
- Впервые Crashlytics получает отчет о сбое Crash «A». Crashlytics открывает соответствующую проблему для этого сбоя (проблема «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получит еще один отчет о проблеме «А» после того, как вы ее закроете.
- Если отчет относится к версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия вообще отправила отчет о сбое при любом сбое), то Crashlytics не будет считать проблему регрессированной. Вопрос останется закрытым.
- Если отчет относится к версии приложения, о которой Crashlytics не знала, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла отчет о сбое для какого- либо сбоя), то Crashlytics считает, что проблема регрессировала, и повторно откроет проблему. .
Когда проблема регрессирует, мы отправляем предупреждение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыла проблему. Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
Если отчет исходит из старой версии приложения, которая вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, Crashlytics считает, что проблема регрессировала, и повторно откроет проблему.
Такая ситуация может возникнуть в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи более старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправила никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начнут сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессирующую проблему.
Если вы не хотите, чтобы проблема открывалась повторно из-за нашего алгоритма регрессии, «приглушите» проблему, а не закрывайте ее.
Отчет о неперехваченных исключениях как о фатальных
Crashlytics может сообщать о неперехваченных исключениях как о фатальных (начиная с версии 10.4.0 Unity SDK). Следующие часто задаваемые вопросы помогут объяснить обоснование и рекомендации по использованию этой функции.
Сообщая о неперехваченных исключениях как о фатальных, вы получаете более реалистичное представление о том, какие исключения могут привести к тому, что в игру невозможно будет играть, даже если приложение продолжает работать.
Обратите внимание: если вы начнете сообщать о сбоях, процент пользователей без сбоев (CFU), скорее всего, уменьшится, но показатель CFU будет более репрезентативным для опыта работы конечных пользователей с вашим приложением.
Чтобы 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 и не выдают повторно исключение.
- Выполните печать на консоли Unity, используя
Вариант 2. Загрузите в Crashlytics консолидированную отчетность на панели управления Crashlytics в следующих ситуациях:
- Если исключение стоит зарегистрировать для отладки возможного последующего события Crashlytics, используйте
Crashlytics.Log(exception.ToString()). - Если об исключении все же следует сообщить в Crashlytics, несмотря на то, что оно было перехвачено и обработано, используйте
Crashlytics.LogException(exception), чтобы зарегистрировать его как нефатальное событие.
- Если исключение стоит зарегистрировать для отладки возможного последующего события Crashlytics, используйте
Однако если вы хотите вручную сообщить о фатальном событии в 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
//
}
На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics. Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общее устранение неполадок/часто задаваемые вопросы
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase. И вы также можете заметить функцию под названием «варианты» в некоторых ваших задачах. Вот почему!
В начале 2023 года мы представили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые расширенные функции для новых проблем (например, вариантов!). Подробности читайте в нашем недавнем сообщении в блоге , а основные моменты вы можете прочитать ниже.
Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные события и ошибки ANR) и создает группы событий, называемые проблемами — все события в проблеме имеют общую точку сбоя.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь анализирует многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировки стека, приводящие к сбою, могут быть разными. Другая трассировка стека может означать другую основную причину. Чтобы представить эту возможную разницу внутри проблемы, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку отказа и аналогичную трассировку стека. С помощью вариантов вы можете отладить наиболее распространенные трассировки стека внутри проблемы и определить, приводят ли к сбою различные основные причины.
Вот что вы получите благодаря этим улучшениям:
Обновленные метаданные, отображаемые в строке проблемы.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Упрощенная отладка сложных проблем с различными первопричинами.
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит больше метаданных, доступных для поиска, таких как тип исключения и имя пакета.
Вот как эти улучшения реализуются:
Когда мы получаем новые события из вашего приложения, мы проверяем, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую проблему с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или возникли какие-либо проблемы, сообщите нам об этом , отправив отчет.
Если вы не видите показатели без сбоев (например, без сбоев пользователей и сеансов) и/или оповещения о скорости, убедитесь, что вы используетеCrashlytics SDK 11.7.0+.
Если вы не видите навигационные журналы , рекомендуем проверить конфигурацию вашего приложения для Google Analytics. Убедитесь, что вы соответствуете следующим требованиям:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили обмен данными для Google Analytics. Подробнее об этом параметре читайте в разделе «Управление настройками общего доступа к данным Google Analytics».
Выдобавили Firebase SDK для Google Analytics.в ваше приложение. Этот SDK необходимо добавить в дополнение к Crashlytics SDK.
Вы используете новейшие версии SDKПоследние версии Firebase SDKдля всех продуктов, которые вы используете в своем приложении.
Если вы используете Unity IL2CPP и видите не только растерянные трассировки стека, попробуйте следующее:
Убедитесь, что вы используете V8.6.1 или выше Crashlytics Unity SDK.
Убедитесь, что вы настроили и запускаете
crashlytics:symbols:uploadкоманду для генерации и загрузки файла символов.Вам нужно запустить эту команду CLI каждый раз, когда вы создаете сборку выпуска, или любую сборку, для которой вы хотите видеть следы символицированных стеков в консоли Firebase. Узнайте больше на странице Get Readable отчеты о сбоях .
Да, Crashlytics может отображать следы символического стека для ваших приложений, которые используют IL2CPP. Эта возможность доступна для приложений, выпущенных на платформах Android или Apple. Вот что вам нужно сделать:
Убедитесь, что вы используете V8.6.0 или выше Crashlytics Unity SDK.
Выполните необходимые задачи для вашей платформы:
Для приложений Apple Platform : никаких специальных действий не требуется. Для приложений Apple Platform плагин редактора Firebase Unity автоматически настраивает ваш проект XCode для загрузки символов.
Для приложений Android : убедитесь, что вы настроили и запускаете
crashlytics:symbols:uploadкоманду для генерации и загрузки файла символов.Вам нужно запустить эту команду CLI каждый раз, когда вы создаете сборку выпуска, или любую сборку, для которой вы хотите видеть следы символицированных стеков в консоли Firebase. Узнайте больше на странице Get Readable отчеты о сбоях .
Значение без сбоев представляет процент пользователей, которые взаимодействовали с вашим приложением, но не имели сбоя в течение определенного периода времени.
Вот формула для расчета процента пользователей без сбоев. Его входные значения предоставляются Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Когда происходит сбой, Google Analytics отправляет тип события
app_exception, а CRASHED_USERS представляет количество пользователей, связанных с этим типом события.ALL_USERS представляет общее количество пользователей, которые занимались вашим приложением в течение периода времени, который вы выбрали из раскрывающегося меню в верхней правой части панели Crashlytics Dashboard.
Процент без сбоев пользователей-это агрегация с течением времени , а не среднее значение.
Например, представьте, что в вашем приложении есть три пользователя; Мы назовем их пользователем A, пользователем B и пользователем C. Следующая таблица показывает, какие пользователи занимаются вашим приложением каждый день, и у кого из этих пользователей был сбой в тот день:
| Понедельник | Вторник | Среда | |
|---|---|---|---|
| Пользователи, которые занимались вашим приложением | А, Б, С | А, Б, С | А, Б |
| Пользователь, у которого был сбой | С | Б | А |
В среду ваш процент без сбоев пользователей составляет 50% (1 из 2 пользователей был без сбоев).
В среду двое из ваших пользователей занимались вашим приложением, но только один из них (пользователь B) не имел сбоев.В течение последних 2 дней ваш процент без сбоев пользователей составляет 33,3% (1 из 3 пользователей был без сбоев).
Три из ваших пользователей, занимающихся вашим приложением за последние два дня, но только один из них (пользователь C) не имел сбоев.В течение последних 3 дней ваш процент без сбоев пользователей составляет 0% (0 из 3 пользователей были без сбоев).
Три из ваших пользователей занимались вашим приложением за последние три дня, но ноль из них не имел сбоев.
Значение пользователей без сбоев не следует сравнивать в течение разных периодов времени. Вероятность того, что один пользователь испытывает аварию, увеличивается больше раз, когда он использует ваше приложение, поэтому ценность пользователей без сбоев, вероятно, будет меньше в течение более длительных периодов времени.
Примечания позволяют участникам проекта комментировать конкретные вопросы с вопросами, обновлениями статуса и т. Д.
Когда участник проекта публикует заметку, она помечена электронной почтой их учетной записи Google. Этот адрес электронной почты видна, наряду с примечанием для всех участников проекта с доступом для просмотра примечания.
Следующее описывает доступ, необходимый для просмотра, записи и удаления примечаний:
Члены проекта с любой из следующих ролей могут просмотреть и удалять существующие заметки и писать новые заметки по вопросу.
Члены проекта с любыми из следующих ролей могут просмотреть заметки, опубликованные по вопросу, но они не могут удалить или написать заметку.
- Зритель проекта, зритель Firebase , качественный просмотр или Crashlytics Viewer
См. Понятно, без сбоев метрик .
Примечания позволяют участникам проекта комментировать конкретные вопросы с вопросами, обновлениями статуса и т. Д.
Когда участник проекта публикует заметку, она помечена электронной почтой их учетной записи Google. Этот адрес электронной почты видна, наряду с примечанием для всех участников проекта с доступом для просмотра примечания.
Следующее описывает доступ, необходимый для просмотра, записи и удаления примечаний:
Члены проекта с любой из следующих ролей могут просмотреть и удалять существующие заметки и писать новые заметки по вопросу.
Члены проекта с любыми из следующих ролей могут просмотреть заметки, опубликованные по вопросу, но они не могут удалить или написать заметку.
- Зритель проекта, зритель Firebase , качественный просмотр или Crashlytics Viewer
Интеграции
Если ваш проект использует Crashlytics вместе с SDK Google Mobile Ads, вполне вероятно, что репортеры с аварией вмешиваются при регистрации обработчиков исключений. Чтобы решить проблему, отключите отчеты о сбоях в мобильной рекламе SDK, позвонив в disableSDKCrashReporting .
После того, как вы связываете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически расположены в Соединенных Штатах, независимо от места вашего проекта Firebase.
Регрессивные проблемы
Вопрос возникла регрессия, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о том, что проблема повторно зарегистрировалась. Crashlytics автоматически вновь открывает эти регрессивные проблемы, чтобы вы могли решать их как необходимые для вашего приложения.
Вот пример сценария, в котором объясняется, как Crashlytics классифицирует проблему как регрессию:
- Впервые Crashlytics получает отчет о аварии о Crash "A". Crashlytics открывает соответствующую проблему для этого сбоя (выпуск «a»).
- Вы быстро исправляете эту ошибку, закрываете проблему «A», а затем выпускаете новую версию вашего приложения.
- Crashlytics получает еще один отчет о выпуске «A» после того, как вы закрыли проблему.
- Если отчет взят из версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя), то Crashlytics не рассматривает эту проблему как регрессированную. Проблема останется закрытой.
- Если отчет взят из версии приложения, о которой Crashlytics не знал о том, когда вы закрыли проблему (это означает, что версия никогда не отправляла никакого отчета о сбое для какого-либо сбоя), то Crashlytics рассматривает вопрос об регрессивности и повторно откроет проблему .
Когда проблема регрессирует, мы посылаем оповещение о обнаружении регрессии и добавляем сигнал регрессии в проблему, чтобы вы знали, что Crashlytics вновь открыла проблему. Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.
Если отчет взят из старой версии приложения, которая вообще никогда не отправляла отчеты о сбоях, когда вы закрыли проблему, то Crashlytics рассматривает проблему, регрессирующая и вновь откроет проблему.
Эта ситуация может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию вашего приложения, но у вас все еще есть пользователи на старых версиях без исправления ошибки. Если случайно одна из этих старых версий никогда не отправляла никаких отчетов о сбоях вообще, когда вы закрыли проблему, и эти пользователи начинают встречаться с ошибкой, то эти отчеты об аварии вызывают регрессивную проблему.
Если вы не хотите, чтобы проблема была вновь открыта из-за нашего алгоритма регрессии, «отключить» проблему вместо того, чтобы закрыть ее.
Сообщение о непредучанных исключениях как смертельные фататы
Crashlytics может сообщать о неотложных исключениях как фаталов (начиная с V10.4.0 Unity SDK). Следующие часто задаваемые вопросы помогают объяснить обоснование и лучшие практики для использования этой функции.
Сообщая об исключениях от Uncaught как фаталы, вы получаете более реалистичное указание на то, что исключения могут привести к тому, что игра не играет - даже если приложение продолжает работать.
Обратите внимание, что если вы начнете сообщать о смертельных фататах, процент ваших пользователей без сбоев (КОЕ), вероятно, уменьшится, но показатель КОЕ будет более репрезентативным для опыта конечных пользователей с вашим приложением.
Для того, чтобы Crashlytics сообщил о необработанном исключении как смертельное, оба из следующих двух условий должны быть выполнены:
Во время инициализации в вашем приложении
ReportUncaughtExceptionsAsFataltrueВаше приложение (или включенная библиотека) бросает исключение, которое не поймано. Исключение, которое создано, но не брошено , не считается непредуденным.
Когда вы начнете получать отчеты о ваших не учитывающихся исключениях в качестве фаталов, вот несколько вариантов обработки этих нехваченных исключений:
- Подумайте о том, как вы можете начать ловить и обрабатывать эти необратимые исключения.
- Рассмотрим различные варианты для регистрации исключений из консоли отладки Unity и Crashlytics.
Поймайте и ручку, брошенные исключения
Исключения создаются и брошены, чтобы отразить неожиданные или исключительные состояния . Решение проблем, отраженных исключением, включает в себя возврат программы в известное состояние (процесс, известный как обработка исключений ).
Лучшая практика - поймать и справиться со всеми предусмотренными исключениями, если программа не может быть возвращена в известное государство.
Чтобы контролировать, какие виды исключений пойманы и обрабатываются каким кодом, обертите код, который может генерировать исключение в блоке try-catch . Убедитесь, что условия в операторах catch настолько узкие, насколько это возможно, для надлежащего обработки конкретных исключений.
Исключения журнала в Unity или Crashlytics
Существует несколько способов записать исключения в единстве или Crashlytics, чтобы помочь отладить проблему.
При использовании Crashlytics, вот два наиболее распространенных и рекомендуемых вариантов:
Вариант 1: Печать в консоли Unity, но не сообщайте о Crashlytics, во время разработки или устранения неполадок
- Печать в консоль Unity с использованием
Debug.Log(exception),Debug.LogWarning(exception)иDebug.LogError(exception), которые печатают содержимое исключения из консоли Unity и не перепроизводите исключение.
- Печать в консоль Unity с использованием
Вариант 2: Загрузка в Crashlytics для консолидированной отчетности в панели Crashlytics для следующих ситуаций:
- Если исключение стоит войти, чтобы отладить возможное последующее событие Crashlytics, используйте
Crashlytics.Log(exception.ToString()). - Если исключение все еще следует сообщать о Crashlytics, несмотря на то, что его поймают и обрабатывают, используйте
Crashlytics.LogException(exception), чтобы зарегистрировать его в качестве нерадостного события.
- Если исключение стоит войти, чтобы отладить возможное последующее событие Crashlytics, используйте
Однако, если вы хотите вручную сообщить о фатальном событии для диагностики облака Unity, вы можете использовать Debug.LogException . Этот вариант печатает исключение из опции 1, но он также бросает исключение (независимо от того, было ли оно брошено или пойман еще). Он бросает ошибку нелокально. Это означает, что даже окружающая Debug.LogException(exception) с блоками try-catch по-прежнему приводит к неучтенному исключению.
Поэтому позвоните Debug.LogException тогда и только тогда, когда вы хотите сделать все следующее:
- Чтобы распечатать исключение из консоли единства.
- Чтобы загрузить исключение в Crashlytics как смертельное событие.
- Чтобы добавить исключение, если его рассматривают как необратимое исключение и сообщить о его диагностике Облако.
Обратите внимание, что если вы хотите распечатать пойманное исключение из консоли 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
//
}