На этой странице представлена помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании 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+) .
Процент пользователей, у которых не возникло сбоев, представляет собой совокупность данных по времени , а не среднее значение.
Значение без сбоев представляет собой процент пользователей, которые взаимодействовали с вашим приложением, но не имели сбоев за определенный период времени. Вы выбираете этот период времени в раскрывающемся меню в правом верхнем углу панели инструментов Crashlytics.
Например, представьте, что у вашего приложения три пользователя; мы будем называть их пользователем A, пользователем B и пользователем C. В следующей таблице показано, какие пользователи взаимодействуют с вашим приложением каждый день и у кого из этих пользователей в тот день произошел сбой:
| Понедельник | Вторник | Среда | |
|---|---|---|---|
| Пользователи, взаимодействовавшие с вашим приложением | А, Б, С | А, Б, С | А, Б |
| Пользователь, у которого произошел сбой | С | Б | А |
В среду процент безаварийных пользователей составляет 50% (у 1 из 2 пользователей не было сбоев).
Двое ваших пользователей взаимодействовали с вашим приложением в среду, но только у одного из них (Пользователь Б) не было сбоев.За последние 2 дня процент пользователей, у которых не было сбоев, составляет 33,3% (у 1 из 3 пользователей не было сбоев).
Трое из ваших пользователей взаимодействовали с вашим приложением за последние два дня, но только у одного из них (пользователь C) не было сбоев.За последние 3 дня процент пользователей, у которых не было сбоев, составляет 0 % (у 0 из 3 пользователей не было сбоев).
Трое пользователей взаимодействовали с вашим приложением за последние три дня, но ни у одного из них не было сбоев.
Интеграции
Если ваш проект использует 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 считает, что проблема регрессировала, и повторно открывает проблему.
Это может произойти в следующей ситуации: вы исправили ошибку и выпустили новую версию своего приложения, но у вас все еще есть пользователи старых версий без исправления ошибки. Если случайно одна из этих старых версий вообще не отправляла никаких отчетов о сбоях, когда вы закрыли проблему, и эти пользователи начали сталкиваться с ошибкой, то эти отчеты о сбоях вызовут регрессию проблемы.
Если вы не хотите, чтобы проблема снова открывалась из-за нашего алгоритма регрессии, «заглушите» проблему, а не закрывайте ее.