Гибридное мобильное приложение NativeScript: отслеживание / захват сбоев - PullRequest
Новая
       60

Гибридное мобильное приложение NativeScript: отслеживание / захват сбоев

0 голосов
/ 08 мая 2018

Я создаю мобильное приложение NativeScript и, помимо прочего, собираю для аналитических целей, мне нужно фиксировать «сбои приложения» , возможно, с ошибками / причинами его сбоя.

Я натолкнулся на этот пост , но там он был в ответе на вопрос о том, как не дать сбою приложения. Было предложено поймать события аварии: 

var application = require("application");

application.on(application.uncaughtErrorEvent, function (args) {
    if (args.android) {
        // For Android applications, args.android is an NativeScriptError.
        console.log("NativeScriptError: " + args.android);
    } else if (args.ios) {
        // For iOS applications, args.ios is NativeScriptError.
        console.log("NativeScriptError: " + args.ios);
    }
});

Если я пойду выше, то у меня возникнут следующие вопросы. Был бы признателен, если кто-нибудь может подтвердить, означает ли это, что каждый раз, когда приложение аварийно завершает работу, оно будет генерировать это событие application.uncaughtErrorEvent? Могу ли я на это положиться? Если это правда, то, возможно, я могу сделать вызов REST для моего бэкэнда и сохранить дату, время и все, что находится в args.android или args.ios.

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

Любая помощь высоко ценится. Спасибо!

1 Ответ

0 голосов
/ 10 мая 2018

application.onUncaughtError будет поражен, вероятно, в 95-98% случаев во время аварии; это довольно надежно. Я видел сбой приложения без какого-либо уведомления, оно просто фальсифицируется, но я не уверен, что какая-либо система отчетов может справиться с этим.

В процессе запуска приложения я регистрирую пару вещей:

  1. Я создаю global.error функцию; это используется для всего (например, try / catch, обещание / catch), для которого необходимо отправить сообщения об ошибках для удаленной регистрации. Поэтому в любом месте моей кодовой базы я могу сделать global.error(theError);, и это будет обработано; таким образом, мне НЕ нужно беспокоиться о том, чтобы пытаться загрузить или потребовать что-то, пока происходит ошибка, так как это может вызвать другие ошибки.
  2. Я использую событие onUncaughtError, чтобы перехватить все, что обычно не перехватывается, а затем уведомить пользователя о том, что произошла ошибка, и выйти из приложения. (в этом случае попытка восстановления не рекомендуется, так как вы не знаете, откуда возникла ошибка ...)
  3. Если я использую рабочий поток, при запуске рабочего я регистрирую worker.onerror для пересылки его данных в функцию основных потоков global.error И у меня есть конкретное сообщение из рабочей версии global.error, что отправляет ошибку обратно в основной поток. Таким образом, если рабочий сам вызывает global.error, это сообщение передается обратно в основной поток, а затем в global.error в главном потоке, который обрабатывает все правильно.

Эта техника позволяет мне отлавливать практически все ошибки, которые могут возникнуть. Основная функция global.error и onUncaughtError обе используют простую созданную мной библиотеку отчетов, которая передает все данные обратно на один из моих серверов, ЕСЛИ устройство подключено к сети. Если устройство находится в автономном режиме, оно может при желании сохранить данные в файл отчета, который будет загружен позже; или просто проигнорируй это.

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

...