BroadcastReceiverについてちょっと混乱しています。タイトルのとおり、アプリにもう 1 つの BroadcastReceiver は必要ないと思います。
または、アプリでたくさんの BroadcastReceiver を使用すると何か問題がありますか? OSの実行メモリとパフォーマンスに影響すると思いますが、そうです。
温かいお時間をありがとうございました。
BroadcastReceiverについてちょっと混乱しています。タイトルのとおり、アプリにもう 1 つの BroadcastReceiver は必要ないと思います。
または、アプリでたくさんの BroadcastReceiver を使用すると何か問題がありますか? OSの実行メモリとパフォーマンスに影響すると思いますが、そうです。
温かいお時間をありがとうございました。
それはすべてあなた次第です。すべてのインテント フィルターを処理するBroadcastReceiver
ために、さまざまなセットの複数のブロードキャスト レシーバーを使用するか、単一のブロードキャスト レシーバーを使用することができます。intent-filter
通常、関連するタスクのグループに機能を提供するはずの一連のインテント フィルターに基づいて、さまざまなレシーバーを定義することをお勧めします。
私が言ったように、それはすべてあなた次第です。多数のインテント フィルターがあり、コードを適切に処理したい場合 (実行するタスクの同様の分類に基づいて)、複数のレシーバーを使用します。そうでなければ、単一の受信機でいくつかのフィルターを処理するのは簡単で論理的です。
さらに、レシーバーやフィルターの数ではなく、レシーバーでのタスクの実行に依存するため、アプリのパフォーマンスが妨げられることはありません。
ヒント:Threads
重いものを持ち上げることが予想される場所ならどこでも紹介してみてください :)
クラスは 1 つの責任を持つべきだと考えられています。そのため、BroadcastReceiver が と インテントの両方SMS
をCALL
処理する場合は、複数のレシーバーを用意することを検討してください。
アプリで必要な数のBroadcastReceiverを宣言できます。受信するすべてのブロードキャストで、100万回の長時間実行されるバックグラウンド操作を開始するかどうかに影響します。
しかし、あなたが計画しているアプリは本当にそれらすべてのレシーバーを必要としますか?
宣言されたレシーバーをプログラムで有効/無効にするAPIがいくつかありますが、これも良いオプションかもしれません。
編集: 自分で少しテストを行う方が簡単だと思います。
これらはすべて、BroadcastReceiverが受信する可能性のあるさまざまなアクションです。そのため、一部のアプリケーションでは、さまざまなタイプのアクションごとに1つのレシーバーを使用して、複数のレシーバーを実装することが簡単になり、より整理されたものになります。あるいは、非常によく似た2つのアクションしか受信しておらず、すべてを1つのレシーバーにまとめる方が簡単な場合もあります。
それは意味がありますか?