0

そこで、Cocoa アプリケーションの中心部分を再構築しました (本当にやらなければなりませんでした!)。それ以来、問題が発生しています。

簡単な概要: 私のアプリケーションは、外部タイムコードと同期するように QuickTime ムービーの再生を制御します。

したがって、外部タイムコードは CoreMIDI コールバック スレッドに到着し、1 秒あたり約 25 回アプリケーションに送信されます。その後、同期がチェックされ、必要に応じて調整されます。このチェックと調整はすべてメインスレッドで行われます。

すべての処理をバックグラウンド スレッドに配置したとしても、現在多くの GCD ブロックを使用しているため、大量の作業が必要になり、NSThread から呼び出せるように多くの関数を書き直す必要があります。それで、それが私の問題を解決するかどうかを最初に確認したいと思います。

問題

Core MIDI コールバックは常に時間内に呼び出されますが、メイン キューにディスパッチされる GCD ブロックが最大 500 ミリ秒ブロックされることがあります。それが起こった場合、同期を調整してもうまくいかないことは理解できます。理由が見つからなかったので、メインスレッドをブロックするようなことをしているのではないかと推測しています。

私は Instruments に精通していますが、メッセージが時間内に処理されない理由を確認するための適切なモードが見つかりませんでした。

誰か助けていただければ幸いです。私がそれについて何ができるかわかりません。前もって感謝します！

4

2 に答える 2

2

メインスレッドをブロックしているか、イベントであふれさせている可能性があります。

私は3つのことを提案します：

  • タイムコードが CoreMIDI コールバック スレッドに到着したときのタイムスタンプを取得します (「 」を参照してくださいmach_absolute_time()。次に、メイン スレッドの作業が完了している現在の時刻を取得します。その後、メイン スレッドへのポストとそれへのポストの間に経過した時間に基づいて、それに応じて調整できます。実際に処理しています。

  • メインスレッドがブロックされたときに暫定的なタイムコードイベント (現在は古くなっている) が破棄されるような、ある種の合体メカニズムを作成します。これは、イベントを受信するたびにインクリメントされるグローバル NSUInteger と同じくらい簡単です。メイン キューにディスパッチされたブロックは、作成時に現在の値を取得し、処理時にそれを確認できます。差が N (N はユーザーが決定) を超える場合は、処理中のイベントの方が多いため、イベントを破棄します。

  • タイムコード通知ごとにメイン スレッドにイベントを送信しないことを検討してください。毎秒 25 回の調整は大変な作業です。1 秒あたり 5 回の処理だけで「十分な」知覚体験が得られる場合、それは非常に多くの作業が節約されたことになります。

一般に、メイン イベント ループのインストルメント化は少し注意が必要です。Instruments の CPU プロファイラーは非常に役立ちます。驚くかもしれませんが、Allocations インストゥルメントも同様です。特に、Allocations インストルメントを使用してメモリ スループットを測定できます。一時的な (短命の) 割り当てが大量にある場合、これらすべての割り当て/割り当て解除を行うために大量の CPU 時間を消費します。

于 2013-09-04T16:06:40.407 に答える