NSCore，NSOperation或GCD是否用于CoreMotion和准确的计时目的？

Question

我希望在iPhone 4+上进行一些高精度的核心运动读取（如果可能，>> = 100Hz）和运动分析，这些运动将在应用程序的主要部分持续运行。 至关重要的是，运动响应和分析代码发出的信号应尽可能避免滞后。

我最初的计划是根据节拍器项目中的代码启动一个专用的NSThread，如下所示： iOS中的准确计时 ，以及用于运动分析器链接和使用线程的协议。 我想知道GCD或NSOperation队列是否会更好？

在大量阅读之后，我的印象是，它们被设计为处理大量离散的一次性操作，而不是定期执行一次又一次的少量操作，每毫秒左右使用它们可能会无意中产生很多创建/销毁线程的开销。 有人在这里有经验吗？

我还想知道线程中无休止的while循环对性能的影响（例如上述链接中的代码）。 有人知道线程在幕后如何工作吗？ 我知道iPhone4（及更低版本）是单核处理器，并使用某种智能多任务处理（抢先式吗？），它会根据各种时序和I / O需求切换线程，以产生并行效果。

如果您的线程有一个简单的“ while”循环无休止地运行，但每毫秒才执行任何其他工作，那么处理器的切换算法是否认为该无休止的循环是对资源的“高需求”，因此将其从其他线程中拖累了或是否足够聪明，可以在额外的代码执行之间的“停机时间”内向其他线程分配更多资源？

预先感谢您的帮助和专业知识...

Answer 1

IMO的瓶颈在于传感器。 实际更新频率通常不等于您指定的频率。 请参阅为deviceMotionUpdateInterval设置的更新频率，它是实际频率？ 和设备运动的实际频率更新低于预期，但随着设置的增加而增加

不久前，我还使用Core Motion和原始传感器数据进行了一些测量。 我也需要很高的更新率，因为我正在进行Simpson集成，因此可以最大程度地减少错误。 事实证明，实际频率始终较低，并且极限约为80 Hz。 那是一台运行iOS 4的iPhone4。但是，只要出于科学目的您不需要它，在大多数情况下60-70 Hz仍然可以满足您的需求。