解读

国内面试场景下，这道题几乎必问，但面试官真正想听的不是“一个在 Manifest 一个在代码”，而是：

1. 两种注册方式对应用生命周期、内存、安全、保活、合规的影响；
2. 能否结合国产 ROM 的“对齐唤醒”“自启动”限制、工信部 24 个月下架规则、Google Play 后台启动限制给出实战结论；
3. 能否在 Compose+Kotlin 时代给出“该用谁、不该用谁”的明确判断。 答得太浅会被追问“那静态广播怎么保活”，答得太深又容易把 Binder 驱动搬出来，必须踩住“系统行为差异 + 国内合规 + 性能”这三条线。

知识点

1. 注册位置：静态在 AndroidManifest.xml，动态在 Context.registerReceiver()。
2. 生效区间：静态随系统开机即存在，与组件生命周期无关；动态与注册者（Activity/Service/Application）同生共死。
3. 进程状态：静态广播可拉活空进程（国内 ROM 已限制），动态广播只能给已运行进程投递。
4. 安全限制：
   • 静态广播 Android 8.0 以后无法接收大部分隐式广播（targetSdk≥26 时），国产 ROM 直接屏蔽；
   • 动态广播只要注册时未加 Intent.FLAG_RECEIVER_EXCLUDE_BACKGROUND 就能收到，但 Android 12 引入“后台启动限制”，需要 START_ACTIVITIES_FROM_BACKGROUND 权限或前台服务。
5. 电量与合规：静态广播被系统统一调度，易触发“对齐唤醒”；动态广播随注册者销毁而注销，工信部检测不到“后台持续监听”风险。
6. 典型保活误区：国内旧代码用静态监听 BOOT_COMPLETED、TIME_TICK、CONNECTIVITY_CHANGE 保活，现已被系统/厂商拦截，属于下架高危。
7. 性能差异：静态广播由 AMS 遍历清单，匹配过程在系统进程；动态广播在进程内维护 ReceiverDispatcher，匹配在注册方进程，减少一次 IPC，但依赖注册方存活。
8. 热修复与插件化：静态广播在清单中声明，热修复框架无法动态增删；动态广播可在运行时按需注册，利于插件化下发。

答案

一句话结论：静态注册在 AndroidManifest.xml 中声明，由系统在应用未运行时即可派发，但受 Android 8.0 隐式广播限制及国内 ROM 保活策略影响，已不推荐用于普通业务；动态注册在代码中调用 registerReceiver()，生命周期与注册者绑定，可精确控制注册/注销时机，是官方推荐的主流方式，同时能规避工信部“后台自启动”检测与 Google Play 后台启动限制。

展开四点：

1. 生命周期：静态广播与进程解耦，可触发应用启动；动态广播必须进程已运行。
2. 系统限制：静态广播 targetSdk≥26 时无法接收大部分隐式广播，国产 ROM 直接屏蔽 CONNECTIVITY_CHANGE、TIME_TICK 等；动态广播只要注册者在前台或拥有前台服务即可正常接收。
3. 安全与合规：静态广播在清单中公开声明，容易被第三方嗅探并伪造广播，需加 exported="false" 或自定义权限；动态广播可局部注册为 exported=false，减少攻击面，同时注销时机明确，不会留下“持续监听”记录。
4. 内存与性能：静态广播无注销概念，若事件高频（如 SCREEN_ON）会频繁拉活进程，增加耗电；动态广播可在 onStop()/onDestroy() 及时注销，配合 LifecycleOwner 实现自动注销，零内存泄漏。

因此，国内项目除 BOOT_COMPLETED、SMS_RECEIVED 等系统特许广播外，其余场景一律使用动态注册，并在 Application 或 Lifecycle 感知组件中集中管理；若需跨进程通信，优先使用显式广播 + 自定义权限，或直接迁移到 JobScheduler、WorkManager、PushSDK，彻底告别“静态保活”旧思维。

拓展思考

1. Android 13 新增“运行时广播权限”RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED，动态注册也必须二选一，否则抛异常；如何封装一个兼容 Android 4.x~13 的 BroadcastReceiverLauncher？
2. 国内厂商“对齐唤醒”把静态广播批量延迟 1~5 min，导致心跳包失效；如何利用 AlarmManager+setExactAndAllowWhileIdle 或 WorkManager 的 expedited 工作项替代，并保证在 MIUI、EMUI、ColorOS 上拉活率 >95%？
3. 在 Jetpack Compose 单 Activity 架构下，所有页面都是 Composable，传统“在 BaseActivity 注册”已失效；如何借助 LifecycleOwner 的 ProcessLifecycleOwner 与 DisposableEffect，实现“页面可见时注册、不可见时注销”的精细化广播管理？
4. 如果业务必须监听 SMS_RECEIVED（银行验证码自动填充），而 Google Play 政策禁止除默认短信应用外的后台读取短信，如何引导用户将 App 设为默认短信应用，同时在国内渠道包保留 SMS 广播能力，实现“双包差异化”构建？