NSThread, NSOperation или GCD для CoreMotion и точного определения времени? - PullRequest
0 голосов
/ 24 января 2012

Я собираюсь сделать некоторые высокоточные показания движения ядра (> = 100 Гц, если это возможно) и анализ движения на iPhone 4+, которые будут работать непрерывно в течение всей основной части приложения. Крайне важно, чтобы реакция на движение и сигналы, которые посылает код анализа, были максимально свободными от задержек.

Мой первоначальный план состоял в том, чтобы запустить выделенный NSThread на основе кода в проекте метронома, на который есть ссылка: Точная синхронизация в iOS вместе с протоколом для анализаторов движения для соединения и использования потока. Мне интересно, могут ли быть лучше очереди GCD или NSOperation?

У меня сложилось впечатление, что после обильного чтения они предназначены для обработки определенного количества разовых одноразовых операций, а не небольшого числа операций, выполняемых снова и снова с регулярным интервалом, и что их использование каждую миллисекунду или около того может непреднамеренно создайте много потоков создания / уничтожения накладных расходов. У кого-нибудь есть опыт здесь?

Мне также интересно узнать о влиянии на производительность бесконечного цикла while в потоке (например, в коде по ссылке выше). Кто-нибудь знает больше о том, как все работает под капотом с нитками? Я знаю, что iPhone4 (и ниже) являются одноядерными процессорами и используют своего рода интеллектуальную многозадачность (упреждающую?), Которая переключает потоки на основе различных временных требований и требований ввода / вывода для создания эффекта параллелизма ...

Если у вас есть поток, у которого простой цикл while работает бесконечно, но выполняет какую-либо дополнительную работу каждую миллисекунду или около того, считает ли алгоритм переключения процессора бесконечный цикл «высоким требованием» к ресурсам, перехватывая их от других потоки или это будет достаточно разумно, чтобы распределять ресурсы более интенсивно по отношению к другим потокам в «простое» между выполнением дополнительного кода?

Заранее благодарим за помощь и опыт ...

1 Ответ

0 голосов
/ 24 января 2012

IMO узким местом являются скорее датчики. Фактическая частота обновления чаще всего не равна указанной вами. См. частота обновления, установленная для deviceMotionUpdateInterval, это фактическая частота? и Фактическая частота обновлений движения устройства ниже ожидаемой, но увеличивается с настройкой

Некоторое время назад я сделал несколько измерений, используя Core Motion и необработанные данные датчика. Мне тоже нужна была высокая частота обновления, потому что я делал интеграцию Симпсона и поэтому хотел минимизировать ошибки. Оказалось, что реальная частота всегда ниже и что существует предел около 80 Гц. Это был iPhone 4 с iOS 4. Но если вам это не нужно для научных целей, в большинстве случаев частота 60–70 Гц должна соответствовать вашим потребностям.

...