企业官网建设流程全解析

1. 广播的动态注册：一次系统级别的“订阅通知”

做Android开发的人，对广播（Broadcast）这套机制应该都不陌生。它是四大组件里最“轻量”的一个，用来在应用内部、应用之间、甚至系统和应用之间传递消息。很多刚接触的同学会把广播想得很简单——注册一下、发一下、收一下，完事。但真正深入到源码层面，你会发现广播的动态注册过程，其实是整个Android消息体系里最绕、也最有代表性的一个环节，中间牵扯到Binder跨进程通信、AMS（ActivityManagerService）端的复杂数据结构、进程内Handler的消息调度，以及一套独特的生命周期管理。把这套流程吃透，你对Android framework的整体理解会上一个台阶，以后再遇到广播收不到、泄漏、ANR这类问题，排查起来会从容得多。

这篇文章我打算从动态注册这条主线展开，一步步拆解从应用层调用registerReceiver开始，到AMS完成注册、再到后续广播分发和反注册的完整链路。过程中我会补充大量源码分析和实操经验，正好覆盖“为什么要这样设计”“遇到问题怎么排查”这些常规文档里不会细讲的东西。

先说清楚这篇文章适合谁看。如果你是一个刚接触Android源码的开发者，或者工作中经常处理广播相关问题但是总觉得隔着一层纱，这篇文章可以当作一条索引，帮你把零散的源码片段串成一条完整的链路。如果你已经是有经验的工程师，那重点可以放在后半部分的源码细节和踩坑经验上，相信也能带来一些新的视角。

2. 广播机制整体设计与动态注册的定位

2.1 广播的三种“打开方式”与设计哲学

Android的广播一共有三种玩法：标准广播（Normal Broadcast）、有序广播（Ordered Broadcast）和本地广播（Local Broadcast，现在推荐用LiveData或者Flow替代）。标准广播是异步的、无序的，发出去之后所有匹配的接收者都能收到，彼此之间没有先后概念。有序广播则是同步的，按照优先级一个个往下传，中途还可以被截断，典型的场景是短信拦截这类需求。

但无论哪种广播，接收者的注册方式都只有两种：静态注册和动态注册。静态注册是写在AndroidManifest.xml里的<receiver>标签，由系统在安装应用时就解析好，应用不启动也能收到广播。动态注册是在代码里通过Context.registerReceiver()来注册，必须等应用进程跑起来才能收到广播。

从设计哲学上看，广播机制本质上就是一个进程间（或进程内）的发布-订阅模型。系统进程（AMS）扮演消息中枢的角色，保存所有的注册信息，负责匹配和分发。应用进程则通过Binder与AMS通信，完成订阅和退订。理解了这一层，后面看代码就有方向了——你只需要顺着“应用进程怎么把订阅信息交给AMS、AMS怎么存、匹配到之后怎么回传”这条主线走。

2.2 为什么动态注册在实践中的存在感更强

虽然静态注册看起来更方便——不用写代码，manifest里配一下就行——但在实际开发中，动态注册的使用频率反而更高，原因有几个。

第一，从Android 8.0（API 26）开始，系统对静态注册的隐式广播做了大量限制。除了少数系统广播（比如开机广播、网络变化、电量变化等）之外，大量的自定义隐式广播已经不能在manifest里静态注册了，因为静态注册收不到。这是一个很大的政策转变，逼着开发者转向动态注册。

第二，动态注册的生命周期是可控的。它跟随组件的生命周期，你在onCreate里注册、onDestroy里反注册，整个生命周期收放自如，不会出现“注册了却不知道什么时候会被拉起”的问题。而静态注册的广播接收者，系统可以在任意时刻通过handleReceiver把进程拉起来执行onReceive，这对内存和电量都不太友好，也容易在不知不觉中占用系统资源。

第三，从调试和维护的角度看，动态注册的逻辑写在代码里，调用链清晰，出问题了可以用IDE的调试器直接打断点，定位效率高得多。静态注册的调用过程绕经过系统解析和拉起流程，调试起来反而更麻烦。

2.3 动态注册的完整链路概览

在深入源码之前，我先把动态注册的链路大致画出来。整个过程可以分成以下几个阶段：

• 应用进程调用Context.registerReceiver()，创建ReceiverDispatcher和InnerReceiver（Binder对象）。
• 通过Binder跨进程调用AMS的registerReceiverWithFeature()方法，把接收者信息、IntentFilter、权限等传给系统进程。
• AMS在内部数据结构和ReceiverResolver中保存注册信息，完成“订阅登记”。
• 后续有广播发出时，AMS的BroadcastQueue根据Intent匹配接收者，找到对应的InnerReceiver代理，通过Binder回调应用进程。
• 应用进程的InnerReceiver收到回调后，通过ReceiverDispatcher内部持有的Handler把onReceive投递到主线程执行。

这个链路中，注册只是第一步。后面分发流程还涉及很多细节，比如ReceiverRecord的状态机、BroadcastQueue的调度逻辑。不过别急，我会在后面的章节里把每一段都拆开讲清楚。

3. 从一行registerReceiver开始：应用层到底做了什么

3.1 ContextImpl.registerReceiverInternal：动态注册的真正入口

当你在Activity里写下registerReceiver(receiver, filter)时，最终会走到ContextImpl.registerReceiverInternal()这个方法。它是动态注册在应用进程的真正入口点。为什么不是直接走到registerReceiver的重载方法？因为ContextWrapper会先做一层转发，把调用委托给内部的mBase（也就是ContextImpl实例）处理。这层封装很容易被忽略，但在追踪源码时得记住：Activity自身并不实现注册逻辑，它只是一个壳。

registerReceiverInternal的核心代码如下（简化版）：

private Intent registerReceiverInternal(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheduler, Context context, int flags) { IIntentReceiver rd = null; if (receiver != null) { if (mPackageInfo != null && context != null) { if (scheduler == null) { scheduler = mMainThread.getHandler(); } rd = mPackageInfo.getReceiverDispatcher(receiver, context, scheduler, mMainThread.getInstrumentation(), true); } else { rd = new LoadedApk.ReceiverDispatcher(receiver, context, scheduler, mMainThread.getInstrumentation(), true).getIIntentReceiver(); } } try { final Intent intent = ActivityManager.getService().registerReceiverWithFeature( mMainThread.getApplicationThread(), mBasePackageName, getAttributionTag(), mRemoteToken, receiver != null ? rd.asBinder() : null, filter, broadcastPermission, userId, flags); return intent; } catch (RemoteException e) { throw e.rethrowFromSystemServer(); } }

这里面有几件事值得注意。

第一，如果传入了scheduler参数（也就是Handler），系统会优先使用它来调度onReceive；如果把scheduler留空，则默认使用主线程的Handler（mMainThread.getHandler()）。这就是为什么动态注册的广播接收者默认跑在主线程。如果你想在子线程收广播，就必须在重载版本里主动传入一个子线程的Handler。这一点很多人踩过坑，我记得有个用HandlerThread做后台任务的朋友，因为忘了传Handler，结果onReceive里的耗时操作直接卡了主线程，引发了ANR。

第二，代码里通过mPackageInfo.getReceiverDispatcher()获取了一个IIntentReceiver类型的Binder对象rd。这里面的mPackageInfo是LoadedApk的实例，它内部维护了一个ReceiverDispatcher的缓存机制。这个“把BroadcastReceiver包装成Binder对象”的步骤是整个动态注册的核心，我会在下一个章节单独拆解。

3.2 LoadedApk.ReceiverDispatcher：接收者的“Binder壳”

在Android的多进程模型里，AMS运行在system_server进程，你的应用跑在自己的进程里。AMS要回调你的广播接收者，不可能直接拿着一个Java对象引用跨进程调用，所以必须通过Binder。ReceiverDispatcher就是干这个事情的：它把一个普通的BroadcastReceiver对象包装成可以跨进程调用的IIntentReceiver接口。

这里的IIntentReceiver是一个AIDL接口，它在应用进程的实现在InnerReceiver这个内部类中。InnerReceiver本身是一个Binder对象，AMS拿到的是它的代理端（也就是IIntentReceiver.Stub.asInterface()转换出来的对象）。当AMS需要发送广播时，它实际上是在调用这个代理的performReceive方法，通过Binder驱动把调用请求发送到应用进程，最终由InnerReceiver处理。

我来展示一下InnerReceiver的简化代码：

static final class InnerReceiver extends IIntentReceiver.Stub { final WeakReference<LoadedApk.ReceiverDispatcher> mDispatcher; final LoadedApk.ReceiverDispatcher mStrongRef; @Override public void performReceive(Intent intent, int resultCode, String data, Bundle extras, boolean ordered, boolean sticky, int sendingUser) { final LoadedApk.ReceiverDispatcher rd; if (intent == null) { rd = null; } else { rd = mDispatcher.get(); } if (rd != null) { rd.performReceive(intent, resultCode, data, extras, ordered, sticky, sendingUser); } else { IActivityManager mgr = ActivityManager.getService(); try { if (extras != null) { extras.setAllowFds(false); } mgr.finishReceiver(this, resultCode, data, extras, false, true); } catch (RemoteException ex) { throw ex.rethrowFromSystemServer(); } } } }

从代码里可以看到，InnerReceiver持有一个ReceiverDispatcher的弱引用（WeakReference），而不是强引用。这是一个很有意思的设计细节。为什么不用强引用？因为InnerReceiver是系统进程持有的Binder对象，如果它强引用ReceiverDispatcher，而ReceiverDispatcher又通过mReceiver引用着BroadcastReceiver，同时BroadcastReceiver又可能被外部注册者引用着，就会形成一条无法回收的引用链，容易导致内存泄漏。使用弱引用的话，如果应用侧的接收者已经不再被使用，垃圾回收时就可以把ReceiverDispatcher回收掉，InnerReceiver也就变成了一个空壳。

但这里还有一个mStrongRef字段，它是ReceiverDispatcher的强引用。这个字段平时是null的，只有在特定的“有序广播”场景下才被临时赋值，确保在极短的跨进程投递过程中接收者不会被GC回收。这就是一个典型的“用时创建、用完释放”的临时强引用技巧，对理解Binder对象跨进程传输时的生命周期管理很有帮助。

3.3 getReceiverDispatcher与缓存机制

LoadedApk内部维护了一个HashMap，用来缓存ReceiverDispatcher。缓存的key是一对组合：BroadcastReceiver对象和Context对象。这是为了确保同一个BroadcastReceiver在同一个Context下多次注册时，复用同一个ReceiverDispatcher和InnerReceiver。如果每次都新建，那AMS端会积累大量重复的Binder对象，不仅浪费资源，还会导致广播重复投递的问题。

这个缓存的另一个作用，是为后续的unregisterReceiver服务。反注册时，系统需要根据BroadcastReceiver找到对应的InnerReceiver，然后告诉AMS移除该Binder对应的所有记录。如果没有缓存，连查找都没法做。

缓存实现的核心代码大致是这样的（经简化）：

public IIntentReceiver getReceiverDispatcher(BroadcastReceiver r, Context context, Handler handler, Instrumentation instrumentation, boolean registered) { synchronized (mReceivers) { LoadedApk.ReceiverDispatcher rd = null; ArrayMap<BroadcastReceiver, LoadedApk.ReceiverDispatcher> map = null; if (registered) { map = mReceivers.get(context); if (map != null) { rd = map.get(r); } } if (rd == null) { rd = new ReceiverDispatcher(r, context, handler, instrumentation, registered); if (registered) { if (map == null) { map = new ArrayMap<>(); mReceivers.put(context, map); } map.put(r, rd); } } return rd.getIIntentReceiver(); } }

注意这里mReceivers的类型是ArrayMap<Context, ArrayMap<BroadcastReceiver, ReceiverDispatcher>>——外层以Context为key，内层以BroadcastReceiver为key。为什么要套两层？是因为同一个BroadcastReceiver对象可以在不同的Context下注册（比如同一个Activity实例和同一个Application实例），它们的调度Handler和生命周期语境不同，需要区分开来。

顺便说一句，很多泄漏问题的根源就在这个缓存里。如果你在Activity中注册了广播，但在onDestroy时没有反注册，那么Activity对象会一直被ReceiverDispatcher引用着（因为ReceiverDispatcher内部持有Context的引用），就算Activity已经销毁，垃圾回收也没法回收它，最终造成内存泄漏。Logcat里通常会打印Activity has leaked IntentReceiver这种提示，这实际上就是系统在帮你做了一次“泄漏体检”。这个坑我真的见过太多次了，后面我会在专门的问题排查章节里详细讲。

4. 核心幕后：AMS端的分发与注册处理流程

4.1 AMS.registerReceiverWithFeature：注册流程的服务端实现

应用进程打包好InnerReceiver之后，通过ActivityManager.getService().registerReceiverWithFeature()发起跨进程调用。这个ActivityManager.getService()拿到的是ActivityManagerProxy，它在Binder驱动里找到AMS的system_server进程，把调用请求投递过去，最终执行到AMS的registerReceiverWithFeature()方法。

我来梳理一下这个方法的服务端逻辑。它做的事情主要包括：

• 解析调用者身份：确认是哪个应用、哪个进程在注册。
• 处理调用者的进程状态：如果需要的话，先把进程调度到前台，确保它能被拉起。
• 如果receiver参数非空（也就是InnerReceiver的Binder代理），解析出它的ReceiverList。
• 把IntentFilter和对应的接收者插入ReceiverResolver，为后续的广播匹配做准备。
• 调用broadcastQueue或者mStickyController处理粘性广播。

这里涉及到的核心数据结构有两个：ReceiverList和ReceiverResolver。

ReceiverList可以理解成一个“接收者身份证表”，它记录了某个Binder接收者（IIntentReceiver）注册的所有IntentFilter信息，以及它所属的进程。同一个InnerReceiver可以被同一个进程多次注册不同的IntentFilter，所以ReceiverList里有一个List<IntentFilter>的成员变量filter。

ReceiverResolver则是IntentResolver的子类，专门用于广播IntentFilter的匹配。它内部使用了一个HashMap<String, ArrayList<IntentFilter>>，键是Intent的action字符串，值是匹配该action的所有IntentFilter列表。这样在广播发送时，系统可以根据action直接定位到候选的Filter列表，再进一步做类型和数据的匹配，实现非常高效的检索。

registerReceiverWithFeature中间有一段比较关键的处理逻辑，就是register过程的权限校验和“sticky广播”的即时应答。你可能遇到过一种情况：我先发送一个广播，然后才去注册接收者，按理说应该收不到，但如果发送的广播是通过sendStickyBroadcast发送的，那么注册时系统会立刻把最近一次的这个粘性广播补发给新注册者。这就是为什么粘性广播在源码里会在注册阶段就做匹配返回。

4.2 registerReceiver调用细节：“先查后插”的双保险策略

AMS的注册流程并不是直接拿到IntentFilter就插入数据结构了，而是先做一轮查询。这个查询的目的，是检查当前是否有粘性广播能匹配这个新注册的IntentFilter。如果匹配到了，就把这个粘性广播的Intent直接作为返回值传给调用方，让应用进程可以在注册的同时就收到一次“迟到”的广播。

这轮查询的核心代码逻辑大致如下：

if (intentFilter != null && receiver != null) { // 检查当前是否有匹配的粘性广播，如果有则加入队列等待分发 ... }

这里有个小细节值得注意：插入Resolver使用的是mRegisteredReceivers这个Map，但真正实现匹配效率的，还是mReceiverResolver这个Resolver。注册时，AMS拿到ReceiverList后，会把里面的每个IntentFilter都插入mReceiverResolver中，形成以action为索引的查找结构。

所以整个AMS注册过程，可以理解为“先在登记簿上写名字，再把你的联系方式挂到对应频道下”。前者是顺序遍历查找用的，后者是广播分发时快速定位用的。一套数据，两种组织方式，各司其职，这是系统设计的巧妙之处。

4.3 matcher机制与动态注册中的过滤逻辑

注册信息进了ReceiverResolver之后，是不是就万事大吉了？并不是。接下来还有一层匹配逻辑在等着它。广播发送时，AMS会用发送广播的Intent去和所有注册的IntentFilter做匹配，这个过程通过IntentResolver.queryIntent()实现。

queryIntent的匹配规则很细，具体来说有以下几个层次：

• action必须匹配。
• data的scheme、host、port、path必须匹配（如果IntentFilter里指定了的话）。
• type（MIME类型）必须匹配。
• category匹配（像CATEGORY_DEFAULT这种，在广播中一般不会涉及太多）。
• 如果发送广播时指定了包名，那么接收者的包名必须和发送者指定的包名一致。

这里容易出错的是data匹配。我记得有个同事自定义了一个广播，在filter里写了<data android:scheme="https"/>，结果发送广播时只是new Intent(action)后再setData(Uri.parse("http://..."))，就无论如何都收不到。折腾了半天才发现是scheme不一致导致的。这在动态注册里同样存在，特别是用addDataScheme和addDataType方法时，要格外小心。

匹配产生结果之后，AMS会把匹配到的所有接收者（ReceiverList）批量加入广播分发队列。这里面还有一层性能优化：如果接收者的进程正在运行，就直接加入分发队列；如果进程没运行，可能就需要先拉起进程再分发。动态注册的接收者因为进程一定是在运行的，所以不会出现拉起进程的情况，这也是动态注册比静态注册更轻量的原因之一。

4.4 动态注册过程中的AppOps与权限校验

权限校验在动态注册过程中也是一个隐藏的坎。AMS会检查注册者是否有权限接收指定广播，以及是否有权限发送广播。具体有两种情况：

第一种是发送者声明了发送权限（sendBroadcast(intent, permission)），那么接收者必须在注册时指定能接收带该权限的广播，否则广播不会递给它。这个权限检查是在匹配和分发阶段做的，注册阶段不会报错，但后续广播收不到。

第二种是接收者声明了接收权限（registerReceiver(receiver, filter, broadcastPermission, null)），那么发送者在发送广播时必须持有这个权限，否则接收者收不到广播。

很多开发者会忽略这两种权限差异，导致“明明注册了、也匹配了，就是收不到”。我的经验是，遇到这种情况先检查一下有没有权限问题。你可以在日志里搜一下AMS打印的Permission Denial相关tag，很快就能定位。

5. 注册后的世界：一条广播的完整通路

5.1 广播发送：从sendBroadcast到AMS的IntentResolver

说完了注册，我们再来看一条广播从发送到被动态注册接收者收到，中间经历了什么。

当你调用sendBroadcast(intent)时，最终会通过ActivityManager.getService().broadcastIntentWithFeature()进入AMS的broadcastIntentLocked()方法。这个方法做的事情非常核心：

• 添加FLAG_EXCLUDE_STOPPED_PACKAGES等标记，默认不投递给已停止的应用。
• 从mReceiverResolver中查询匹配的接收者列表。
• 整理出接收者集合后，交给BroadcastQueue调度发送。

BroadcastQueue是系统进程里专门负责广播分发调度的类，它内部有一系列的队列和状态，用来管理广播在系统进程和各个应用进程之间传递的时序。动态注册的广播接收者正常情况下都在system_server这边的“first receivers”队列里排队。

这里有一个知识点值得补充：对于动态注册的接收者，AMS在匹配之后会调用BroadcastQueue.scheduleBroadcastsLocked()，然后通过BroadcastHandler发送一个BROADCAST_INTENT_MSG消息，进入异步分发流程。注意，broadcastIntentLocked本身是在处理Binder调用的binder线程上执行的，而分发是在BroadcastHandler绑定的线程中执行的，做了线程切换。这也是为什么广播的分发是异步的——系统先把广播入队，再通过Handler机制逐条取出分发，这个过程本身是异步的。

5.2 从排队到回调：BroadcastQueue中的动态接收者何时被送达

广播进入BroadcastQueue之后，里面就开始了一系列的状态流转。每个接收者被包装成BroadcastRecord里的ReceiverRecord，ReceiverRecord可能处于多种状态：IDLE、APP_RECEIVE、CALL_DONE_RECEIVE等。分发时，系统会从队列中取出当前排在最前面的广播记录，然后逐个调用deliverToRegisteredReceiverLocked()来处理动态注册的接收者。

deliverToRegisteredReceiverLocked这个方法会做几件事：先检查接收者的进程是否存活，如果存活则直接把BroadcastRecord和ReceiverRecord传入processCurBroadcastLocked，最终调用performReceiveLocked，通过receiver（也就是IIntentReceiver的Binder代理）调用performReceive方法。

到这里，一条广播的“系统进程到应用进程”跨进程传输就完成了。performReceive的Binder调用会在应用进程的Binder线程池中被InnerReceiver接收，然后走我们之前提到的ReceiverDispatcher.performReceive。

5.3 performReceive到onReceive：主线程如何被安全调度

在应用进程这一侧，InnerReceiver.performReceive最终会调用ReceiverDispatcher.performReceive，然后通过内部的ArgsRunnable把这个任务提交给调度Handler。这里有一个重要的分发逻辑，我来对比一下不同Handler下的行为差异：

• 如果调度Handler是主线程Handler，那么Args.run()会在主线程执行，最终触发onReceive。这是最常见的情况。
• 如果注册时传入了子线程Handler，那么onReceive就会在子线程执行。这时你必须自己保证线程安全，不能直接操作UI。

performReceive的代码逻辑大致如下：

public void performReceive(Intent intent, int resultCode, String data, Bundle extras, boolean ordered, boolean sticky, int sendingUser) { final Args args = new Args(intent, resultCode, data, extras, ordered, sticky, sendingUser); if (intent == null) { ... } else { ... } if (intent == null || !mActivityThread.post(args.getRunnable())) { if (mRegistered) { ... } else { ... } } }

这个Args对象的getRunnable()返回的是一个包装后的Runnable，最终的run()方法里面做了几件重要的事：反序列化Intent的Extras（因为Binder传输可能会丢失一些类型信息）、调用receiver.onReceive()、处理有序广播的setResult系列方法、最后执行finishReceiver回调告诉AMS“我已经处理完这个广播了”。

这里我想强调一下finishReceiver的重要性。动态注册的广播接收者如果在onReceive里抛出异常，会导致finishReceiver没有被调用，AMS那边会认为广播还在处理中，影响后续有序广播的调度。你可以通过Looper.getMainLooper().setUncaughtExceptionHandler来捕获主线程异常，或者在onReceive里加一个兜底的try/catch/finally来确保流程不被中断。

5.4 生命周期细节：为什么动态注册的广播默认在处理完就结束

与静态注册不同，动态注册的广播接收者的生命周期非常短暂。onReceive执行完之后，这个“接收周期”就结束了。下一次再有匹配的广播，系统会重新通过InnerReceiver回调过来，可能还是在同一个ReceiverDispatcher上，但每次的Args任务都是新的。

这意味着onReceive不能当作一个长时任务来用。如果你在onReceive里启动了一个线程去做耗时操作，而这个线程持有Context引用，那么即使接收者已经被反注册，这个Context仍然可能被线程强引用，造成泄漏。更合理的做法是在onReceive里只做轻量级的数据传递，真正耗时的任务交给WorkManager或者goAsync()来异步处理。

提到goAsync()，这是Android 7.0之后提供的一个特性，它可以让onReceive在返回后仍然保持广播的激活状态，把耗时逻辑放到异步线程里执行，等异步任务完成后再调用PendingResult.finish()。这个功能在动态注册接收者中同样适用，但很多开发者在动态注册里都不用它，其实这是一个很大的浪费，遇到需要处理较多数据的场景，goAsync()比开线程更规范。

6. 反注册机制与动态注册的完整闭环

6.1 unregisterReceiver：反注册的一连串“清扫”动作

有注册就有反注册。动态注册的收尾动作是调用unregisterReceiver(receiver)，它同样通过ContextImpl最终调用AMS的unregisterReceiver()方法。

应用进程这一侧，unregisterReceiver会先根据BroadcastReceiver对象，从LoadedApk的缓存中取出对应的ReceiverDispatcher，然后从缓存中移除映射关系，再把IIntentReceiver的Binder句柄传给AMS。AMS收到请求后，会做以下几件事：

• 从mRegisteredReceivers中移除该InnerReceiver对应的ReceiverList。
• 从mReceiverResolver中移除该ReceiverList里所有IntentFilter对应的注册信息。
• 清理ReceiverList中持有的进程引用，如果有必要的话，调整进程的调度状态。

一个细节是，unregisterReceiver之后，AMS可能还会根据该进程是否还有其他活跃组件来决定是否降低进程的优先级。动态注册的广播接收者本身不会让进程保持在前台，所以它反注册后，进程可能很快就处于可被杀死的状态了——前提是没有其他后台组件在撑住它。

6.2 反向反射机制：BroadcastReceiver.onReceive与Activity生命周期的隔离

动态注册的广播接收者与Activity生命周期是“隔离”的，这一点很多人没有深刻认识到。注册和反注册是你在代码里手动控制的，但onReceive的调用时机并不与Activity的状态绑定。如果你在onResume里注册、onPause里反注册，那么onPause之后广播就不会再触达你的接收者了。这种模式适合那些只关心界面在前台时状态的场景，比如前台时的网络状态监听。

但更常见的做法是onCreate注册、onDestroy反注册，确保屏幕旋转等配置变更不会导致重复注册。我建议根据业务需求明确选择生命周期绑定方式，不要盲目照搬某一个模板。否则你会遇到“切到后台之后收不到广播”“屏幕旋转后收到两次广播”这类问题。

6.3 常见反注册问题的排查思路

反注册过程虽然不复杂，但实际开发中问题不少。我来总结几个常见场景：

• “重复反注册导致崩溃”：unregisterReceiver在接收者已经被反注册过的场景下会抛出IllegalArgumentException: Receiver not registered异常。出现这个异常，一般意味着你的注册和反注册没有对称配对。推荐写一个工具类来封装注册和反注册逻辑，保证配对。
• “忘记反注册导致泄漏”：之前章节提过，Activity销毁后没有反注册，日志会提示Activity has leaked IntentReceiver。这种问题可能不会立刻导致崩溃，但长时间运行后内存会增长。
• “进程被杀后恢复导致的重复注册”：如果应用进程被系统杀死，而你在onCreate里又注册了一遍，此时LoadedApk里的缓存是全新的，AMS端也没有历史注册信息，正常情况下没有问题。但如果你的代码在进程被杀死前没有正常反注册（比如onDestroy没执行就被杀），重新注册后会多一条记录吗？不会，因为进程死了，AMS端的Binder对象也就失效了，系统会做一次清理。

7. 实战踩坑与性能优化：动态注册的那些“潜规则”

7.1 高频注册与重复投递：缓存为何还是不够

注册、反注册本身开销不小，因为它涉及到两次Binder调用。如果某段代码被频繁调用，比如在onResume里注册、在onPause里反注册，且两个生命周期切换频率很高，那么Binder调用的次数会非常可观。在性能敏感的页面里，这可能引起不必要的线程调度和系统负载。

我的建议是：如果广播的注册确实需要跟随页面可见性状态，可以考虑用onStart/onStop替代onResume/onPause，或者用LiveData配合LifecycleService来减少注册频次。系统事件（比如网络变化）类型的广播，通常是全局性的，注册频次越高，浪费越严重，这种情况下更适合用ApplicationContext注册，让生命周期跨过整个应用。

7.2 广播接收顺序：动态注册之间的优先级关系

有序广播里，动态注册接收者之间也是有顺序的。registerReceiver(receiver, filter)时，如果使用filter.setPriority()设置了优先级，那么高优先级的接收者会先收到广播。但这只对有序广播（sendOrderedBroadcast）有效，标准广播本身没有顺序概念，优先级自然也就没有意义。

这里有一个很少被提到的细节：动态注册和静态注册的优先级比较规则。当同时存在动态注册接收者和静态注册接收者时，动态注册的接收者默认优先级会比较高，因为它的ReceiverList在AMS的“first receivers”列表里排得更靠前。只有静态注册的接收者优先级特别高时（比如android:priority="999"这种），才可能跑到动态接收者前面。

7.3 系统性广播的动态注册限制（Android 14的行为变化）

Android 14（API 34）对动态注册的广播接收者也做了一些调整，主要是关于接收设备状态的导出限制。具体来说，如果你的应用以Android 14为目标平台，并且动态注册了一个接收开机完成或者某些特殊系统广播的接收者，有些广播会要求你的应用声明特定的权限，否则注册时会抛SecurityException。

这个变化对老项目的冲击很大。我见过不少项目在升级targetSdk后，开机广播的接收者突然失灵，实际上就是因为注册时的权限校验变严格了。解决方法是升级前先查一下官方文档的“广播限制”章节，逐条对一下你的注册列表，把所有涉及敏感系统事件的filter都加上对应权限。

7.4 注册时机的性能优化与“发送后注册收不到”问题

最后再说一个常见的业务问题：我先sendBroadcast，后registerReceiver，为什么收不到？这个问题的答案其实很简单——广播是一种“即时投递”，不是“持久化消息”。发送时AMS去匹配当前已注册的接收者，如果接收者还没注册，那这条广播自然就不会补发（除非是粘性广播）。粘性广播在注册时会补发，但它在Android 13上已经被标记废弃了，不建议新代码使用。

这类问题的排查思路就一条：确认发送广播时接收者是否已经注册完成。注意“注册完成”和“registerReceiver返回”不是一回事，前者是AMS已经保存了注册信息，后者只是应用进程等待Binder调用返回。不过实际场景中，这两者基本处于同一时刻，不会有明显的窗口时间，所以不用担心这个细节。真正需要注意的是，如果你在Application.onCreate里发送广播，而某个Activity里的动态注册还没执行，那这个Activity是肯定收不到这条广播的。正确的做法是延迟发送，或者改用消息总线，让订阅方注册时主动拉取一次“最新状态”。

8. 从一次线上问题看动态注册的完整排查思路

8.1 问题描述与初步定位

年前我们遇到过一个问题：某个版本的App上线后，线上反馈“设备解绑后收不到任何回调广播”，而代码里明明在onCreate里注册了接收者，onReceive里的逻辑也写得很完整。

我当时的第一反应是检查动态注册的代码有没有被执行。通过日志确认，registerReceiver确实被调用了，IntentFilter的action也确实是约定好的。这排除了最基础的“代码没走到”的可能。

接下来，我怀疑是不是AMS没有把广播发过来。为了验证，我在广播发送端加了日志，确认发送端的sendBroadcast也执行了。那么问题就锁定在匹配环节。

8.2 深挖匹配失败的原因

我写了一个临时页面，把注册时用的IntentFilter和发送时用的Intent全部打出来对比，最终发现了问题：发送端在Intent上设置了setPackage("com.xxx.packageName")，而接收端动态注册的IntentFilter里没有对应的包名限定，按理说应该能收啊？后来仔细看了文档才发现，当发送端setPackage指定了包名后，AMS只投递给那一个包名下的、已注册的接收者。我们的业务场景里，sendBroadcast在服务端（另一个进程）执行，它设置的包名指向的是另一个模块，而接收端的模块包名和它不一致，广播自然就没送达。

这个问题的根源不是动态注册本身，而是匹配规则的使用不当。但它提醒了我一个事情：动态注册的广播，调试时不能只看“注册了、发送了”，还要把IntentFilter的所有属性（action、scheme、type、package）都核对一遍。

8.3 如何用Binder日志和dumpsys辅助定位

对于更复杂的广播问题，我通常会配合系统命令来辅助定位。adb shell dumpsys activity broadcasts是一个很强大的命令，它能列出当前所有已注册的广播接收者、每个广播的排队状态和处理进度。

具体用法是这样的：先复现问题，然后在命令行执行adb shell dumpsys activity broadcasts > broadcasts.txt，导出日志后搜索你的包名，看看有没有对应的ReceiverList记录。如果找到了，说明注册信息确实存在于AMS中，问题出在匹配或发送端；如果没找到，说明应用侧的注册可能已经失效，下次注册可能是用了不同的Context或接收者实例。

另外，打开Binder日志也可以看到跨进程调用的记录。adb shell settings put global enable_binder_logging true之后，系统会输出大量Binder调用日志，虽然噪音很大，但你能看到registerReceiverWithFeature和broadcastIntent这些函数是否被调用、参数是什么。这个方法比较高级，适合钻研型开发者，一般排查到dumpsys级别就够了。

9. 动态注册的框架演进与设计参考

9.1 为什么动态注册能延续这么多年

从Android 1.0到现在的Android 15，动态广播注册机制的核心架构几乎没有变。这和它的设计精巧度有关：应用进程用Binder注册、AMS统一匹配、BroadcastQueue统一调度，整个模型清晰、扩展性好。即便后来加了WorkManager、LiveData这些新组件，也没有撼动广播这一层的基础地位。

这种“稳定性”其实是很值钱的。它意味着你在网上找到的很多老文章、老代码，只要没有用到被废弃的API，放到现在的系统上依然能跑。作为开发者，深入掌握这些基础机制的收益是长期的。

9.2 与Jetpack新组件的对比：何时选广播、何时选LiveData/Flow

不过也得客观说一句：动态广播注册并不是万能的。它在某些场景下比较“笨重”，比如本地消息传递、UI状态同步，这些场景用LiveData或者Flow更轻、更安全。我的原则是：跨应用通信、系统事件监听，优先选广播；同一个应用内的模块通信，优先选LiveData/Flow；同一进程的UI层事件，连这些都不用，直接回调更高效。

我有一次重构一个旧模块时，把几十处动态注册的本地广播全部换成了LiveData，包体积虽然没怎么变，但内存占用下降了很多，而且那些“收不到广播”的诡异问题也消失了。原因很简单，LiveData在注册时有生命周期感知，不会出现“Activity销毁后还收消息”的情况。

9.3 从动态注册看Android系统设计的通用模式

最后再说一点更有延展性的思考。动态广播注册的整套流程，是Android系统设计模式的一个缩影。你会在别的地方反复看到类似的结构：应用进程持有一个Binder对象，系统进程保存详细的注册信息，通过某种高效的索引结构做匹配，再通过Binder回调完成通信。ServiceConnection、ContentObserver、KeyguardUpdateMonitor，本质上都是这个套路。

所以如果你把动态注册的链路彻底搞明白了，再去看Android的其他机制，会感觉“怎么都是这一套”——因为它们的骨架是一致的。这也是为什么我强烈建议Android开发者在学习framework时，先从广播机制入手。它是一个足够复杂、又足够有代表性的话题，吃透了它，就等于给整个framework学习打了一个坚实地基。