企业官网建设流程全解析

在Android四大组件里，BroadcastReceiver（广播接收器）经常被人当成最容易上手的一个。确实，写一个接收器类、注册一下、重写onReceive，三行代码就能收到系统广播。可等到真去处理项目里的业务逻辑，各种坑就冒出来了：同样一个广播，有的手机能收到有的收不到；明明正确注册了，安卓8.0之后突然就失效了；还有那种同一件事触发多个回调、重复执行的问题，排查起来真是头大。

这篇文章是“安卓基础”系列的第23篇，也是广播专题的第一篇。先不急着写代码，我们把广播这件事从根上理一遍，重点就是“广播类别”。文章会拆开讲标准广播、有序广播、粘性广播、本地广播和系统广播各自是什么、怎么用、有哪些坑，顺带理清广播的注册方式、Android版本演进带来的限制，以及大家经常混淆的几个“广播”概念（网络广播域、单播多播和BLE广播）。不管你是刚接触Android的新手，还是写过几年业务、对广播机制一直一知半解的老开发，这篇都值得花十分钟看完。

1. 广播背后的设计思路：为什么Android要搞这么一套机制

很多人学广播的时候，脑袋里只有一个模糊的印象：“系统发个通知，我这边收一下”。这理解没错，但太表面了。真实项目里你会遇到的问题，往往都出在你没搞清楚的底层逻辑上。所以我先花点篇幅，把广播这套机制的设计动机讲透。

1.1 解耦：发广播的人根本不用关心谁在听

Android的应用之间是相互隔离的，每个App跑在自己的进程和沙箱里。但现实业务里有大量“一件事发生了，好多地方都要知道”的场景。举个例子：手机飞行模式被打开了。这个事件谁关心？你的下载管理器关心（要暂停下载）、音乐播放器关心（可能要停止播放）、网络层框架关心（要切换网络策略）。如果让每个应用都去轮询系统状态，性能上是灾难，而且状态判断永远有延迟。

广播解决的就是这件事：发送方只负责把“飞行模式开了”这个消息扔出去，它不需要知道谁在听、有多少人在听、听的人会做什么反应。接收方呢，只需要注册一下自己关心的事件类型，事件发生时系统就会自动把消息送过来。这样一来，发送方和接收方完全解耦，谁也不知道对方的存在。

这就像小区里的广播站。广播站喊一嗓子“明天停水了”，它不会挨家挨户打电话，也不在乎你听没听到、听了以后是去备水还是出去住酒店。你作为居民，只需要平时养成听广播的习惯就行。广播站和居民之间，靠的就是“同一个广播频道”这个约定。

1.2 一次广播从发出到接收，系统到底做了什么

理解了设计动机，再看流程就顺了。一次标准广播的完整生命周期是这样的：

1. 发送方调用sendBroadcast(intent)，把Intent丢给系统。
2. 系统收到请求后，由AMS（ActivityManagerService）拿着这个Intent的action去匹配当前系统里所有注册过的BroadcastReceiver。
3. AMS把匹配到的接收者按规则排好队，逐个通知。
4. 接收者的onReceive(context, intent)被回调，你在里面写业务逻辑。

注意，这里有个关键点：广播的发送方和接收方，很多时候根本不是同一个进程。发送方把Intent交给AMS，真正负责分发的是系统进程的AMS，接收方在自己的应用进程里被唤醒。这就是跨进程通信（IPC），底层走的Binder机制。之所以广播能跨App传播，就是因为它经过了系统这个“中转站”。

这也引出一个非常容易踩坑的点：整个过程是异步的。sendBroadcast()执行完，函数就返回了，不会等待接收者处理完。真正处理广播的，是接收方进程里的主线程。所以你在onReceive里写耗时操作，比如访问网络、读写大文件，会直接导致接收方应用ANR（Application Not Responding，应用无响应）。具体怎么规避，后面“常见问题”部分我会详细说。

2. Android广播的五种基本类别

标题里说的“广播类别”，其实指的是发送方式不同、行为语义不同的广播类型。不同类别，对应不同的API和适用场景。这一节是全文核心，我逐个讲。

2.1 标准广播：最常用的异步广播

标准广播是最基础、最常用的一类，调用方式就是一行：

Intent intent = new Intent("com.example.custom.ACTION_TEST"); sendBroadcast(intent);

它的核心特点是完全异步、无序。所有匹配的接收者，都会在同一时刻收到这条广播，接收者之间没有先后顺序。更重要的是，接收者之间不能互相通信，也没办法拦截这条广播，谁也不能阻止别人继续接收。

这种广播实现起来最简单，效率也最高。适合做什么？纯通知类型的场景。比如你登录成功了，发个广播通知一下其他组件“登录状态变了”；或者某个数据同步完成了，通知一下UI刷新。这些场景不需要接收者之间有任何协作，大家收到消息各自干活就行。

但缺点也很明显：因为无序，你没法控制多个接收者之间的执行次序；因为不能拦截，你也没法实现“有人处理了这个事件，别人就别管了”这样的逻辑。这种场景，就需要有序广播了。

2.2 有序广播：能排队、能中断、能传数据

有序广播，API对应的是sendOrderedBroadcast()：

sendOrderedBroadcast(intent, null, null, null, Activity.RESULT_OK, null, null);

这行代码里第二、三、四个参数是权限和接收者相关的高级用法，后面会提。先说它的核心能力：所有匹配的接收者会按照优先级一个一个执行，前一个接收者处理完，后一个才会开始。

优先级怎么定？两种方式：

• 动态注册时，在IntentFilter上调用setPriority(1000)设置。
• 静态注册时，在<intent-filter>标签里写android:priority="1000"属性。

优先级数值越大，越先执行。如果两个接收者优先级相同，动态注册的优先于静态注册的。这里有个小细节：优先级建议不要设成int最大值，因为系统自己的一些广播也用优先级调整顺序，你设成最大值反而可能把系统逻辑搞乱。

有序广播最有价值的两个操作是abortBroadcast()和setResultData()。

abortBroadcast()可以在onReceive里调用，调用之后这条广播就不会再继续往下传了。典型的例子是拦截短信：某些安全类App会注册高优先级接收短信广播，收到之后先判断是不是垃圾短信，是就直接abortBroadcast掉，后面的接收者就收不到了。

setResultData()则是往下一个接收者传数据。注意，有序广播中使用的不是intent.putExtra，而是通过getResultData()/setResultData()这两个API来传递文本数据。实测中很多人都会在这里卡一下：明明下一个接收者收到的Intent还是同一个，你自己往Intent里塞的数据用intent.getXxxExtra也能拿到，但有序广播官方语义推荐用setResultData传递。尤其是当你有“一组接收者链式处理同一个事件，前一个的输出是后一个的输入”这类需求时，ResultData比IntentExtra更可靠。

有序广播也有个注意点：多个接收者串行执行，整体耗时会长一些，高频事件慎用。另外，静态注册的接收者，如果优先级很低，在Android 8.0+环境下可能压根收不到（后面第4节详细说）。

2.3 粘性广播：已经废弃但代码里还经常看到

粘性广播的发送API是sendStickyBroadcast()，从Android 5.0（API 21）开始就已经标记为@Deprecated了。虽然官方废弃，但老项目里经常还能看到，面试也偶尔会问，所以我必须提一下。

它特殊在哪？普通广播发完就结束了，接收者收不到就是收不到。粘性广播则会一直“粘”在系统里，之后无论是谁注册了这个Receiver，系统都把最近一次广播的Intent作为返回值立刻发给他。也就是说，你可以“迟到注册然后补收消息”。

举例：想知道当前电池电量，不需要时时刻刻监听电池变化广播。只需要在电量为某一状态时，注册一个监听ACTION_BATTERY_CHANGED的接收器，registerReceiver()返回的Intent里就包含了当前电池信息。因为这个广播是粘性的，系统里始终缓存着最新状态。

官方废弃它的核心原因是安全。粘性广播的发送方无法控制谁能收到数据，接收方也无法确认数据是谁发的，很容易被用来获取用户隐私。再加上它需要在权限声明android.permission.BROADCAST_STICKY，管理成本高、收益却很低。我的建议很明确：新代码一律别用，老代码见到尽量重构掉。

2.4 本地广播：应用内通信曾经的最优解

本地广播走的API是LocalBroadcastManager，它解决的问题是：广播只在自己App内部传播，不经过系统，其他应用绝对收不到。

看段代码感受一下：

// 注册 LocalBroadcastManager.getInstance(this).registerReceiver(mReceiver, filter); // 发送 LocalBroadcastManager.getInstance(this).sendBroadcast(intent);

用法和全局广播几乎一样，但它有几个明显优势：

• 数据不跨进程，安全性高多了，不用担心别的App注册相同action来监听你的数据。
• 发送和接收都在应用内部，绕开了系统AMS的分发流程，效率更高。
• 不会出现“接收方进程被系统杀掉后，广播丢失”的场景，因为广播就直接发在当前进程里，当前进程活着就有接收者。

这个API之前放在androidx.localbroadcastmanager这个依赖里，但是AndroidX官方后来把LocalBroadcastManager标记为废弃了，推荐用LiveData、Flow或者直接使用StateFlow替代。老项目里如果你还在用LocalBroadcastManager，问题不大，能跑就行；但新项目建议直接用协程的SharedFlow，或者更轻量的接口回调，没必要额外引入这层封装。

2.5 系统广播：开发中最常接触的一类

系统广播是系统在特定事件发生时自动发出的一类广播，比如开机完成、电量低、网络切换、耳机插入、屏幕亮灭、时区变化、安装新应用等。这类广播的action都是系统定义好的常量，例如：

这些系统广播里，有些是允许静态注册的（比如BOOT_COMPLETED），有些只能在运行时动态注册（比如屏幕亮灭、电量变化），还有一些甚至有版本限制（比如网络状态变化）。这一点也是新手最容易出Bug的地方：明明在清单文件里写了ACTION_SCREEN_ON的接收器，却发现收不到。原因就是系统明确规定，这类高频敏感广播不允许静态注册。

判断一个系统广播能不能静态注册，有个简单粗暴的方法：查官方文档的“广播”页面，里面会明确标出“This broadcast can only be received after the receiver is registered dynamically”。不过更稳妥的做法是，开发阶段针对关键系统广播做真机验证，不同厂商ROM对广播的管制也不一样，我在这上面吃过不少亏，后面“常见问题”部分会讲。

3. 注册方式决定广播能不能收到

说完广播类别，必须接着讲注册方式。因为同一个广播，你用静态注册和动态注册去接收，效果天差地别。这里有两套体系要分清。

3.1 动态注册：代码里绑定生命周期

动态注册就是在代码里手动注册、手动注销。标准写法：

private BroadcastReceiver mReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { // 处理广播 } }; @Override protected void onStart() { super.onStart(); IntentFilter filter = new IntentFilter("com.example.custom.ACTION_TEST"); ContextCompat.registerReceiver(this, mReceiver, filter, ContextCompat.RECEIVER_NOT_EXPORTED); } @Override protected void onStop() { super.onStop(); unregisterReceiver(mReceiver); }

注意这里的ContextCompat.registerReceiver写法，这是Android 13（API 33）之后官方推荐的调用方式，比直接调registerReceiver(receiver, filter)多了一个RECEIVER_EXPORTED或RECEIVER_NOT_EXPORTED的显式声明。我后面第4节会专门说这个，因为大部分人还在用旧API，结果在Android 13以上直接崩溃，报SecurityException。

动态注册最大的特点是生命周期跟着组件走。我在onStart里注册、在onStop里注销，这个Receiver就只在Activity可见期间有效。好处是不会泄漏，坏处是如果组件不在运行，广播就收不到。

这里要特别注意：动态注册一定要成对出现。注册了不在合适的时机注销，轻则内存泄漏，重则同一个Receiver被多次注册，一条广播到达时onReceive被调用好几次，业务重复执行。很多线上花式Bug就是这么来的。

3.2 静态注册：清单文件里声明

静态注册是在AndroidManifest.xml里声明Receiver，不需要代码主动注册：

<receiver android:name=".BootReceiver" android:enabled="true" android:exported="true"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> </intent-filter> </receiver>

exported这个属性要留意。有intent-filter时，如果exported不写，不同版本会有不同的默认值行为。在Android 12（API 31）及以上，如果应用targetSdkVersion是31+，带intent-filter的receiver默认exported就是true（这个默认行为在不同版本之间反复横跳，网上很多帖子说默认false，其实是把Activity的规则记到Receiver头上了）。最稳的做法是永远显式声明，别依赖默认值。

静态注册最大的优势是：应用进程死了，系统也能把它拉起来。比如开机广播BOOT_COMPLETED，这是典型的“应用没运行但要触发业务”的场景，必须静态注册。你手机重启后，App进程还没启动，如果这时想收到开机完成的广播去做点初始化，动态注册是做不到的。

但静态注册的坑也最多。除了版本限制（8.0之后大部分隐式广播禁止静态注册），还有个隐蔽问题：如果你给Receiver声明了android:process属性，指定了一个独立进程，那即使静态注册了，各种厂商ROM也会因为进程管理策略直接杀死这个进程，广播自然收不到。

3.3 静态和动态怎么选：我的判断方法

我接手过好几个老项目，里面最乱的就是广播混用：同一个action，动态、静态各注册了一遍，线上经常出现重复执行或者收不到。我总结的选型逻辑很简单：

• 需要应用没启动也能收到广播（比如开机自启、应用更新替换），选静态注册。
• 只在界面可见期间关心事件（比如屏幕亮灭，或者某个页面需要响应网络变化刷新UI），选动态注册。
• 事件涉及敏感数据、不想被其他App监听，用本地广播（或直接换成LiveData/Flow）。
• 静态注册收到后需要做耗时操作，比如网络请求，别在onReceive里直接做，先用goAsync()或丢到JobService里。

一句话：能动态别静态，能本地别全局。全局广播看起来方便，但安全性和可控性都很差，能不碰就别碰。

4. 版本演进带来的广播限制（必踩的坑）

Android广播的API十几年没变过，但系统的限制规则一直在加。很多人的广播代码“当时可好使了”，过几年突然就全挂了，大概率就是版本限制的锅。这一节我按版本线抽几个关键节点讲。

4.1 Android 8.0：隐式广播基本禁掉静态注册

Android 8.0（API 26）是一个分水岭。官方规定：targetSdkVersion 26及以上的应用，在清单文件中静态注册的Receiver，无法再接收大部分隐式广播（即没有明确指定包名、只靠action匹配的广播）。

可以静态注册的隐式广播被列在官方“隐式广播例外列表”中，包括但不限于：

• ACTION_BOOT_COMPLETED
• ACTION_LOCKED_BOOT_COMPLETED
• ACTION_MY_PACKAGE_REPLACED（自己App被覆盖安装）
• ACTION_PACKAGE_FIRST_LAUNCH（包首次安装）
• ACTION_TIMEZONE_CHANGED（时区变化）
• 等等

除了这些例外，其他隐式广播想静态注册，就别指望能收到了。那怎么办？两个思路：

一是把静态注册改成动态注册。如果你的业务场景是应用在运行期间需要关注某个事件，动态注册完全够用。二是发送方显式指定包名，用显式广播来绕过限制。但自己的业务自己可以改发送方，系统广播你是改不了的，所以核心还是靠动态注册。

4.2 Android 14顺势继续收紧后台广播

Android 9（API 28）开始，系统对“后台应用接收网络相关广播”做了限制，比如CONNECTIVITY_ACTION，后台App收不到。到了Android 14（API 34），要求前台服务必须声明具体类型，部分广播的前台启动限制也更严格了。

实际项目中我遇到最多的是这类问题：应用切到后台，网络从Wi-Fi切到4G，再切回来，后台逻辑（比如下载任务、消息推送重连）没有响应。很多团队第一反应是“网络广播收不到”，然后拼命找Receiver的问题，其实根子在于系统限制后台应用接收这类广播。

解决办法通常不是死磕广播，而是换思路：用ConnectivityManager.registerDefaultNetworkCallback()来监听网络状态。这个是系统推荐的替代方案，前台后台都能收到回调，比广播可靠得多。如果你的需求是上网的即时感知，强烈建议优先用NetworkCallback，别在广播这棵树上吊着。

4.3 Android 13起，动态注册必须显式声明Export状态

Android 13（API 33）引入了一个足够让人崩溃的变更：动态注册Receiver时，如果只调用最旧的registerReceiver(receiver, filter)，系统会直接抛SecurityException，原因是缺少RECEIVER_EXPORTED或RECEIVER_NOT_EXPORTED标志。

正确做法是用前面第3节写过的ContextCompat.registerReceiver：

// 只能接收自己App或系统同Uid发来的广播 ContextCompat.registerReceiver(context, receiver, filter, ContextCompat.RECEIVER_NOT_EXPORTED); // 需要接收其他App发来的隐式广播时 ContextCompat.registerReceiver(context, receiver, filter, ContextCompat.RECEIVER_EXPORTED);

这个“导出”的概念，你可以理解成：RECEIVER_NOT_EXPORTED表示这个接收器只对内，外部应用不能给它发广播；RECEIVER_EXPORTED表示对外开放，任何App都能触发它。

我遇到过真实事故：App升级targetSdk到33之后，线上直接大面积崩溃，崩溃栈指向registerReceiver，就是因为在升级时没改调用方式。这里也提醒一下：如果你因为兼容性原因，暂时想忽略这个异常，可以在AndroidManifest.xml里给<application>节点加tools:targetApi="tiramisu"之类的标记，但这不是长久之计，早晚要改代码。新代码从第一天就按API 33的标准写，省得后面重构。

5. 常见问题与排查思路实录

广播这东西，看着简单，出问题的时候最磨人。我把这些年开发中遇到频率最高的几类问题整理了一下，按排查顺序给你一个可以照做的思路。

5.1 收不到广播，按这个顺序查

收不到广播是绝对的高频问题。我现在的排查顺序基本固定了：

1. 先确认发送方和接收方的action字符串完全一致。这个听起来蠢，但实际发生概率真的不低。尤其是当你不小心在IntentFilter里多加了一个空格，或者把常量定义在不同类里改了一个字母，排查起来非常痛苦。建议action常量统一放在一个Constants类里，两侧引用同一份。
2. 确认注册方式在当前Android版本下有效。静态注册的，先看是不是Android 8.0+禁用的隐式广播；动态注册的，确认是在onReceive会被触发的组件生命周期内注册过。
3. 确认接收方组件还活着。动态注册的Receiver，组件销毁了自然收不到；进程被杀，静态注册理论上能拉起来，但厂商ROM的省电策略经常拦截，尤其是那些“一键省电”模式开着的时候。测试时建议先把电池优化白名单排除掉再试。
4. 看有没有权限门槛。发送方用了sendBroadcast(intent, permission)指定权限，接收方没声明对应权限，就会收不到。系统广播里也有这个情况，比如接收BOOT_COMPLETED需要在manifest里声明RECEIVE_BOOT_COMPLETED权限，漏了权限就一切白搭。
5. 确认发送方式匹配。用setPackage或setComponent的显式广播，接收方必须精确匹配包名/组件；隐式广播则要求action匹配，且接收方exported状态对吗？如果接收方是RECEIVER_NOT_EXPORTED，外部App发的隐式广播它收不到，这个也是我排查过的真实案例。

5.2 动态注册重复执行的处理

很多时候广播本身没问题，问题出在一次广播触发了多次onReceive。常见原因有三个：

• 同一个Receiver在Activity的onCreate里注册，但Activity被反复创建（比如屏幕旋转）时没有注销旧的，旧的实例和新的实例都注册了。这个的解决方法是把注册和注销的时机绑死在同一个生命周期回调对里，比如onStart/onStop，别再onCreate里注册却拖到onDestroy才注销。
• 广播发送方自己发了多次广播。比如网络状态变化时你可能连续收到好几条CONNECTIVITY_ACTION，其中一条是Wi-Fi断开的旧状态、一条是新状态。这时候不要盲目“收到就处理一次”，要根据intent里的EXTRA_NO_CONNECTIVITY等附加字段或当前网络状态做去重。
• onReceive里触发了新的sendBroadcast，形成广播风暴。比如A广播触发了一个操作，操作里又发送了B广播，而B又触发A，逻辑把控不好就会出现指数级循环。这种问题不常见，但一旦出现就是灾难级Bug，我建议广播接收器里永远不要直接发广播，要做也给它做一个去重标记。

5.3 onReceive里的时间限制和特殊约束

onReceive是在主线程执行的，系统给它定了硬性时间限制。旧版本是10秒，Android 9之后通常是5到10秒，超过就直接ANR。一旦这里超时，用户会看到“xx应用无响应”的弹窗，口碑瞬间炸掉。

正确姿势：遇到需要联网、读数据库、写文件的场景，要么用goAsync()把工作丢到后台线程，要么先startService启动一个前台服务来处理。goAsync()很多人不熟悉，我放个简单例子：

@Override public void onReceive(Context context, Intent intent) { final PendingResult pendingResult = goAsync(); new Thread(() -> { try { // 在后台线程做耗时操作 processData(); } finally { // 一定要调用finish，否则ANR概率更高 pendingResult.finish(); } }).start(); }

注意：goAsync()不等于无限延时，官方建议最长10秒内必须完成并调用finish()。如果超过10秒的耗时任务，老老实实配合JobScheduler或前台服务使用。

另外要记住，在onReceive里直接startActivity有严格限制，尤其后台状态下启动Activity会被系统拦截（后台Activity启动限制）。Android 10之后系统还会在部分情况下直接禁止从后台广播启动Activity。这是很多老代码迁移到新版本时最常撞上的墙。

5.4 常见问题速查表

6. 别把这几类“广播”搞混了

最后聊一个很容易被忽略的问题：因为搜索热词的关系，很多同学搜“安卓广播”时，会把网络层的“广播”概念也搜出来，然后越看越懵。这里我顺手把几个容易被混在一起的“广播”理清楚。

6.1 网络广播域

“广播域”是网络领域的概念，指的是网络中一组设备的集合，在这组设备里，任何一台设备发出的广播帧，其他设备都能收到。比如家用路由器的局域网，默认就是一个广播域，你用抓包工具能抓到各种DHCP、ARP的广播包。

它和Android广播的共同点是“一对所有的传播模型”，但实现完全不是一个层次：网络广播是链路层/网络层的行为，走的是MAC地址和交换机/路由器的转发逻辑；Android广播是应用层的消息传递机制，走的是AMS的Receiver注册表匹配逻辑。在排查Android设备上的网络问题时，你会同时碰到这两层概念，但别把它们混为一谈。

6.2 单播、多播和广播的区别

这三个词放在一起，在通信领域是说消息的三种发送模式：

• 单播：一对一的通信，就两个人说话，其他人都听不见。
• 多播（组播）：一对多但要对“特定群体”，只有加入这个组的人才能收到。
• 广播：一对所有，整个广播域里所有人都能收到。

Android里的广播，发送面向的是“所有注册了对应action的接收者”，本质上是“多播”或者“广播”的混合体。因为IntentFilter实际上起到的是“分组”的作用。如果你希望像多播那样只给特定群体发消息，Android的显式广播（指定包名/组件）就是最接近的实现方式。

网上很多帖子会拿这三个概念来类比Android广播模式，我觉得能帮你理解，但别过分代入。因为Android的广播没有真正的网络拓扑约束，你在全球任何一台设备上都能给另一台设备（只要注册了）发送隐式广播（当然前提是走系统通道），它不关心设备是不是在同一个网段里。

6.3 BLE广播

蓝牙低功耗（BLE）里的广播，指的是BLE设备以一定周期向外发送广播包，让周围的扫描设备发现自己。这是BLE连接建立之前的一种物理层行为。

为什么我特意提它？因为做物联网、智能硬件项目的Android开发，经常要同时处理BLE广播和Android系统广播两件事。你可能会写一个接收BluetoothDevice.ACTION_FOUND的系统广播来发现设备，同时又要配置BLE广播参数来做外设端广播。一个走的是Android系统的Receiver机制，一个是蓝牙协议栈的广播信道行为，完全两回事。如果你这块容易混，记住一点：Android广播是“应用层的消息事件”，BLE广播是“物理层的射频信号”。一个是软件，一个是硬件，中间差了整整一个协议栈。

最后再分享个我自己的小体会：广播这套机制，从技术形式上可以说“过时”了，官方也在不断收紧它的使用场景，推动你转向更安全的替代方案。但你在老项目里维护代码时，它依然无处不在，而且广播里“事件发布与订阅”的思想，在今天主流的LiveData、Flow、Kotlin协程这些新方案里依然清晰可见。所以哪怕你未来很长一段时间不写广播，也值得把广播类别和注册机制这些底层逻辑搞清楚。基础扎实了，回头看各种新框架，你会发现很多设计都是同一个套路换了个壳而已。