15 秒のカウントダウンを使用するカウントダウン メソッドをゲームに実装しています。私はこれを実装するさまざまな方法を探しており、NSTimer が最適な方法であると考えています。
ただし、プロセッサの速度などの影響を受ける可能性があると誰かが私に言ったので、私の質問は、これが本当かどうか、もしそうなら、どうすればそれに対抗できますか?
私はこれを見てきました: NSTimerしかし、これの影響を完全には理解していません。
15 秒のダウンタイムとすべてのデバイスを保証する他の方法はありますか?
最後の一文がわかりません…
ただし、実際のカウントダウン秒数と比較してわずかにずれているというあなたの友人の意見は正しいと思いますが、その差は非常に小さいため、特にゲームでは目立たないことを保証します.
違いの理由は、NSTimer を 1 秒で実行するように設定したためです。実行すると、画面上のカウントダウンが更新されてから繰り返されます。私の推測では、NSTimer は、メソッドの実行が終了するまで繰り返しを開始しないため、NSTimer の各秒は、実際の秒よりも数分の 1 秒長くなります。
Apple は私の一歩先を行っており、実行の前に繰り返しを呼び出している可能性がありますが、私にはよくわかりません。
いずれにせよ、私が言ったように、毎秒画面を更新する以外に大きなことをしていない限り、ユーザーはまったく違いに気付かないはずです。
NSTimer は、ほとんどの目的で問題ありません。正確ではありません - 期間は設定したものよりもわずかに長くなりますが、良好な状態ではごくわずかです - ミリ秒と考えてください。ただし、NSTimer は runloop を介して起動するため、その精度はその runloop がビジーでないことに依存します。システムがビジー状態の場合、タイマーの期間がわずかに拡大することはありますが、独自のスレッドに専用のランループを配置することで問題を最小限に抑えることができます。
そのため、CPU 速度と他のそのような要因との間に本質的な関係はありませんが、より高速なハードウェアはビジー状態にならないため、より良い状態を保つことができます。
また、繰り返し NSTimer が位相シフトしないことにも注意してください。15 秒と同じくらい正確に 1 秒の間隔に設定されます。唯一の注意点は、次の火災が発生するときにハンドラーがまだ実行されている場合、その火災はまったく発生しないということです。たとえば、1.1 秒かかる場合、発砲間のギャップは最大 2 秒になります。
runloops と NSTimers の代替は、dispatch_after です。ただし、これ以上正確になる可能性は低く、そのスキッドは、起動時にビジーでないターゲット キュー (おそらくデフォルトの同時キューの 1 つ) に左右されます。
理論:NSTimerはプロセッサの速度に直接影響されません。Gen 2 デバイスで 1 分間実行されているタイマーは、より新しいデバイスでも 1 分を表す必要があります。
これが理論でした :) が、実際には、プロセッサの速度はタイマーに影響するだけでなく、アプリの全体的な速度にも影響します (たとえば、ビューが変化する速さ、ボタンを押してから音楽が始まるまでの時間、等）。唯一 (または最良のテスト) は、対象とするデバイスの種類でアプリを繰り返しテストすることです。早期にテストし、頻繁にテストしてください:)
（私の経験に基づいて）Tどのデバイスでも正確な時間を保証することはできません. ただし、平均して予想時間に近い時間を取得できますT。