На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании 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+) .
Значение без сбоев представляет собой процент пользователей, которые взаимодействовали с вашим приложением, но не имели сбоев за определенный период времени.
Вот формула для расчета процента безаварийных пользователей. Его входные значения предоставляются 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. Этот адрес электронной почты виден вместе с заметкой всем участникам проекта, имеющим доступ к просмотру заметки.
Ниже описаны права доступа, необходимые для просмотра, записи и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
- Средство просмотра проектов , средство просмотра Firebase , средство просмотра качества или средство просмотра Crashlytics
Интеграции
Если ваш проект использует 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 считает проблему регрессированной и повторно открывает ее.
Это может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправляла никаких отчетов о сбоях, когда вы закрывали проблему, и эти пользователи начали сталкиваться с ошибкой, тогда эти отчеты о сбоях вызовут регрессию проблемы.
Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.