Android四大组件之BroadcastReceiver解析

你过来啊你
74 阅读10分钟

核心概念：

  • 定义： 一个用于响应系统范围或应用内部广播通知的组件。
  • 角色： 监听者/订阅者。它“订阅”特定的广播事件（由 Intent 对象定义），并在该事件发生时被系统调用。
  • 设计模式： 基于发布-订阅 (Pub/Sub) 模式。事件发布者发送广播，零个或多个订阅了该事件的接收者接收并处理。
  • 通信范围：
    • 应用内通信： 组件间解耦（如 Activity 通知 Service 数据更新完成）。
    • 跨应用通信： 应用间协作（如应用 A 通知应用 B 文件下载完成）。
    • 系统与应用通信： 系统状态变化通知（如开机完成、电量低、网络连接变化、时区变更、屏幕开关）。

超深度剖析维度

1. 注册机制与生命周期

  • 静态注册 (Manifest-declared):

    • 方式： 在 AndroidManifest.xml 中使用 <receiver> 标签声明。
    • 特点：
      • 持久性： 应用未启动时也能接收广播（系统发送的广播如 BOOT_COMPLETED 的关键）。
      • 启动应用： 收到匹配的广播时，系统会启动应用进程（如果未运行）来创建 BroadcastReceiver 实例并调用 onReceive()。
    • 生命周期： 非常短暂。每次广播到达都会创建一个新的 BroadcastReceiver 实例。onReceive(Context context, Intent intent) 方法被调用，该方法执行时间必须非常短（主线程！），执行完毕后该实例即被销毁。不能在 onReceive 中执行异步操作或启动长时间运行的任务（需使用 goAsync() 或转交给 Service/WorkManager）。
    • 限制 (Android 8.0+): 对大多数隐式广播（不针对特定应用的广播）禁止静态注册（豁免列表除外），以限制后台应用启动和节省资源。强制开发者使用动态注册或替代方案（如 JobScheduler）。

  • 动态注册 (Context-registered):

    • 方式： 在代码中（通常在 Activity/Service 的 onCreate()/onResume()）调用 Context.registerReceiver(BroadcastReceiver, IntentFilter) 注册。在 onDestroy()/onPause() 中调用 Context.unregisterReceiver() 注销。
    • 特点：
      • 上下文绑定： 与注册它的 Context (通常是 Activity 或 Service) 生命周期紧密关联。Context 销毁时必须注销，否则会导致内存泄漏。
      • 应用运行时： 只在应用进程运行且注册的 Context 有效时才能接收广播。
      • 灵活性： 可以在运行时根据条件动态改变注册的 IntentFilter。
      • 优先级： 动态注册的接收器通常比静态注册的优先级更高（在有序广播中更早收到）。
    • 生命周期： 注册期间有效。当 onReceive() 被调用时，生命周期约束与静态注册相同（短时间主线程执行）。注销后实例不再接收广播。

2. 广播发送机制 (sendBroadcast)

  • 核心方法：
    • Context.sendBroadcast(Intent) / Context.sendBroadcast(Intent, String)：发送标准广播（异步、无序）。
    • Context.sendOrderedBroadcast(Intent, String) / Context.sendOrderedBroadcast(Intent, String, BroadcastReceiver, Handler, int, String, Bundle)：发送有序广播。
    • Context.sendStickyBroadcast(Intent) (已弃用 API 21+)：发送粘性广播（广播会持续存在，新注册的接收器也能收到最近一次发送的该广播）。
  • Intent & IntentFilter：
    • Intent: 携带广播的“动作”(Action)、类别 (Category)、数据 (Data/Type)、附加信息 (Extras) 等。Action 是匹配接收器的关键。
    • IntentFilter: 接收器声明自己感兴趣的广播特征（Action, Category, Data, Scheme, Host, Port, Path, MimeType）。系统通过匹配发送方的 Intent 和接收方的 IntentFilter 来确定目标接收器。
  • 广播类型：
    • 标准广播 (Normal Broadcasts - sendBroadcast):
      • 完全异步。
      • 所有匹配的接收器几乎同时收到广播，彼此独立，无顺序、无法拦截、无法修改结果。
      • 效率较高。
    • 有序广播 (Ordered Broadcasts - sendOrderedBroadcast):
      • 同步执行（一个接一个）。
      • 接收器按优先级（在 IntentFilter 或动态注册时设置）从高到低依次接收。
      • 接收器可以：
        • 中断广播 (abortBroadcast()): 阻止广播传递给后续低优先级接收器。
        • 修改结果 (setResultExtras(Bundle), getResultExtras(boolean)): 向下一个接收器传递数据（通常用于收集信息）。
      • 可以指定一个最终接收器 (resultReceiver), 无论广播是否被中断，它都会最后收到广播（包含最终结果）。
      • 用于需要处理链式逻辑或收集结果的场景（如短信拦截、设置变更确认）。
    • 粘性广播 (Sticky Broadcasts - 已弃用):
      • 广播发送后会被系统保留（“粘住”）。
      • 后续注册的匹配接收器在注册后会立即收到最后一次发送的该粘性广播的 Intent。
      • 主要用于反映系统最后已知状态（如电池电量）。由于其持久性带来的安全和资源问题，已被弃用。替代方案包括：
        • 使用普通广播 + 应用自身持久化状态（如 SharedPreferences）。
        • 使用 Sticky 特性的 LocalBroadcastManager (也已弃用，但模式可用)。
        • 直接查询系统服务获取当前状态。

3. 系统交互与底层机制 (Binder, AMS)

  • 核心角色 - Activity Manager Service (AMS):
    • 广播的中央枢纽： 所有广播的发送 (sendBroadcast) 请求最终都路由到 AMS。
    • 注册管理： 维护全局的接收器注册表（包括静态和动态）。
    • 匹配与分发： AMS 根据发送的 Intent 和注册的 IntentFilter 进行匹配，确定目标接收器列表。
    • 有序广播调度： 对有序广播，AMS 负责按优先级排序接收器列表，并控制分发的顺序（一个接一个），处理中断请求和结果传递。
    • 进程管理： 对于静态注册的接收器，如果目标应用未运行，AMS 负责启动其进程。
    • 权限检查： 在发送和接收时执行权限检查 (android:permission, android:exported)。
  • 进程间通信 (IPC) - Binder:
    • 发送端到 AMS： 应用调用 sendBroadcast() 时，通过 Binder IPC 将 Intent 等信息传递给 AMS。
    • AMS 到接收端进程： AMS 确定接收器后，通过 Binder IPC 将 Intent 分派到目标应用进程。
    • 应用进程内的分发： 目标应用进程收到来自 AMS 的 IPC 调用后，在其主线程（通常是主线程，除非使用 goAsync() 或指定了 Handler）的消息队列中放入一个消息，最终触发创建 BroadcastReceiver 实例并调用其 onReceive() 方法。
  • onReceive() 执行环境：
    • 主线程 (UI 线程)： 默认情况下，onReceive() 在应用的主线程中执行。这是最关键的约束之一！
    • 超时 (ANR)： 因为运行在主线程，如果 onReceive() 执行时间过长（前台广播约 10 秒，后台广播更长但仍有超时），系统会弹出 Application Not Responding (ANR) 错误对话框。必须避免任何耗时操作！
    • goAsync(): 提供了一种机制让 onReceive() 在方法返回后继续工作。它返回一个 PendingResult 对象，允许你在后台线程中完成工作，然后显式调用 PendingResult.finish() 通知系统广播处理结束。这避免了 ANR，但增加了复杂性。
    • 指定 Handler： 动态注册时可以通过 registerReceiver(receiver, filter, broadcastPermission, scheduler) 的 scheduler 参数指定一个 Handler，将 onReceive() 调度到该 Handler 关联的线程执行（需要小心线程安全问题）。

4. 安全模型

  • 权限 (Permissions):
    • 发送权限 (android:permission in <intent-filter> or sendBroadcast(Intent, String)): 要求接收者必须持有指定权限才能接收此广播。用于保护发送方，确保只有授权应用才能接收敏感广播。
    • 接收权限 (android:permission in <receiver> or registerReceiver(BroadcastReceiver, IntentFilter, String, Handler)): 要求发送方必须持有指定权限才能发送广播给此接收器。用于保护接收方，防止恶意应用发送伪造广播。
  • 导出属性 (android:exported):
    • 控制该 BroadcastReceiver 是否能接收来自其他应用的广播。
    • true: 可以接收外部广播（默认值：如果 <intent-filter> 存在则为 true，否则为 false）。
    • false: 只能接收来自同一应用、同一用户 ID 或特权系统组件发送的广播。
    • 最佳实践： 除非明确需要跨应用接收广播，强烈建议显式设置为 false，这是防止恶意广播注入攻击的重要防线。
  • 签名权限 (protectionLevel="signature"): 用于限制广播只能在具有相同签名的应用间传递（如系统应用套件或同一开发者的应用套件）。
  • 隐式广播限制 (Android 8.0+): 极大地缩小了静态注册可以接收的隐式广播范围（Intent 没有指定目标包名的广播），迫使开发者使用动态注册（需应用运行）或 JobScheduler 等替代方案来响应后台事件，提升系统安全性和电池续航。

5. 性能与优化

  • ANR 风险： onReceive() 在主线程执行是最大的性能陷阱。任何超过短暂时间的操作都可能导致 ANR。
  • 优化策略：
    • onReceive() 极简主义： 只做绝对必要的最小工作（如状态检查、启动服务/工作线程、设置标志）。
    • goAsync(): 用于将耗时任务移出主线程。务必在完成后调用 finish()。
    • 委托给 Service: 使用 Context.startService() 或 Context.startForegroundService() (Android 8.0+) 在 onReceive() 内启动一个 Service 来处理耗时任务。这是常见且推荐的做法。
    • 委托给 WorkManager / JobIntentService: 对于需要保证执行的后台任务，尤其是不紧急的任务，使用 WorkManager 或 JobIntentService (已进入维护模式) 是更好的选择，它们能处理后台执行限制。
    • 避免在 onReceive() 中启动 Activity: 用户体验差（突然弹窗）。考虑使用通知 (Notification)。
    • 谨慎使用有序广播： 串行执行会显著增加整体延迟。
    • 及时注销动态接收器： 防止内存泄漏和接收不必要的广播。
    • 限制广播范围： 优先使用 LocalBroadcastManager (已弃用，但其思想可用) 或应用内事件总线（如 RxJava, EventBus, LiveData）进行应用内通信，避免不必要的系统级广播开销。
    • 避免粘性广播： 已弃用且效率低。

6. 替代方案与最佳实践

  • 应用内通信首选：
    • LocalBroadcastManager (已弃用，但概念有效)： 其高效、安全的进程内广播机制值得借鉴。可使用 LiveData, RxJava, EventBus 或自定义基于 Handler/Looper 的机制实现类似功能。
    • 观察者模式 (LiveData, Flow, RxJava): 非常适合组件间状态变化的通知。
    • 回调接口 (Callbacks): 直接、强类型，适用于紧密耦合的组件（如 Fragment 和 Activity）。
    • 事件总线 (EventBus, Otto): 提供发布-订阅，解耦性好，但需注意生命周期管理和潜在的内存泄漏。
  • 跨应用/后台任务通信：
    • ContentProvider: 共享结构化数据，可通过 ContentObserver 监听数据变化。
    • Binder (AIDL) / Messenger: 用于需要双向、结构化、长时间通信的场景（RPC）。
    • JobScheduler / WorkManager: 处理需要在特定条件（如网络连接、充电状态）下执行的后台任务。系统优化资源调度。
    • AlarmManager: 安排精确或非精确的未来事件（慎用，有唤醒锁和电池消耗问题）。
  • 系统状态监听：
    • 使用系统提供的 BroadcastReceiver (遵守限制)： 如 ConnectivityManager.CONNECTIVITY_ACTION, Intent.ACTION_BATTERY_CHANGED (动态注册)。
    • 直接查询系统服务： 如 (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE).getActiveNetworkInfo() 获取当前网络状态，比监听广播更及时。
  • 最佳实践总结：
    1. 优先考虑应用内通信替代方案。
    2. onReceive() 必须轻量快速，避免 ANR。
    3. 耗时操作委托给 Service, WorkManager 或 goAsync()。
    4. 动态注册务必及时注销。
    5. 静态注册仅用于必须应用未启动时接收的广播（且需符合 Android 8.0+ 限制）。
    6. 显式设置 android:exported="false" 除非必要。
    7. 合理使用权限保护广播发送和接收。
    8. 了解有序广播和标准广播的区别，按需选择。
    9. 避免使用粘性广播。
    10. 严格遵守 Android 版本对广播的限制（尤其是后台和隐式广播）。

总结

BroadcastReceiver 是 Android 事件驱动架构的基石，提供了强大的全局和应用内通信能力。然而，其设计（尤其是主线程执行的 onReceive 和进程启动机制）带来了显著的 ANR 风险、性能开销和安全挑战（如恶意广播注入）。随着 Android 版本的演进（特别是 Android 8.0 的隐式广播限制），其使用场景，尤其是静态注册和后台接收，受到了严格约束。

avatar
文章
阅读
粉丝