Ответ
BroadcastReceiver используется для реагирования на системные или кастомные широковещательные сообщения. Основные сценарии:
- Системные события (изменение состояния сети, зарядка, завершение загрузки):
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>-
Межпроцессное взаимодействие (когда нужно уведомить несколько компонентов)
-
Фоновые операции (но с ограничениями начиная с Android 8+)
Важно:
- Для Android 8+ используйте
Context.registerReceiver()вместо манифеста - Избегайте долгих операций - лучше запускать Service/WorkManager
- Для межкомпонентного взаимодействия в одном приложении предпочтительнее LiveData/Flow
Пример регистрации в коде:
val receiver = object : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
// handle event
}
}
registerReceiver(receiver, IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION))Ответ 18+ 🔞
А, блядь, BroadcastReceiver! Ну это же классика, ёпта, как старый добрый холодильник «ЗИЛ» — работает, пока не отключишь от розетки, но бензина жрёт дохуя, если неаккуратно пользоваться.
Смотри, чувак, представь себе такого всевидящего ушастого зайца в твоём приложении. Его работа — сидеть на попе ровно и слушать, что творится вокруг. Как только система или кто-то другой крикнет в эфир «Эй, все! Сеть пропала!» или «Батарея зарядилась!», этот заяц сразу подскакивает и говорит: «Опа, я тут!» Это и есть BroadcastReceiver, манда с ушами, которая ловит эти самые широковещательные интенты.
Основные сценарии, где его применяют, — это вообще пиздопроебибна:
- Системные события. Это когда тебе надо среагировать на какую-то системную хрень. Например, телефон включился, зарядка началась, картинка скачалась. В манифесте раньше прописывали фильтр, и всё было чётко. Типа такого:
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>То есть, грубо говоря, «разбуди меня, когда система полностью загрузится».
-
Межпроцессное общение. Ну тут всё просто: один компонент орет на всю деревню, а все, кто подписался, его слышат. Удобно, когда надо уведомить кучу народу разом. Но, блядь, доверия к этому механизму сейчас — ноль ебать, потому что все друг другу спамят.
-
Фоновые операции. Раньше это была хитрая жопа, чтобы что-то сделать в фоне. Но сейчас, ёпта, начиная с Android 8 (Oreo), Гугл взял и накрыл это дело медным тазом. Системные ограничения такие, что волосы дыбом встают. Теперь просто так из манифеста слушать почти нихуя нельзя, кроме пары исключений.
И вот тут самое важное, запомни как «Отче наш», а то будет тебе хиросима:
- Для Android 8 и выше забудь про регистрацию в манифесте для большинства событий. Теперь надо регистрировать ресивер прямо в коде, через
Context.registerReceiver(). Иначе он просто не сработает, будет молчать как партизан. - Не делай в
onReceive()долгих операций! Там у тебя времени — хуй с горы. Система даёт пару секунд, а потом просто убьёт твой процесс. Если надо поработать подольше — запускай Service или, что сейчас модно, WorkManager. Иначе пользователь будет орать «чо за лагающее говно». - Если тебе нужно общение внутри одного приложения — выкинь эту дурацкую идею с ресивером нахуй. Для этого есть современные штуки вроде LiveData, Flow или SharedFlow. Это быстрее, надёжнее и не надо городить огород с интентами.
Вот, смотри, как это выглядит в коде, если делать по-новому, по-взрослому:
val receiver = object : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
// Ну вот, событие пришло. Делай что надо, но быстро, блядь!
// Например, проверь, есть ли интернет.
}
}
// Регистрируем нашего ушастого зайца на конкретное событие — изменение сети.
registerReceiver(receiver, IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION))И не забудь его потом отрегистрировать, когда он не нужен, а то будет течь памяти и приложение сожрёт батарею как не в себя. В общем, инструмент мощный, но сейчас его по рукам сильно отбили. Используй с умом, а не тупо в каждую дырку пихай.