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

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

0 голосов
/ 10 ноября 2019

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

Теперь с 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

Запросы службы определения местоположенияинтерфейс WiFi во вторых интервалах. Прибор показывает, что эти запросы запросов имеют утечку памяти.

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

...