オーディオ ファイルを再生する iPhone アプリの場合、ユーザーが聞いたエピソードの進行状況を追跡するシステムに取り組んでいます (たとえば、ユーザーは file1 の最初の 4:35 を聞いてから、別のファイルを開始し、 file1 に戻り、4:35 から始まります)。
メタデータを保存するための Core Data モデルをセットアップしましたが、再生中に現在の場所をどれだけ積極的にキャッシュできるか/すべきか疑問に思っています。
現在、時間ラベルと UISlider 再生ヘッドを更新するために以前に使用されていたメソッドで save: 呼び出しをスタックしています。そのメソッドは、0.2 秒ごとに NSTimerInterval によって呼び出されています。
0.2 秒という精度は、進行状況キャッシュを追跡するために必要な精度よりもはるかに高くなっています。とにかく、値は最も近い秒に丸められるため、基本的にすべての保存の 4/5 が冗長です。
ただし、これが Core Data が行っていることのほとんどすべてであり、常に 1 つのレコードの 1 つの値しか処理していないことを考えると、余分な不要な保存を行う方が理にかなっているのかどうか疑問に思っています。 :'s、または更新の頻度を下げるための 2 番目のタイマーを管理します。
現状では、Instruments は各イベントの保存期間を ~800 と報告しており、ピークは 2000 前後です。これらの結果をどのように解釈するかはよくわかりません。シミュレーターでの実際のアプリのパフォーマンスに大きな影響はないようです。
この種の保存が非常に安価であり、コードの複雑さを低く保つ (単一のタイマーのみを管理する) ことが理にかなっている場合、私はそれをそのままにしますが、私の本能は、どんなに安くてもそれは多くの操作であるということです。