Узнайте точное время сбоя в Crashlytics

Question

В моем приложении я хотел бы узнать точное время любого сбоя с предыдущей сессии, о которой сообщается через Crashlytics. Я настраиваю Crashlytics так:

- (void) setUpCrashlytics 
{ 
    [[Fabric sharedSDK] setDebug:YES]; 
    [CrashlyticsKit setDebugMode:YES]; 
    [CrashlyticsKit setDelegate:self]; 
    [Fabric with:@[[Crashlytics class]]]; 
} 

Я имитируя сбой приложения, нажав на кнопку, через несколько минут после приложения запускает:

[CrashlyticsKit crash]; 

Я пытался получить время аварии последней сессии с помощью CrashlyticsDelegate:

#pragma mark - CrashlyticsDelegate Methods 
- (void) crashlyticsDidDetectReportForLastExecution:(CLSReport *) report completionHandler:(void (^)(BOOL)) completionHandler 
{ 
    BOOL isCrash = report.isCrash; //this is TRUE 

    NSDate *crashDate = report.crashedOnDate; 
    NSDate *reportCreation = report.dateCreated; 

    [[NSOperationQueue mainQueue] addOperationWithBlock:^{ 
     completionHandler(YES); 
    }]; 
} 

но, к сожалению, обе даты отображения не время аварии, но на прошлой сессии время запуска. Есть идеи? Благодарю.

Answer 1

Мэтт здесь из Crashlytics.

К сожалению, вы нашли ошибку :(Я принял к сведению, и я прослежу, чтобы он получает смотреть.

Я также интересно узнать, что, как вы собираетесь использовать этот информация. Это просто прецедент, о котором я не слышал раньше.

Кроме того, имейте в виду, что конкретный обратный вызов делегата является проблематичным. Как мы указываем в документации заголовка, API этого метода требует от нас пожертвовать некоторыми функциями надежности Я бы рекомендовал избегать этого, потому что наша способность успешно сообщать о сбоях намного лучше без него. Да, у нас есть планы по добавлению нового API для чтения, который позволяет избежать этого компромисса. На данный момент я бы рекомендовал его, если вы иметь av которая не может быть удовлетворена любым другим способом.

Кроме того, поскольку он был взят в комментариях - этот API никогда не будет вызываться для завершения вывода из памяти. Это технически не сбой, и они не сообщаются как таковые. Используемые нами механизмы совершенно разные и описаны в нашей документации здесь: https://docs.fabric.io/apple/crashlytics/OOMs.html. Мы используем эвристику и на 100% не надеемся (и не претендуем). Это очень хорошо.

Надеюсь, что это будет полезно - и поднимитесь на наши форумы поддержки/электронную почту для дальнейшей помощи. Переполнение стека труднее контролировать :)

Update:

Я думал, что было бы полезно подробнее здесь, теперь, когда я понимаю, что Radu пытается достичь. Результат использования этого метода делегата не может достичь того, что он хотел бы, и на самом деле будет только ухудшать ситуацию.

В настоящий момент Crashlytics инициализируется (во время вызова -[Fabric with:]), SDK готовит и завершает любые сбои на диске до NSURLSession. Мы делаем это, потому что хотим убедиться, что процесс загрузки не прерывается другим сбоем. Насколько мне известно, эта функция уникальна для нашей реализации, мы используем ее в течение многих лет, и она работает удивительно хорошо. Crashlytics в основном невосприимчив к сообщениям о сбоях, вызванных сбоями при последующих запусках.

Теперь, чтобы убедиться, что это работает как можно лучше, мы должны выполнить эту работу синхронно во время запуска. Таким образом, если вы запускаете Crashlytics/Fabric в фоновом потоке или выполняете фоновые работы одновременно с инициализацией SDK, это ставит под угрозу нашу способность надежно завершить этот процесс до того, как может произойти другой потенциальный сбой.

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

• Crashlytics не будет посылать отчеты, потому что она ждет вашего разрешения, чтобы сделать это
• другой аварии может привести к потере Ожидаемые отчеты

В течение времени между вызываемым делегатом и вызываемым обратным вызовом вы не уделяете больше времени на отправку отчетов. Вы просто добавляете задержку, прежде чем SDK знает, что вы дали разрешение на их отправку.

(Лично я считаю этот API очень проблематичным и хотел бы его удалить. Но мы должны сохранить его для обратной совместимости. Это действительно моя ошибка в том, что вы не внедряете новый API, который не позволяет делегату отмените отчет. Такой API не будет подвержен задержке выдачи отчета и может избежать всех этих проблем. Однажды у нас это будет, и мы можем, наконец, отказаться от этого.)

Итак, чтобы улучшить обработку аварии рано запуска, я бы рекомендовал следующее:

• никогда не инициализировать Crashlytics на фоне потока
• убедитесь, чтобы инициализировать Crashlytics как в начале запуска, как вы можете, в идеале самое первое приложение делает
• никогда не использовать этот метод делегата

Единственные исключения должны быть действительно:

• вы пытаетесь внедрить диалоговое окно разрешений отчетов об ошибках, ориентированных на пользователя (он был разработан именно для этого варианта использования)
• хотите сдуть чувствительные данные кеша, которые могут быть ответственны за сбои
• есть некоторые другие механизмы аналитики, и вы хотите считать сбои

Я также рекомендовал бы, обратившись в нашу службу поддержки. Отсутствуют аварии. Отсутствие сбоев, вызванных проблемами с SDK, является необычным, контролируется, и у нас есть тонна SDK-кода и кода на стороне сервера, чтобы понять и минимизировать их.