Эта страница содержит помощь по устранению неполадок и ответы на часто задаваемые вопросы об использовании Crashlytics . Если вы не нашли то, что искали, или вам нужна дополнительная помощь, обратитесь в службу поддержки Firebase .
Общие вопросы по устранению неполадок/FAQ
Вы могли заметить два разных формата для задач, перечисленных в таблице «Проблемы» в консоли Firebase . Кроме того, в некоторых задачах вы могли заметить функцию под названием «варианты». Вот почему!
В начале 2023 года мы внедрили улучшенный аналитический механизм для группировки событий, а также обновили дизайн и добавили ряд расширенных функций для новых выпусков (например, варианты!). Подробности читайте в нашем недавнем блоге , а ниже вы найдёте самые важные моменты.
Crashlytics анализирует все события вашего приложения (например, сбои, нефатальные ошибки и ANR) и создает группы событий, называемые проблемами . Все события в проблеме имеют общую точку отказа.
Чтобы сгруппировать события по этим проблемам, улучшенный механизм анализа теперь учитывает множество аспектов события, включая кадры в трассировке стека, сообщение об исключении, код ошибки и другие характеристики платформы или типа ошибки.
Однако внутри этой группы событий трассировки стека, приводящие к сбою, могут различаться. Различная трассировка стека может указывать на иную первопричину. Чтобы отразить это возможное различие внутри проблемы, мы теперь создаём варианты внутри проблем: каждый вариант представляет собой подгруппу событий в проблеме, имеющих одну и ту же точку сбоя и схожую трассировку стека. С помощью вариантов можно отладить наиболее распространённые трассировки стека внутри проблемы и определить, приводят ли разные первопричины к сбою.
Вот что вы ощутите благодаря этим улучшениям:
Обновленные метаданные, отображаемые в строке выпуска
Теперь стало проще понимать и решать проблемы в вашем приложении.Меньше повторяющихся проблем
Изменение номера строки не приводит к возникновению новой проблемы.Более простая отладка сложных проблем с различными корневыми причинами
Используйте варианты для отладки наиболее распространенных трассировок стека в рамках проблемы.Более значимые оповещения и сигналы
Новая проблема фактически представляет собой новую ошибку.Более мощный поиск
Каждая проблема содержит больше доступных для поиска метаданных, таких как тип исключения и имя пакета.
Вот как реализуются эти улучшения:
Когда мы получим новые события из вашего приложения, мы проверим, соответствуют ли они существующей проблеме.
Если совпадений нет, мы автоматически применим к событию наш более интеллектуальный алгоритм группировки событий и создадим новую задачу с обновленным дизайном метаданных.
Это первое крупное обновление нашей группы мероприятий. Если у вас есть отзывы или вы столкнулись с какими-либо проблемами, пожалуйста, сообщите нам об этом , отправив отчёт.
Если вы не видите журналы навигации , рекомендуем проверить конфигурацию вашего приложения для Google Analytics . Убедитесь, что выполнены следующие требования:
Вы включили Google Analytics в своем проекте Firebase.
Вы включили совместное использование данных для Google Analytics . Подробнее об этом параметре читайте в статье «Управление настройками совместного использования данных Google Analytics».
У тебя естьдобавил Firebase SDK для Google Analyticsв ваше приложение. Этот SDK необходимо добавить в дополнение к SDK Crashlytics .
Вы используетепоследние версии Firebase SDKдля всех продуктов, которые вы используете в своем приложении.
Если вы не видите оповещений о скорости, убедитесь, что вы используетеCrashlytics SDK 11.7.0+.
Если вы не видите показателей без сбоев (например, количество пользователей и сеансов без сбоев) или видите ненадежные показатели, проверьте следующее:
Убедитесь, что вы используетеCrashlytics SDK 11.7.0+.
Убедитесь, что настройки сбора данных не влияют на качество ваших показателей безотказности:
Если вы включите отправку отчётов по подписке, отключив автоматическую отправку отчётов о сбоях, информация о сбоях будет отправляться в Crashlytics только от пользователей, которые явно согласились на сбор данных. Это повлияет на точность показателей отсутствия сбоев, поскольку Crashlytics получает информацию только от этих пользователей, подписавшихся на рассылку (а не от всех ваших пользователей). Это означает, что ваши показатели отсутствия сбоев могут быть менее надёжными и хуже отражать общую стабильность вашего приложения.
Если у вас отключен автоматический сбор данных, вы можете использовать
sendUnsentReportsдля отправки кэшированных на устройстве отчётов в Crashlytics . Этот метод отправит в Crashlytics данные о сбоях , но не данные о сеансах , из-за чего на диаграммах консоли будут отображаться низкие или нулевые значения для метрик без сбоев.
См. раздел Понимание показателей отсутствия сбоев .
Если вы используете Unity IL2CPP и видите несимволизированные трассировки стека, попробуйте сделать следующее:
Убедитесь, что вы используете версию Crashlytics Unity SDK 8.6.1 или выше.
Убедитесь, что вы настроили и запустили команду Firebase CLI
crashlytics:symbols:uploadдля создания и загрузки файла символов.Эту команду CLI необходимо выполнять каждый раз при создании сборки релиза или любой сборки, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase . Подробнее см. на странице «Получение читаемых отчётов о сбоях» .
Да, Crashlytics может отображать символьные трассировки стека для ваших приложений, использующих IL2CPP. Эта возможность доступна для приложений, выпущенных как на платформах Android, так и Apple. Вот что вам нужно сделать:
Убедитесь, что вы используете версию Crashlytics Unity SDK 8.6.0 или выше.
Выполните необходимые задачи для вашей платформы:
Для приложений на платформе Apple : никаких специальных действий не требуется. Для приложений на платформе Apple плагин Firebase Unity Editor автоматически настраивает ваш проект Xcode для загрузки символов.
Для приложений Android : убедитесь, что вы настроили и запустили команду Firebase CLI
crashlytics:symbols:uploadдля создания и загрузки файла символов.Эту команду CLI необходимо выполнять каждый раз при создании сборки релиза или любой сборки, для которой вы хотите видеть символизированные трассировки стека в консоли Firebase . Подробнее см. на странице «Получение читаемых отчётов о сбоях» .
Заметки позволяют участникам проекта комментировать конкретные проблемы с помощью вопросов, обновлений статуса и т. д.
Когда участник проекта публикует заметку, она помечается адресом электронной почты его учётной записи Google. Этот адрес электронной почты виден всем участникам проекта, имеющим доступ к просмотру заметки.
Ниже описан доступ, необходимый для просмотра, написания и удаления заметок:
Участники проекта с любой из следующих ролей могут просматривать и удалять существующие заметки, а также писать новые заметки по проблеме.
Участники проекта с любой из следующих ролей могут просматривать заметки, опубликованные по проблеме, но не могут удалять или писать заметки.
- Project Viewer , Firebase Viewer , Quality Viewer или Crashlytics Viewer
Интеграции
Если ваш проект использует Crashlytics вместе с Google Mobile Ads SDK, вероятно, что средства отправки отчётов о сбоях мешают регистрации обработчиков исключений. Чтобы устранить эту проблему, отключите отправку отчётов о сбоях в Mobile Ads SDK, вызвав метод disableSDKCrashReporting .
После подключения Crashlytics к BigQuery новые создаваемые вами наборы данных автоматически размещаются в США, независимо от местоположения вашего проекта Firebase.
Регрессивные проблемы
Проблема была решена повторно, и вы уже закрыли её, но Crashlytics получает новый отчёт о её повторном возникновении. Crashlytics автоматически открывает эти регрессивные проблемы, чтобы вы могли устранить их в соответствии с требованиями вашего приложения.
Вот пример сценария, который объясняет, как Crashlytics классифицирует проблему как регрессию:
- Впервые в истории Crashlytics получает отчёт о сбое под номером «A». Crashlytics открывает соответствующую задачу для этой задачи (задача «A»).
- Вы быстро исправляете эту ошибку, закрываете проблему «А», а затем выпускаете новую версию своего приложения.
- Crashlytics получает еще один отчет по проблеме «А» после того, как вы ее закрыли.
- Если отчёт относится к версии приложения, о которой Crashlytics было известно на момент закрытия вами проблемы (то есть эта версия отправила отчёт о любом сбое), то Crashlytics не будет считать проблему регрессивной. Проблема останется закрытой.
- Если отчет получен из версии приложения, о которой Crashlytics не знала на момент закрытия вами вопроса (это означает, что версия вообще не отправляла никаких отчетов об ошибках), то Crashlytics считает проблему регрессировавшей и повторно откроет ее.
Когда проблема регрессирует, мы отправляем оповещение об обнаружении регрессии и добавляем к проблеме сигнал регрессии, чтобы вы знали, что Crashlytics повторно открыл её. Если вы не хотите, чтобы проблема была повторно открыта из-за нашего алгоритма регрессии, «заглушите» её, а не закрывайте.
Если отчет получен из старой версии приложения, которая не отправляла никаких отчетов о сбоях до момента закрытия вами проблемы, то Crashlytics посчитает проблему регрессировавшей и откроет ее повторно.
Такая ситуация может возникнуть в следующей ситуации: вы исправили ошибку и выпустили новую версию приложения, но у вас всё ещё есть пользователи старых версий без исправления ошибки. Если по какой-то причине одна из этих старых версий вообще не отправляла отчёты о сбоях на момент закрытия проблемы, и эти пользователи начнут сталкиваться с ошибкой, то эти отчёты о сбоях приведут к регрессивной проблеме.
Если вы не хотите, чтобы проблема была повторно открыта из-за нашего регрессионного алгоритма, «отключите» проблему вместо ее закрытия.
Сообщение о неперехваченных исключениях как о фатальных
Crashlytics может сообщать о неперехваченных исключениях как о фатальных (начиная с версии Unity SDK 10.4.0 ). В следующих ответах на часто задаваемые вопросы объясняется смысл и рекомендации по использованию этой функции.
Сообщая о неперехваченных исключениях как о фатальных, вы получаете более реалистичное представление о том, какие исключения могут привести к невозможности играть в игру — даже если приложение продолжает работать.
Обратите внимание, что если вы начнете сообщать о фатальных ошибках, процент пользователей, не терпевших сбои (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
//
}