На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics. Если вы не можете найти то, что ищете, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общие вопросы по устранению неполадок/часто задаваемые вопросы
Если вы не видите пользователей без сбоев, журналы навигации и/или оповещения о скорости, мы рекомендуем проверить конфигурацию вашего приложения для Google Analytics.
Убедитесь, что вы включили Google Analytics в своем проекте Firebase.
Убедитесь, что для Google Analytics включен обмен данными на странице «Интеграция» > «Google Analytics» консоли Firebase. Обратите внимание, что настройки обмена данными отображаются в консоли Firebase, но управляются в консоли Google Analytics.
В дополнение к Firebase Crashlytics SDK убедитесь, что вы добавили Firebase SDK для Google Analytics в свое приложение ( iOS+ | Android ).
Убедитесь, что вы используете последние версии всех своих Firebase SDK ( iOS+ | Android ).
В частности, убедитесь, что вы используете как минимум следующие версии Firebase SDK для Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ для macOS и tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Вы можете заметить два разных формата проблем, перечисленных в таблице «Проблемы» в консоли Firebase. И вы также можете заметить функцию под названием «варианты» в некоторых из ваших задач. Вот почему!
В начале 2023 года мы выпустили улучшенный механизм анализа для группировки событий, а также обновленный дизайн и некоторые дополнительные функции для новых задач (например, вариантов!). Ознакомьтесь с нашим недавним сообщением в блоге , чтобы узнать все подробности, но вы можете прочитать ниже основные моменты.
Crashlytics анализирует все события вашего приложения (такие как сбои, нефатальные ошибки и ANR) и создает группы событий, называемые проблемами — все события в задаче имеют общую точку отказа.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь рассматривает многие аспекты события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако в этой группе событий трассировка стека, приведшая к сбою, может быть другой. Другая трассировка стека может означать другую основную причину. Чтобы представить эту возможную разницу внутри задачи, мы теперь создаем варианты внутри задач — каждый вариант представляет собой подгруппу событий в задаче, которые имеют одну и ту же точку сбоя и аналогичную трассировку стека. С помощью вариантов вы можете отлаживать наиболее распространенные трассировки стека в рамках проблемы и определять, приводят ли различные основные причины к сбою.
Вот что вы почувствуете благодаря этим улучшениям:
Обновленные метаданные отображаются в строке задачи.
Теперь стало проще понимать и сортировать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Более простая отладка сложных проблем с различными первопричинами
Используйте варианты для отладки наиболее распространенных трассировок стека в задаче.Более содержательные оповещения и сигналы
Новая проблема на самом деле представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит дополнительные метаданные с возможностью поиска, такие как тип исключения и имя пакета.
Вот как внедряются эти улучшения:
Когда мы получим новые события из вашего приложения, мы проверим, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более умный алгоритм группировки событий и создадим новую задачу с обновленным дизайном метаданных.
Это первое большое обновление, которое мы вносим в нашу группу событий. Если у вас есть отзывы или вы столкнулись с какими-либо проблемами, сообщите нам об этом, заполнив отчет.
Значение без сбоев представляет собой процент пользователей, которые взаимодействовали с вашим приложением, но не имели сбоев за определенный период времени.
Вот формула для расчета процента безаварийных пользователей. Его входные значения предоставляются 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. Этот адрес электронной почты виден вместе с заметкой всем участникам проекта, имеющим доступ к просмотру заметки.
Ниже описаны права доступа, необходимые для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
Интеграции
Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вполне вероятно, что отчеты о сбоях мешают регистрации обработчиков исключений. Чтобы устранить эту проблему, отключите отчеты о сбоях в Mobile Ads SDK, вызвав disableSDKCrashReporting .
После того как вы свяжете Crashlytics с BigQuery, новые наборы данных, которые вы создаете, автоматически размещаются в США, независимо от местоположения вашего проекта Firebase.
Поддержка платформы
Регрессивные проблемы
У проблемы был регресс, когда вы ранее закрыли проблему, но Crashlytics получает новый отчет о повторном возникновении проблемы. Crashlytics автоматически повторно открывает эти регрессивные проблемы, чтобы вы могли решить их соответствующим образом для своего приложения.
Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:
- Crashlytics впервые получает отчет об аварии «А». Crashlytics открывает соответствующую проблему для этого сбоя (проблема «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получает еще один отчет о проблеме «А» после того, как вы закрыли проблему.
- Если отчет относится к версии приложения, о которой Crashlytics знал, когда вы закрыли проблему (это означает, что версия отправила отчет о сбое для любого сбоя вообще), Crashlytics не будет считать проблему регрессом. Вопрос останется закрытым.
- Если отчет относится к версии приложения, о которой Crashlytics не знал, когда вы закрыли проблему (это означает, что версия вообще никогда не отправляла отчеты о сбоях для каких-либо сбоев), Crashlytics считает проблему регрессированной и повторно открывает проблему. .
Когда проблема регрессирует, мы отправляем предупреждение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыла проблему. Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.
Если отчет относится к старой версии приложения, которая никогда не отправляла отчеты о сбоях, когда вы закрывали проблему, Crashlytics считает, что проблема регрессировала, и повторно открывает проблему.
Это может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начали сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессию проблемы.
Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.