Приложение закрыто из-за использования процессора в iOS 13.2

Question

У меня есть приложение для отслеживания и геозон на основе службы определения местоположения, которое будет работать в течение нескольких дней и недель в фоновом режиме на устройстве iOS 12.2 ff.

Теперь с iOS 13.2 приложение завершается через переменное время, но не менее нескольких часов из-за чрезмерного использования процессора:

Date/Time:        2019-11-09 23:25:18 +0200
End time:         2019-11-09 23:26:06 +0200
OS Version:       iPhone OS 13.2 (Build 17B84)
Architecture:     arm64
Report Version:   29
Incident Identifier: 5B46660C-A347-477F-8AE2-B1401080892B

Data Source:      Microstackshots
Shared Cache:     0x44db8000 94FD24C8-F407-3A82-8D27-367F5B6C7BEC

Command:          Anchorwatch
Path:             /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Identifier:       de.sioned.Anchorwatch
Version:          2.2.1 (14)
Beta Identifier:  68A95EFC-B341-476C-9277-D711242471EC
PID:              57424

Event:            cpu usage
Action taken:     Process killed
CPU:              48 seconds cpu time over 48 seconds (99% cpu average), exceeding limit of 80% cpu over 60 seconds
CPU limit:        48s
Limit duration:   60s
CPU used:         48s
CPU duration:     48s
Duration:         48.39s
Duration Sampled: 14.08s
Steps:            16

Hardware model:   iPad6,12
Active cpus:      2


Heaviest stack for the target process:
  16  ??? (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
  16  ??? (libdispatch.dylib + 74516) [0x1c4ecb314]
  16  ??? (libdispatch.dylib + 36344) [0x1c4ec1df8]
  16  ??? (libdispatch.dylib + 33488) [0x1c4ec12d0]
  16  ??? (libdispatch.dylib + 104312) [0x1c4ed2778]
  16  ??? (libdispatch.dylib + 33948) [0x1c4ec149c]
  16  ??? (libdispatch.dylib + 124996) [0x1c4ed7844]
  16  ??? (libdispatch.dylib + 125216) [0x1c4ed7920]
  16  ??? (libsystem_kernel.dylib + 158196) [0x1c50419f4]


Powerstats for:   Anchorwatch [57424]
Bundle ID:        de.sioned.Anchorwatch
Adam ID:          0
Is first party:   No
App version:      2.2.1
Build version:    14
Is Beta:          No
Share with Devs:  No
UUID:             1C943425-70F9-3670-98D0-45D3051B4BB7
Path:             /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Architecture:     arm64
Footprint:        1046.66 MB
Start time:       2019-11-09 23:25:52 +0200
End time:         2019-11-09 23:26:06 +0200
Num samples:      16 (100%)
CPU Time:         13.971s
Primary state:    15 samples Non-Frontmost App, Non-Suppressed, Kernel mode, Effective Thread QoS Background, Requested Thread QoS Default, Override Thread QoS Unspecified
User Activity:    0 samples Idle, 0 samples Active, 16 samples Unknown
Power Source:     0 samples on Battery, 0 samples on AC, 16 samples Unknown
  16  _pthread_wqthread + 275 (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
    16  _dispatch_workloop_worker_thread + 587 (libdispatch.dylib + 74516) [0x1c4ecb314]
      16  _dispatch_lane_invoke$VARIANT$mp + 419 (libdispatch.dylib + 36344) [0x1c4ec1df8]
        16  _dispatch_lane_serial_drain$VARIANT$mp + 299 (libdispatch.dylib + 33488) [0x1c4ec12d0]
          16  _dispatch_mach_invoke$VARIANT$mp + 471 (libdispatch.dylib + 104312) [0x1c4ed2778]
            16  _dispatch_lane_serial_drain$VARIANT$mp + 759 (libdispatch.dylib + 33948) [0x1c4ec149c]
              16  _dispatch_event_loop_drain$VARIANT$mp + 315 (libdispatch.dylib + 124996) [0x1c4ed7844]
                16  _dispatch_kq_drain + 123 (libdispatch.dylib + 125216) [0x1c4ed7920]
                  16  kevent_id + 8 (libsystem_kernel.dylib + 158196) [0x1c50419f4]
                    1   <User mode>

  Binary Images:
           0x102d80000 -                ???  Anchorwatch             <1C943425-70F9-3670-98D0-45D3051B4BB7>  /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
           0x1c4eb9000 -        0x1c4f2dfff  libdispatch.dylib       <B7EED4C7-560D-3DA6-9B50-ED52A150AAC6>  /usr/lib/system/libdispatch.dylib
           0x1c4f59000 -        0x1c4f69fff  libsystem_pthread.dylib <F8B082D8-24D9-3B1E-B80B-645FC8A88E14>  /usr/lib/system/libsystem_pthread.dylib
           0x1c501b000 -        0x1c5048fff  libsystem_kernel.dylib  <AE4C3D7A-7D08-33E7-BCC6-11AC821B4E48>  /usr/lib/system/libsystem_kernel.dylib

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

У меня нет ни малейшего представления о том, как подойти к проблеме, и я даже не уверен, могу ли я что-нибудь с этим поделать, или это ошибка в 13.2, и мне нужно ждать исправления.

Мое первое предположение заключалось в том, что старая ошибка iOS 12.0, которая без причины прекращала работу фоновых приложений и была исправлена ​​в 12.2, вернулась. Но это кажется чем-то новым. Мне удалось запустить тестовое приложение. IOS 12 завершает работу приложений в фоновом режиме без причины в течение нескольких дней.

Любой намек, как интерпретировать журнал и действовать?

Редактировать:

Похоже, это связано с сообщением iOS 13.2: nehelper отправил неверный код результата [1] для запроса информации Wi-Fi.

Служба определения местоположения опрашивает интерфейс Wi-Fi с интервалом в секунду. Инструмент показывает, что эти вызовы запросов имеют утечку памяти.

Отключение Wi-Fi на устройстве, похоже, решает проблему, хотя это не настоящее решение. Теперь жду выхода iOS 13.3 из бета-версии.

Answer 1

Оказалось, что сторонняя структура, которую я использую, запускает вызовы CNCopyNetworkInfo через секунды. Эти вызовы не могли быть выполнены, поскольку в моем приложении не были включены возможности Wi-Fi, и поэтому вызовы CNCopyNetworkInfo вызывали небольшие утечки памяти, которые со временем складывались.

После включения возможности доступа Wi-Fi утечки памяти исчезли.