У меня есть длинная операция O, которая вызывается через NSInvocationOperation, сама запланированная путем добавления ее в NSOperationQueue, чтобы она выполнялась асинхронно. Эта длинная операция O вызывается в моем приложении в двух разных случаях.
В случае A, операция O вызывается в результате прикосновения к некоторому виджету в некотором представлении. Как только виджет подключен, операция O выполняется некоторое время (я вижу, что это благодаря UIActivityIndicator), но он не замедляет и не блокирует пользовательский интерфейс, поэтому я могу нажимать на другие виджеты и выполнять другие операции пользовательского интерфейса. во время выполнения операции О.
В случае B операция O вызывается в результате получения локального уведомления в методе didReceiveLocalNotification делегата приложения. В этом случае операции пользовательского интерфейса, выполняемые сразу после вызова операции O, все еще находящиеся в методе didReceiveLocalNotification, значительно замедляются, в основном для обхода, почти как если бы операция O захватила центральный процессор.
Почему это так и каков будет правильный способ вызвать операцию O в случае B, чтобы она действительно выполнялась одновременно в фоновом режиме с более низким приоритетом, оставляя остальную часть кода в методе didReceiveLocalNotification работать нормально? скорость
ПРИМЕЧАНИЕ. Операция O обрабатывает локальные уведомления (удаление существующих или планирование новых) и календари (запросы к хранилищу событий для лучшего планирования локальных уведомлений).