デザインの問題：ハンドラに送信されたオブジェクトを融合する

Question

ハンドラに投稿されたRunnableオブジェクトを融合させるためのデザインコンセプトのアドバイスや批評を探しています。場合は、イベントスレッドで行う必要がある作業の小さなチャンクを生成するバックグラウンドスレッドがある場合です。各チャンクは通常の方法でハンドラにRunnableとして送信されます。これらのRunnableの1つが実行を開始していない場合、別のRunnableを構築してポストするのではなく、実行したときに追加の作業を行うように変更するのは簡単です。このような作業チャンクの合体は、別のRunnableを構築するよりも安価であり、バックグラウンドスレッドがイベントキューに溢れてしまう問題を減らすことにもなります。

しかし、いくつかの問題があります。まず、イベントキューに配信された最後のRunnableにアクセスする必要があります。私が知る限り、HandlerもLooperもそのような機能を提供していないので、最後に投稿されたRunnableへの参照をバックグラウンドスレッドコードで保持するつもりです。私はちょうどこのような参照を維持することはシステムのどこにでも問題を引き起こさないと仮定しています。

さらに深刻な問題は、Runnableがキューから削除されて開始されたかどうかを知るための方法が必要だということです。私は、Runnableクラスにフラグを追加し、run（）メソッドの開始時に設定することで、これを処理する予定です。フラグのテストとRunnable（バックグラウンドスレッド）の更新とRunnableの実行が開始される（イベントスレッド）フラグの設定との間に競合状態を避けるためには、まだ同期が必要です。

誰もがこのようなことをしたことがありますか？あれば、どうしましたか？私は対処する必要のあるものを見落としていますか？

Answer 1

これは、いくつかの厄介なバグをコードする方法のようです。 私は頻繁にフィードveeeeeryを受信し、それを複数のコンポーネントに投稿するプログラムを持っています。実際にはそれほど害はなく、目に見える副作用はありません。

本当にあなたの状況を完全に理解していない可能性がある場合は、必要な作業がすべて保存され、何らかの種類の「作業チャンク」プールが必要になるしばらくして新しいランナブルを開始する作業スターター。 次のようになります。

最初のイベントでは、「作業スターター」がハンドラに実行可能ファイルをポストします。この実行可能ファイルはプールに現在利用可能なすべての作業を提供して処理を要求し、最後に "作業開始"に終了し、スターターは別の実行可能ファイルを実行し、プールには新しい作業などを要求します。 あなたが投稿する実行可能ファイルは、自分のワーカー実行可能ファイルのサブクラスになることができます。フラグを保存したり、ランナブルを変更したりする必要はありません。そして、同時実行性の問題に対処する必要はありません（もしハンドラが1つしかない場合）