Crash и ANR

Критические сбои (CRASH) и блокировки основного потока (ANR) являются двумя самыми распространенными проблемами в Android-приложениях. События типа CRASH обозначают неожиданное или аварийное завершение работы приложения из-за ошибки или необработанного исключения. ANR возникает, когда основной поток (UI-поток) приложения блокируется на длительное время и не отвечает на определенные действия (для Android-приложений это обычно 5 секунд). Возникнуть такая ситуация может, например, из-за долгой операции ввода-вывода или блокирующего запроса к базе данных. Помимо негативного пользовательского опыта возникновение таких проблем может привести к потере данных, а потому требует эффективных механизмов и инструментов для их обнаружения и решения.

Tracer предоставляет набор инструментов, которые позволяют отслеживать не только сбои и блокировки основного потока вашего приложения, но и ошибки, возникшие в коде на языке нативного программирования (NATIVE), и некритические сбои или ошибки загрузки данных (NON_FATAL). За отправку данных о событиях типа CRASH, ANR и NATIVE отвечает CrashReportConfiguration. Для репортинга NON_FATAL-ов есть отдельный инструмент.

Для того, чтобы оценить надежность приложения и его способность сохранять работоспособность в течение продолжительного периода, Tracer позволяет рассчитывать crash-free – процент пользователей, у которых не возникало сбоев в работе приложения за выбранный период. Отвечает за фичу CrashFreeConfiguration. Рассчитывается метрика как (1 - (Пользователи со сбоем / Все пользователи)) * 100%. При этом важно понимать, что использование приложения на разных устройствах одного пользователя или переустановка приложения на текущем устройстве будут обозначены как самостоятельные единицы при расчётах. Отчёты о полученных Tracer-ом сбоях и графики по событиям можно найти в разделе «Сбои».

ВАЖНО! Tracer хранит данные о событиях за последние 90 дней.

Подключение зависимостей к проекту

dependencies {
    implementation(platform("ru.ok.tracer:tracer-platform:1.3.0"))
    implementation("ru.ok.tracer:tracer-crash-report")
}

Если вы хотите дополнительно поддержать сбор и анализ нативных крэшей, следует подключить соответствующую зависимость:

dependencies {
    implementation(platform("ru.ok.tracer:tracer-platform:1.3.0"))
    implementation("ru.ok.tracer:tracer-crash-report-native")
}

Чтобы Tracer генерировал человекочитаемые стектрейсы, необходимо включить загрузку отладочной информации из нативных библиотек. Подробнее о зависимостях и включении загрузки символов из библиотек — на странице Быстрый старт

После подключения зависимостей следует установить плагины в конфигурацию Tracer:

class MyApplication : Application(), HasTracerConfiguration {
    override val tracerConfiguration: List<TracerConfiguration>
        get() = listOf(
            CrashReportConfiguration.build {
                // ваши опции
            },
            CrashFreeConfiguration.build {
                // ваши опции
            },
        )
}

Описание CrashReportConfiguration

На данный момент в CrashReportConfiguration есть несколько параметров, отвечающих за отправку событий определенных типов. Настроить эти параметры можно при помощи опций CrashReportConfiguration.Builder:

Deprecated-опции CrashReportConfiguration.Builder, от которых мы откажемся в ближайшем будущем:

Описание CrashFreeConfiguration

Перед настройкой CrashFreeConfiguration убедитесь, что вы включили отправку крэшей в CrashReportConfiguration, иначе использование этого плагина будет бесполезно.

Опции CrashFreeConfiguration.Builder:

Deprecated-опции CrashFreeConfiguration.Builder, от которых мы откажемся в ближайшем будущем:

Описание TracerCrashReport

Для отправки NON_FATAL-ов используется метод TracerCrashReport.report:

// Залоггировать не фатальную ошибку.
TracerCrashReport.report(NonFatalException("I'll be ok soon"))

issueKey

По умолчанию все сбои группируются по общим частям стектрейса, но в случае NON_FATAL может возникнуть необходимость выделить ошибку среди других аналогичных. Дело в том, что не всегда стектрейс и место, в котором залогировали ошибку, связаны между собой. Существует способ повлиять на эту группировку и собрать все NON_FATAL одного вида ошибки в одну группу при помощи специального ключа issueKey. Этот параметр также будет отображаться в названии события.

Преимущество issueKey в том, что не только вы сможете легко найти NON_FATAL, относящиеся к конкретной проблеме, но и другие разработчики смогут легко найти по ключу точку логирования этой ошибки (и удалить при необходимости) и отследить его в вашем issue-трекере.

Чтобы установить ключ, воспользуйтесь методом TracerCrashReport.report с параметром issueKey:

// Залогировать нефатальную ошибку с ключом ISSUE-001
TracerCrashReport.report(NonFatalException("What a terrible failure"), issueKey = "ISSUE-001")

ВАЖНО! На текущий момент в Tracer есть лимит в 1 млн событий в день. Поэтому рекомендуется не злоупотреблять этим методом.

Tracer также предоставляет ряд инструментов, позволяющих расширить объем данных, которые вы можете отправлять вместе с событиями. Подробнее о том, как добавить дополнительную информацию, читайте тут.