1

Rabbitmq クライアントを実行し、キューからメッセージを消費する Android サービスがあります。クライアントはいつでもメッセージを受信できるため、startService を介してサービスを開始しています (バインディング方法論ではありません)。SO 問題は、サービスからさまざまなアクティビティ (バインディングまたは通知) と通信するために使用する通信メカニズムの種類です。バインディングは、受信したメッセージが表示されているものとは異なるアクティビティに関連している可能性があるため、それほど有用ではありません..サービスのキューで受信した非常に多くの異なるメッセージを処理するためのモデルレイヤーを作成することも課題になりつつあります...アイデアや指針はありますか？

4

2 に答える 2

2

メッセージ キューを操作するかなり標準的な方法は次のとおりです。メッセージに何らかのメタデータを追加する必要があります。そして、メッセージを処理するときのメッセージハンドラーは、そのようなメタデータの助けを借りて、どのクラスがメッセージを処理する必要があるかを判断します。その場合、ストラテジー パターンを使用すると非常に便利です。このような手法を使用すると、いくつかのハンドラーでもメッセージを簡単に処理できます。

メタデータは非常に異なる可能性があります: いくつかのフィールド値 (タグなど) から開始するか、特定のクラスまたはインターフェイスからメッセージを拡張することができます...

あなたの質問の2番目の部分に答えます。はい、もちろん、キューを使用している場合は、コンシューマーが必要です。コンシューマーは、メッセージ マネージャーのようにプレイする必要があります。メッセージごとに新しいスレッドを割り当てるのは悪い考えです。アプリで複数のスレッドを使用する場合は、スレッド プールを使用することをお勧めします。とにかく、パフォーマンスに悪影響を与えるため、スレッドの量は多くすべきではありません。消費者がメッセージハンドルロジックを決定する方法、またはこのロジックをスレッド内に配置する方法について話すと、具体的なメッセージが処理されます-両方のバリアントが可能だと思います。それぞれに長所と短所があります。しかし、コンシューマーはキューからのメッセージを管理し、このタスクはメッセージ処理自体よりもメッセージ管理に近いため、このロジックはコンシューマーに任せたほうがよいと思います。

于 2013-01-24T00:06:08.107 に答える