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