从源码角度看广播

简介

几乎每个安卓应用都无可避免的使用到广播。例如监听WIFI的开启状态、时间的获取，甚至是我们最常用的闹钟功能，都是结合着AlarmManager与广播来实现的。理解广播的注册、发送与接收实现源码将使我们更加懂安卓系统，同时，基于对广播的理解，我们也能很快的掌握AMS中其它组件的实现原理。

网上对于广播源码的分析数以千计，其中不乏精品的文章。但这些文章大多都太过枯燥、太抽象、太冗长，我最初看这些文章时，看了很多遍后才能慢慢理解。这篇文章里，我将画出几张简明扼要的图，简略的列出广播注册、发送中涉及到重要类。每副图后都会有我的一些简洁的理解，都是我在平日里开发中积累的精华。初学者能够通过这些对广播源码有个迅速的大体印象，熟悉广播源码的同学也能够查漏补缺。受语言与我自己理解的局限，如果文章中出现错误还希望大家指正。

文章最后，我会附上一张广播实用adb日志的输出对应图，希望能帮大家对于广播日志有个cheat sheet的作用:-)

重要类

• ReceiverDispatcher
• BroadcastQueue
• BroadcastRecord
• BroadcastFilter
• ResolveInfo
• InnterRceiver
• ReceiverList

广播注册

概括图

未包含的点

我这张图为了避免信息太多内容晦涩，有两个重要的过程没有画出来:

1. 动态注册广播操作过程中，首先会检查sticky广播进行检查操作
2. 静态广播的注册逻辑在PMS中，涉及对manifest文件的解析，以后再分析吧

这里我详细说说动态注册时，对sticky的特殊处理。

动态广播注册阶段中，第一步就是对sticky广播进行检查。 如果AMS中的mStickyBroadcasts存在符合过滤条件的Intent，那么这个广播在注册阶段就会被派发。当从registerReceiver传参进来的receiver为NULL，那么这个最新的sticky Intent将直接被返回。值得注意的一点是，在注册阶段发送出的广播是不会出现在dump日志历史记录中的。

具体解析

再看这张图, 我将从左到右对每个重要图像进行解释：

• mReceivers: 维护在App中的一个列表，用户存储BroadcastReceiver与ReceiverDispatcher之间的对应关系，同一个BroadcastReceiver对应的Binder Stub将不会被反复创建
• InnerReceiver: 实现在App中的Binder”服务端”，它的父类是Binder Stub，当广播在AMS调度时，AMS将在system_server端调用它的代理对象binder call到客户端，以在App端触发广播的onReceive方法
• mRegisteredReceivers: 动态广播注册的核心对象，是一个HashMap，这个Map以IBinder为键，每个BroadcastReceiver将会在AMS中对应这一个ReceiverList
• ReceiverList: 继承自一个泛型为IntentFilter的ArrayList，保存着IntentReceiver句柄，同时有着匹配广播Intent的作用

mRegisteredReceivers中的数据在App进程死亡或App调用unregisterReceiver反注册接口才会被清除。

广播发送

广播入队

• IntentResolver: 动态注册的广播都存储在这个对象中
• registeredReceiver: 动态广播接收者列表
• PMS：负责解析与存储静态广播信息
• receivers: 景泰广播接收者列表
• BroadcastRecord: 进行广播入队的基本单位，定义了这条广播的类型、属性和所有的接收者列表
• BroadcastQueue: AMS中目前维护了前台、后台两种类型的队列，每个队列有两个List，分为并行与串行列表；同时，BroadcastQueue也是dump日志中最重要的打印单位，保存着历史的广播派发记录

广播入队的过程中，最重要的步骤就是收集接收者的列表，并将它封装成一个BroadastRecord对象，将这个record对象加入到BroadcastQueue中，并调用Handler的sendMessage方法，准备派发广播

广播派发

这张图中的BroadcastQueue, BroadcastRecord, BroadcastFilter, ResolveInfo和ReceiveList在前面的队列中都已经出现过了，我就不做解释了，只对App端的几个对象进行解释：

• ActivityThread: 客户端的”主线程”,本质上不是线程，当新进程在Zygote成功创建后，会调用ActivityThread的main方法，而这个方法将会启动一个Looper，所谓的客户端主线程就运行在这个Looper上，main方法调用Looper.loop后将进入无限循环，等待新的消息进行处理
• ApplicationThread: 继承自ApplicationThreadNative,是App端与AMS进行binder call的服务端，AMS调用到App端都是ONE WAY的方式，AMS不需要等待客户端执行完成
• ActivityThread.H: 动态广播将运行在这个Hanlder中
• LoadedApk.Args: 实现了Runnable方法, 静态广播的onReceive方法在这里进行执行

广播的派发是在BroadcastQueue对象中进行的，它维护着并行与串行两个队列。在派发的过程中，并行广播将会被先派发，随后再派发串行广播

动态广播的派发是取出BroadcastFilter的ReceiverList对象，通过ProcessRecord拿到ApplicationThread的代理对象，binder call调用，随后在App中调用BroadcastReceiver.onReceive方法；静态广播的派发是从ResolverInfo对象中取出processName, 再取出ProcessRecord, 最后在LoadedApk中调用了BroadcastReceiver.onReceive

读懂”adb shell dumpsys activity b”

这里我不想直接贴上这条adb命令的执行样例，因为实在太长了，会让这篇文章显得很水:-)

有兴趣的话大家可以试试这条命令，对应着我画的这个图，就能很清楚明白的理解它的意思

这里我简单解释下：

• Registered Receivers & Receiver Resolver Table: 广播注册信息
• Active broadcasts & Pending broadcast: 当前BroadcastQueue的运行状态；正在派发执行的广播
• Historical broadcasts: BroadcastQueue中的广播派发历史
• Sticky broadcasts for user: AMS中存储的粘性广播信息
• mBroadcastScheduled：已经enqueue，但是没有派发的广播

总结

• 动态广播的注册主要维护的是mRegisteredReceivers这个HashMap表
• 广播发送中的入队列步骤主要是收集动态注册和静态注册的接收者，封装成一个BroadcastRecord，enqueue到队列中
• 广播发送中的派发步骤主要是调用binder call到各个客户端，执行BroadcastReceiver.onReceive方法
• dumpsys activity b中保存着广播注册、发送中涉及的重要数据结构的实时状态与历史状态，对调试很有帮助

扫码支持0.99元，您的支持将鼓励我继续创作！ Donate

Alipay