たとえば、これらのイベントを取得するにはBroadcastReceiverが必要です。
再起動またはシャットダウン
画面のオンまたはオフ
バッテリーの状態（電圧、プラグイン、温度）
物理的なボタンの押下（カメラ、メディアなど）
しかし、これらのイベントを取得するにはリスナーが必要です。
センサーイベント（加速度、磁場、方向、近接、温度、光レベルなど）のEventListener
ロケーションイベントのLocationListener（ネットワークロケーション、GPS）
イベントを受信できるように、レシーバーとリスナーの両方が存在するようです。明らかなセマンティックの違い以外に、2つの違いは何ですか？特に画面がオフのときにどれだけのCPUを使用して実行できるかなどに関して、一方でできることはありますが、もう一方ではできないことはありますか？イベントを受信するために、2つのまったく異なる構成が存在するのはなぜですか？
これら2つの間には非常に多くの違いがあり、何かに反応することは唯一の類似点の1つです。
違い：
BroadcastReceiversはインテントを受信しますが、リスナーは基本的に何でも実行できます。目的が定義されていないため、これは単なる命名規則です。たとえば、開発Webサイトで「BroadcastReceiver」を検索してから「Listener」を検索します。
BroadcastReceiversは、非直接のインテントブロードキャストを受信するだけで、リスナーは明示的に呼び出されます。
BroadcastReceiverは、明確な目的（インテントの受信）があるため、独自に定義されたクラスですが、リスナーは何でもかまいません。通常はでinterfaceあり、あるクラスから別のクラスにコールバックを作成できるように提供されます。
BroadcastReceiversは通常、グローバルなシステム全体のイベントに使用され、特定のイベントのリスナーに使用されます（つまり、場所センサーは、公開先のリスナーなどがない限り、場所の更新を毎秒提供するべきではありません。スクリーンオフの意図とは対照的です-これは重要であり、すべてに影響するため、関心のあるすべての受信者にブロードキャストする必要があります）
BroadcastReceiverが取得するイベントは通常、非連続イベント（ワンショット）ですが、リスナーは、実行内容に応じて、継続的な更新（連続）に使用できます。
BroadcastReceiversは、マニフェストで宣言されている場合、システムによってインスタンス化できます。リスナーは動的にのみ作成されます（コードを介して）。
CPU /電力の使用量は、両方の実装に依存します。特に、前述のように、リスナーは何でもかまいません。
特に画面がオフのときにどれだけのCPUを使用して実行できるかなどに関して、一方でできることはありますが、もう一方ではできないことはありますか？
BroadcastReceiversの実行時間は10秒しか保証されていません。リスナーは特定の目的を果たさないため、この制限はありません。
BroadcastReceiverから絶対にできないこと：
特に、BroadcastReceiver内からダイアログを表示したりサービスにバインドしたりすることはできません。
おそらくもっとあります-これは私が思いついたものです。
リスナーとレシーバーの両方がトリガー ハンドラーとして機能しますが、それらを分離するのはこれらのトリガーの起源と特性です。
(ブロードキャスト) レシーバーはインテントによってトリガーされます。これらのインテントの起源は、独自のアプリケーションのコンテキストの外にある可能性があります。したがって、これはアプリケーションがプロセス間通信を実装する方法です。
さらに、インテントを受け取るためにアプリケーションが実行されている必要はありません。インテントは、イベントがトリガーされたときにアプリケーションを起動する目覚まし時計として機能できます。これにより、バッテリーと CPU が節約されます。
主な違いは次のとおりです。
イベントリスナーはより継続的な形式です。つまり、センサーやボタンのクリックに関連するイベントがより頻繁に発生します。
ただし、レシーバーは不連続な性質のものです。つまり、ここでのイベントは、ブートのオン/オフ、メッセージなどの連続的な性質のものではありません。