Реагировать родной сбой в IOS при работе в фоновом режиме

Мое приложение очень похоже на фитнес-трекер, и у меня есть следующая ошибка, которую я воспроизвел на iphone 5s и 5c: когда я начинаю отслеживать запуск, при определенных условиях приложение убивается при работе в фоновом режиме.

Условия кажутся следующими:

  • как только я нажму на кнопку запуска трекинга в приложении, заблокируй экран не более чем через 2 секунды
  • оставьте приложение запущенным в фоновом режиме как минимум на 30 минут.

Мне удалось получить журнал сбоев на устройстве и символизировать отчет, но он больше не подсказывает мне. Он просто упоминает родовые классы реакции JS и IOS, где он получает ошибку.

Я использую Bugsnag для сбора отчетов о сбоях, но в этом случае он не отправляет никаких отчетов (возможно, из-за того, что приложение убито и у него нет времени на отправку отчета).

  • Кто-то имеет представление о том, что происходит?
  • Есть идеи о том, как продвинуть расследование дальше?
  • Что-нибудь существенное, что я пропустил из журнала аварий?

Спасибо!

Интересные биты из журнала аварий:

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace <0xF>, Code 0x8badf00d
Triggered by Thread:  0

xcrun atos -arch arm64 -o appDsyms/4C682DF9-82D7-342C-ABC3-6218A1EED4F6.dSYM/Contents/Resources/DWARF/MyApp -l 0x100074000 0x000000010007b2bc 0x00000001001452f4 0x0000000100145318 0x00000001000aba84

main (in MyApp) (main.m:16)
ksmachexc_i_handleExceptions (in MyApp) (KSCrashSentry_MachException.c:237)
ksmachexc_i_handleExceptions (in MyApp) (KSCrashSentry_MachException.c:233)
+[RCTJSCExecutor runRunLoopThread] (in MyApp) (RCTJSCExecutor.mm:211)

полный журнал аварий

Источник

1 ответ

Решение

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

Пришлось профилировать это в течение длительных периодов времени с XCode, чтобы понять, что происходит: у меня была утечка памяти. И если ваше приложение использует слишком много памяти и работает в фоновом режиме, то в какой-то момент iOS сочтет его вредным и просто убьет его.

ВОПРОС

Короче говоря, проблема заключалась в том, что получение координат GPS и отображение обновления в пользовательском интерфейсе (где я рассчитываю расстояние, среднюю скорость и другие аналитические данные) было ограничено.

Таким образом, избыточные действия были запущены в фоновом режиме, в то время как не было обновления для пользовательского интерфейса. Вдобавок ко всему, я хранил GPS-координаты в избыточном хранилище, которое через некоторое время состояло из огромного массива. Это привело к большому количеству ненужной обработки + глупому использованию памяти.

FIX

Я исправил это, отделяя те

  • извлечение и хранение координат GPS (просто сохраняйте координаты в AsyncStorage, без вычислительных действий)

  • обновление пользовательского интерфейса: обновлять каждую секунду таймер, подсчитывающий затраченное время + проверять каждые 2 секунды, если у меня были новые координаты GPS, и вычислять аналитику, если это так

РЕЗУЛЬТАТ

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

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

Так что мои новые знания по этому вопросу!.. Будьте умны, отдельные проблемы.. Профиль в течение длительных периодов. Если у вас есть утечка памяти, подумайте, где и как часто вы храните данные. Если ваше приложение работает в фоновом режиме, максимально ограничьте то, что происходит на этом этапе (избегайте избыточных обновлений, избегайте вычислений, сохраните их для дальнейшей работы)

Источник
Другие вопросы по тегам