3

現在、ユーザーがオフラインのときに iOS アプリがジョブ (メッセージの送信やバックエンド サーバーへのデータの送信など) をキューに入れることができるようにする、何年も前に書いた古いコードがいくつかあります。ユーザーがオンラインに戻ると、タスクが実行されます。アプリがバックグラウンドになるか終了すると、キューはシリアル化され、アプリが再び起動されたときに再び読み込まれます。私はサブクラス化NSOperationQueueし、私のジョブは のサブクラスですNSOperation。これにより、直接サブクラス化できるデータ構造 (オペレーション キュー) を提供する柔軟性が得られます。サブクラス化することでNSOperation、タスクが失敗した場合 (サーバーがダウンした場合など) に簡単に再キューイングできます。

壊れていない場合は直さないので、そのままにしておく可能性が非常に高いですよね?また、これらは非常に軽量な操作であり、現在取り組んでいるアプリでは、常に非常に多くのタスクがキューに入れられるとは思っていません。NSOperationただし、直接使用するのではなく、使用すると余分なオーバーヘッドがあることはわかっていGCDます。

できる方法でディスパッチ キューをサブクラス化できるとは思わないNSOperationQueueので、アプリが背景ですよね?また、失敗した場合にジョブを再キューイングする方法もわかりません。HTTP 500 responseたとえば、オペレーション コードでサーバーからを取得すると、失敗したNSOperationオブジェクトのディープ コピーを含む通知を送信します。カスタム操作キューがこの通知を受け取り、タスクをそれ自体に追加します。で同様のことができるかどうかはわかりませんGCD。また、ネットワーク接続が失われたときにすべての操作をキャンセルするか、キューを一時停止し、ネットワーク アクセスが回復したときに再アクティブ化する簡単な方法も必要です。

GCD似たようなことをした人や、私よりもよく知っている人から、考え、意見、アイデアを得たいと思っています。

また、いくつかの新しいバックグラウンド タスクのサポートが追加iOS 7されることはわかっていますが、それが私の展開ターゲットになるまでにはしばらく時間がかかるでしょう。それが私が必要とすることを正確に行うかどうかもまだわからないので、現時点ではGCD.

ありがとう。

4

1 に答える 1

1

NSOperationvs ブロックを GCD に送信することが測定可能なオーバーヘッドとして表示される場合、問題は を使用していることではなく、NSOperation操作が細かすぎることですこのオーバーヘッドは、実際の状況では事実上測定不能であると予想されます。(確かに、オーバーヘッドを測定するためのテスト ハーネスを考え出すことはできますが、実際には何もしない操作を行うことによってのみ可能です。)

仕事を成し遂げる最高レベルの抽象化を使用します。確かなデータがそうすべきだと言っている場合にのみ、下に移動してください。

于 2013-08-08T17:26:47.447 に答える