0

データの更新をトリガーするために、タイマー (および場合によっては曜日) に応じて可変間隔でイベントを発生させるカスタム タイマー クラスを作成しています。粒度に関しては、おそらく時間レベルで異なる間隔を持つでしょう。

これまでに思いついた最良のオプションは、24 要素の配列を使用することです。タイマーが作動するたびに、現在の時間 (24 時間) と配列のインデックスを取得して、新しいタイマー間隔を取得します。長い間隔から短い間隔に移行すると、予想される更新が見逃される状況を処理するためのロジックがおそらく必要になるでしょう (たとえば、長い間隔から短い間隔に移行する場合は、時間の先頭で切り捨てます)。

これを行うためのエレガントな方法を探しています。これは、私のコードを維持している誰にとっても明確であり、コードで簡単に操作できます。これを行うためのより良いアルゴリズム/方法はありますか?

その他の詳細:

ユーザーによってトリガーされる可能性のある手動更新があり、タイマーがリセットされます。したがって、タイマーは「オンザアワー」またはその他の定期的な間隔(のような1:15, 1:30, 1:45)に必要なティックにはなりません。ユーザーは、チェックしたばかりの 2 分後に更新をトリガーする可能性があるため、15 分ごとにチェックしている場合、次のような結果になる可能性があり1:15, 1:30, 1:32, 1:47ます:1:32時点)。

その間隔は、私が開発しているシステム全体で標準であるため、ハードコーディングしても問題ありません。この時点で、一般的なインターバル タイマーである必要はありません (ただし、本質的に一般的なソリューションは歓迎されます)。

4

1 に答える 1

1

私が理解していることから、タイマー サブシステムによって次のアクティビティを達成する必要があります
。 1. 定義済みの間隔でのシステム リフレッシュの自動トリガー。
2. 任意のインスタンスで発生する可能性のあるシステム リフレッシュをトリガーしたユーザー。
3.ticker上記の両方を監視し、リフレッシュをトリガーする A。

以下にいくつかのヒントを示しますが、すべての疑問に完全に答えるわけではないかもしれません
1. 上記の 3 つのタスクは、3 つの異なるスレッドの一部として識別できます。一緒にイベントを設定および設定解除します。つまり、タスク 1 と 2 はイベントを設定し、タスク 3 は設定を解除してイベントを設定します。これらのイベントは、スレッド間で共有される 1 つの同じものです。
2. ポイント - 1、つまり事前に定義された間隔については、ソリューションはより単純になります。各間隔 (つまり、10 分、13 分などの更新をスケジュールしたとします) で、現在の時刻から次の差分時刻を計算し、それがゼロのときにイベントを設定できます。

もちろん、モデリングなどによって抽象化を改善することはできますが、intervalEvent(s)の経験から、タイマーやスケジューリングなどの低レベルの精度ベースの要件については、よりC親切なアプローチがはるかに適していると感じています。
チッ!

于 2012-11-29T17:27:02.427 に答える