用于 CoreMotion 和精确计时的 NSThread、NSOperation 或 GCD?

发布于 12-28 19:30 字数 683 浏览 5 评论 0原文

我希望在 iPhone 4+ 上进行一些高精度核心运动读取(如果可能的话,>=100Hz)和运动分析,这将在应用程序的主要部分持续运行。运动响应和分析代码发出的信号必须尽可能没有滞后。

我最初的计划是基于节拍器项目中的代码启动一个专用的 NSThread,如下所示:准确计时iOS,以及运动分析器链接和使用线程的协议。我想知道 GCD 还是 NSOperation 队列可能更好?

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

我还想知道线程中无限 while 循环的性能影响(例如上面链接中的代码)。有谁知道更多关于线程在幕后如何工作的信息?我知道 iPhone4(及以下)是单核处理器,并使用某种智能多任务处理(抢占式?),它根据各种计时和 I/O 需求切换线程以创建并行性效果......

如果您有有一个简单的“while”循环无限运行但只在每毫秒左右执行任何额外工作的线程,处理器的切换算法是否认为无限循环对资源“高需求”,从而从其他线程中占用它们,或者它是否足够聪明为其他线程更多地分配资源在额外代码执行之间的“停机时间”?

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

I'm looking to do some high precision core motion reading (>=100Hz if possible) and motion analysis on the iPhone 4+ which will run continuously for the duration of the main part of the app. It's imperative that the motion response and the signals that the analysis code sends out are as free from lag as possible.

My original plan was to launch a dedicated NSThread based on the code in the metronome project as referenced here: Accurate timing in iOS, along with a protocol for motion analysers to link in and use the thread. I'm wondering whether GCD or NSOperation queues might be better?

My impression after copious reading is that they are designed to handle a quantity of discrete, one-off operations rather than a small number of operations performed over and over again on a regular interval and that using them every millisecond or so might inadvertently create a lot of thread creation/destruction overhead. Does anyone have any experience here?

I'm also wondering about the performance implications of an endless while loop in a thread (such as in the code in the above link). Does anyone know more about how things work under the hood with threads? I know that iPhone4 (and under) are single core processors and use some sort of intelligent multitasking (pre-emptive?) which switches threads based on various timing and I/O demands to create the effect of parallelism...

If you have a thread that has a simple "while" loop running endlessly but only doing any additional work every millisecond or so, does the processor's switching algorithm consider the endless loop a "high demand" on resources thus hogging them from other threads or will it be smart enough to allocate resources more heavily towards other threads in the "downtime" between additional code execution?

Thanks in advance for the help and expertise...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

删除→记忆2025-01-04 19:30:01

在我看来,瓶颈在于传感器。实际更新频率通常不等于您指定的频率。请参阅 为 deviceMotionUpdateInterval 设置的更新频率,它是实际频率?设备运动更新的实际频率低于预期,但会随着设置而扩大

不久前,我还使用 Core Motion 和原始传感器数据进行了几次测量。我也需要高更新率,因为我正在进行辛普森积分,因此希望最大限度地减少错误。事实证明,实际频率总是较低,并且在 80 Hz 左右存在极限。这是一台运行 iOS 4 的 iPhone 4。但只要您在大多数情况下不需要出于科学目的,60-70 Hz 就应该可以满足您的需求。

IMO the bottleneck are rather the sensors. The actual update frequency is most often not equal to what you have specified. See update frequency set for deviceMotionUpdateInterval it's the actual frequency? and Actual frequency of device motion updates lower than expected, but scales up with setting

Some time ago I made a couple of measurements using Core Motion and the raw sensor data as well. I needed a high update rate too because I was doing a Simpson integration and thus wnated to minimise errors. It turned out that the real frequency is always lower and that there is limit at about 80 Hz. It was an iPhone 4 running iOS 4. But as long as you don't need this for scientific purposes in most cases 60-70 Hz should fit your needs anyway.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文