CoreMotionのNSThread、NSOperation、またはGCDと正確なタイミングの目的は？

Question

私は、アプリの主要部分の持続時間の間継続的に実行されるiPhone 4+の高精度コアモーションレディング（可能であれば> 100Hz）とモーション解析を行いたいと考えています。モーションレスポンスと解析コードが送信する信号は、できるだけ遅れなくてもかまいません。

私の元の計画は、メトロノームプロジェクトのコード（Accurate timing in iOS）に基づいて専用のNSThreadを起動し、モーションアナライザがそのスレッドをリンクして使用するプロトコルでした。 GCDやNSOperationのキューが優れているのかどうか疑問に思っていますか？

多読の後で私の印象は、規則的な間隔で繰り返し実行される少数の操作ではなく、一定量の個別の一回限りの操作を処理するように設計されており、不注意に多くのスレッド作成/破壊のオーバーヘッドを作ります。誰もここに経験はありますか？

私はまた、スレッド内の無限のwhileループ（上記のリンクのコードなど）のパフォーマンスへの影響について疑問を抱いています。どのように物事はスレッドでボンネットの下で動作するのか誰かが知っていますか？ iPhone4はシングルコアプロセッサであり、さまざまなタイミングとI/O要求に基づいてスレッドを切り替えて並列処理の効果を作り出すインテリジェントなマルチタスキング（プリエンプティブ？）を使用しています...

単純な「while」ループが無限に実行され、ミリ秒ごとに追加作業しか行わないスレッドがある場合、プロセッサの切り替えアルゴリズムは無限ループをリソースの「高い需要」とみなし、他のスレッドや追加のコード実行間の「ダウンタイム」において、他のスレッドに対してリソースをより重く割り当てることは十分にスマートですか？

ご協力いただきありがとうございます。

Answer 1

IMOのボトルネックはむしろセンサーです。実際の更新頻度は、指定した頻度とほとんど同じではありません。 update frequency set for deviceMotionUpdateInterval it's the actual frequency?とActual frequency of device motion updates lower than expected, but scales up with setting

私はCore Motionと生のセンサーデータを使っていくつかの測定を行ったことがあります。 Simpsonとの統合を行っていたため、エラーを最小限に抑えることができたため、高い更新レートも必要でした。実際の周波数は常に低く、約80Hzに限界があることが判明しました。それはiOS 4を実行しているiPhone 4でした。しかし、科学的目的のためにこれを必要としない限り、ほとんどの場合、60〜70 Hzは必要に応じて必要です。