android几种广播

A. Android BroadcastReceiver详解

BroadcastReceiver（广播接收器）是Android四大组件之一，顾名思义，通过广播的方式进行消息传递，其本质是一个全局的监听器，可以监听到各种广播，可以用来实现不同组件之间的通信。广播最大的特点就是发送方并不关心接收方是否接到数据，也不关心接收方是如何处理数据的，通过这样的形式来达到接、收双方的完全解耦合。

又称无序广播，这种广播完全是异步的，所有与广播Intent匹配的BroadcastReceiver，都可以收到这条广播，并且不分先后顺序，视为同时收到，通过Context.sendBroadcast()方法发送。这种广播的效率比较高，但缺点是接收器不能将处理结果传递给下一个接收器，并且无法在中途终止广播。

这是一种同步执行的广播，通过Context.sendOrderedBroadcast()方法发送，这种广播发出后，通过receiver的intent-filter中的android:priority属性来设置优先级，优先级从-1000～1000，数越大，优先级越高，使用setResult()方法把结果传递给下一个接收者，通过getResult()方法获取上一个接收者传递过来的结果，并可以通过abortBroadcast()方法丢弃该广播，使该广播不再传递给下一个接收者。

粘性广播通过Context.sendStickBroadcast()方法来发送，用此方法发送的广播会一直滞留，当有匹配此广播的接收器被注册后，该广播接收器就会收到此广播。使用此广播时，需要获得BROADCAST_STICKY权限。（在 android 5.0/api 21后不再推荐使用）

Android系统中内置了多个系统广播，只要涉及到手机的基本操作，基本上都会发出相应的系统广播。如：开启启动，网络状态改变，拍照，屏幕关闭与开启，点亮不足等等。每个系统广播都具有特定的intent-filter，其中主要包括具体的action，系统广播发出后，将被相应的BroadcastReceiver接收。系统广播在系统内部当特定事件发生时，有系统自动发出。

以上广播都属于全局广播，发出去的广播，只要有匹配的接收者，就可以收到广播。这样一来会造成一些问题，一是消耗性能，二是容易引起安全性的问题，为了能够简单的解决这方面的问题，Android引入了一套广播本地广播机制，使用该机制发出的广播只能够在本应用内部进行传递，并且广播接收器也只能接收来自本应用发出的广播。

使用方法
1.注册本地广播接收器

2.发送本地广播

3.注销本地广播接收器

本文用到的BroadcastReceiver

Android 8.0（API级别26）取消大部分静态注册广播，建议使用动态广播
https://developer.android.google.cn/about/versions/oreo/android-8.0

B. android蓝牙BLE（三） —— 广播

​ 在蓝牙开发中，有些情况是不需要连接的，只要外设广播自己的数据即可，例如苹果的 ibeacon 。自 Android 5.0 更新蓝牙API后，手机可以作为外设广播数据。

广播包有两种：

其中 广播包是每个外设都必须广播的，而响应包是可选的 。每个广播包的长度必须是 31个字节 ，如果不到 31个字节 ，则剩下的全用 0 填充 补全，这部分的数据是无效的

广播包中包含若干个广播数据单元，广播数据单元也称为 AD Structure 。

广播数据单元 = 长度值Length + AD type + AD Data。

长度值 Length 只占 一个字节 ，并且位于广播数据单元的 第一个字节 。

概念的东西有些抽象，先看看下面的广播报文：

​ 0x代表这串字符串是十六进制的字符串。 两位十六进制数代表一个字节 。因为两个字符组成的十六进制字符串最大为 FF ，即255，而java中byte类型的取值范围是-128到127，刚好可以表示一个255的大小。所以两个十六进制的字符串表示一个字节。

​ 继续查看报文内容，开始读取第一个广播数据单元。读取 第一个 字节: 0x07 ,转换为十进制就是7，即表示后面的7个字节是这个广播数据单元的数据内容。超过这7个字节的数据内容后，表示是一个新的广播数据单元。

​ 而第二个广播数据单元，第一个字节的值是 0x16 ,转换为十进制就是22，表示后面22个字节为第二个广播数据单元。

​ 在广播数据单元的 数据部分 中， 第一个字节 代表 数据类型 （AD type），决定数据部分表示的是什么数据。（即广播数据单元第二个字节为AD type）

AD Type 的类型如下：

​ 这bit 1~7分别代表着发送该广播的蓝牙芯片的物理连接状态。当bit的值为1时，表示支持该功能。
例：

蓝牙广播的数据格式大致讲了一下，有助于下面的广播操作的理解。

先看看广播设置（ AdvertiseSettings ）如何定义：

（1）、通过 AdvertiseSettings.Builder#setAdvertiseMode() 设置广播模式。其中有3种模式：

（2）、通过 AdvertiseSettings.Builder#setAdvertiseMode() 设置广播发射功率。共有4种功率模式：

（3）、通过 AdvertiseSettings.Builder#setTimeout() 设置持续广播的时间，单位为毫秒。最多180000毫秒。当值为0则无时间限制，持续广播，除非调用 BluetoothLeAdvertiser#stopAdvertising() 停止广播。

（4）、通过 AdvertiseSettings.Builder#setConnectable() 设置该广播是否可以连接的。

之前说过，外设必须广播广播包，扫描包是可选。但添加扫描包也意味着广播更多得数据，即可广播62个字节。

可见无论是广播包还是扫描包，其广播的内容都是用 AdvertiseData 类封装的。

（1）、 AdvertiseData.Builder#setIncludeDeviceName() 方法，可以设置广播包中是否包含蓝牙的名称。

（2）、 AdvertiseData.Builder#setIncludeTxPowerLevel() 方法，可以设置广播包中是否包含蓝牙的发射功率。

（3）、 AdvertiseData.Builder#addService UUID (Parcel UUID ) 方法，可以设置特定的 UUID 在广播包中。

（4）、 AdvertiseData.Builder#addServiceData(Parcel UUID ，byte[]) 方法，可以设置特定的 UUID 和其数据在广播包中。

（5）、 AdvertiseData.Builder#addManufacturerData(int，byte[]) 方法，可以设置特定厂商Id和其数据在广播包中。

​ 从 AdvertiseData.Builder 的设置中可以看出，如果一个外设需要在不连接的情况下对外广播数据，其数据可以存储在 UUID 对应的数据中，也可以存储在厂商数据中。但由于厂商ID是需要由Bluetooth SIG进行分配的，厂商间一般都将数据设置在厂商数据。

另外可以通过 BluetoothAdapter#setName() 设置广播的名称

先看一个例子，我们分别在 广播包 和 扫描包 中设置 AdvertiseData.Builder 的 每一种广播报文参数 ，得到一下报文内容：

(1)、Type = 0x01 表示设备LE物理连接。

(2)、Type = 0x09 表示设备的全名

(3)、Type = 0x03 表示完整的16bit UUID 。其值为0xFFF7。

(4)、Type = 0xFF 表示厂商数据。前两个字节表示厂商ID,即厂商ID为0x11。后面的为厂商数据，具体由用户自行定义。

(5)、Type = 0x16 表示16 bit UUID 的数据，所以前两个字节为 UUID ,即 UUID 为0xF117，后续为 UUID 对应的数据，具体由用户自行定义。

最后继承 AdvertiseCallback 自定义广播回调。

初始化完毕上面的对象后，就可以进行广播：

​ 广播主要是通过 BluetoothLeAdvertiser#startAdvertising() 方法实现，但在之前需要先获取 BluetoothLeAdvertiser 对象。

BluetoothLeAdvertiser 对象存在两个情况获取为Null:

所以在调用 BluetoothAdapter#getBluetoothLeAdvertiser() 前，需要先调用判断蓝牙已开启，并判断在 BluetoothAdapter 中获取的 BluetoothLeAdvertiser 是否为空（测试过某些华为手机 mBluetoothAdapter.() 为 false , 但是能发送ble广播）。

​ 与广播成对出现就是 BluetoothLeAdvertiser.stopAdvertising() 停止广播了，传入开启广播时传递的广播回调对象，即可关闭广播：

​ 虽然通过广播告知外边自身拥有这些Service,但手机自身并没有初始化Gattd的Service。导致外部的中心设备连接手机后，并不能找到对应的 GATT Service 和 获取对应的数据。

Service类型有两个级别：

创建 BluetoothGattService 时，传入两个参数： UUID 和Service类型：

​ 我们都知道Gatt中， Service 的下一级是 Characteristic ， Characteristic 是最小的通信单元，通过对 Characteristic 进行读写操作来进行通信。

​ 特征属性表示该 BluetoothGattCharacteristic 拥有什么功能，即能对 BluetoothGattCharacteristic 进行什么操作。其中主要有3种：

权限属性用于配置该特征值所具有的功能。主要两种：

Characteristic 下还有 Descriptor ，初始化 BluetoothGattDescriptor 时传入： Descriptor UUID 和 权限属性

为 Service 添加 Characteristic ，为 Characteristic 添加 Descriptor ：

​ 通过蓝牙管理器 mBluetoothManager 获取 Gatt Server ，用来添加 Gatt Service 。添加完 Gatt Service 后，外部中心设备连接手机时，将能获取到对应的 GATT Service 和 获取对应的数据

​ 定义 Gatt Server 回调。当中心设备连接该手机外设、修改特征值、读取特征值等情况时，会得到相应情况的回调。

最后开启广播后，用nRF连接后看到的特征值信息如下图所示：（加多了一个只能都的特征值）

android蓝牙BLE（一） —— 扫描

android蓝牙BLE（二） —— 通信

android蓝牙BLE（三） —— 广播

android蓝牙BLE（四） —— 实战

C. Android 第六讲 广播接收器和服务

两种方式：静态注册和动态注册
动态注册：

1）动态注册：需要定义一个继承自BroadcastReceiver类的子类，该接收器需要在Activity中的onDestroy中注销
2）静态注册：通过在AndroidManifest.xml中配置

两种广播形式：有序广播和无序广播
1）无序广播：接受标准广播的接收器将同时收到广播消息，异步执行，没有先后顺序 sendBroadCast
2）有序广播：sendOrderedBroadCast，按照一定顺序先后被接受顺序，由priority属性决定，abortBroadCast中断广播

如果只想在本应用中发送和接受广播，使用LocalBroadcastReceiver来对广播进行管理
本地广播不支持静态注册
优点 ：安全高效

Service是Android中的一种组件，和Activity的级别一致，但不能自己运行，只能后台运行，和其他组件交互，服务必须注册才能使用

本地服务：服务依附在主线程中，节约资源，主线程死掉服务终止
远程服务：服务在独立进程中，灵活性好 ，占用资源高

两种服务的启动模式：
1）start方式：调用者和服务之间没有关联，调用者退出不会影响服务，startService启动服务，如果服务不存在，调用onCreat方法，然后onStartCommand被调用。stopService关闭服务，onDestroy方法被调用
2）bind方式：调用者和服务绑定，调用者退出，服务终止bindService启动服务，onCreate方法创建服务，onBind方法绑定服务，onUnbind方法解绑，onDestory在服务结束时调用

D. Android注册广播有几种方式，分别是什么

注册方式有两种：
1、静态注册，就是在manifest文件里配置一下，这种方式注册的广播属于系统级广播。你的应用没打开也能收到广播。比如你要做一个收到某广播就启动你的应用的功能可以这样搞。
2、动态注册，在代码里执行一个rigisterBroadcastReciver（可能拼写有误）的方法。这种你要自己作好反注册。这种广播可以做成你的应用启动后才监听，关闭后就不监听的效果。

E. 注册广播有几种方式，这些方式有何优缺点请谈谈Android引入广播机制的用意。

android中，不同进程之间传递信息要用到广播，可以有两种方式来实现。
第一种方式：在Manifest.xml中注册广播，是一种比较推荐的方法，因为它不需要手动注销广播（如果广播未注销，程序退出时可能会出错）。
具体实现在Manifest的application中添加：上面两个android:name分别是广播名和广播的动作（这里的动作是表示系统启动完成），如果要自己发送一个广播，在代码中为：
Intent i = new Intent(“android.intent.action.BOOT_COMPLETED”);
sendBroadcast(i);
这样，广播就发出去了，然后是接收。
接收可以新建一个类，继承至BroadcastReceiver，也可以建一个BroadcastReceiver的实例，然后得写onReceive方法，实现如下：
protected BroadcastReceiver mEvtReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equals(“android.intent.action.BOOT_COMPLETED”)) {
//Do something
}
}
};
第二种方式，直接在代码中实现，但需要手动注册注销，实现如下：
IntentFilter filter = new IntentFilter();
filter.addAction(“android.intent.action.BOOT_COMPLETED”);
registerReceiver(mEvtReceiver, filter); //这时注册了一个recevier ,名为mEvtReceiver，然后同样用上面的方法以重写onReceiver，
最后在程序的onDestroy中要注销广播，实现如下：
@Override
public void onDestroy() {
super.onDestroy();
unregisterReceiver(mPlayerEvtReceiver);
}

F. 22 AndroidBroadcast广播机制

广播(Broadcast)机制用于进程/线程间通信，广播分为广播发送和广播接收两个过程，其中广播接收者BroadcastReceiver便是Android四大组件之一。

BroadcastReceiver分为两类：

从广播发送方式可分为三类：

广播在系统中以BroadcastRecord对象来记录, 该对象有几个时间相关的成员变量.

广播注册，对于应用开发来说，往往是在Activity/Service中调用 registerReceiver() 方法，而Activity或Service都间接继承于Context抽象类，真正干活是交给ContextImpl类。另外调用getOuterContext()可获取最外层的调用者Activity或Service。

[ContextImpl.java]

其中broadcastPermission拥有广播的权限控制，scheler用于指定接收到广播时onRecive执行线程，当scheler=null则默认代表在主线程中执行，这也是最常见的用法

[ContextImpl.java]

ActivityManagerNative.getDefault()返回的是ActivityManagerProxy对象，简称AMP.
该方法中参数有mMainThread.getApplicationThread()返回的是ApplicationThread，这是Binder的Bn端，用于system_server进程与该进程的通信。

[-> LoadedApk.java]

不妨令 以BroadcastReceiver(广播接收者)为key，LoadedApk.ReceiverDispatcher(分发者)为value的ArrayMap 记为 A 。此处 mReceivers 是一个以 Context 为key，以 A 为value的ArrayMap。对于ReceiverDispatcher(广播分发者)，当不存在时则创建一个。

此处mActivityThread便是前面传递过来的当前主线程的Handler.

ReceiverDispatcher(广播分发者)有一个内部类 InnerReceiver ，该类继承于 IIntentReceiver.Stub 。显然，这是一个Binder服务端，广播分发者通过rd.getIIntentReceiver()可获取该Binder服务端对象 InnerReceiver ，用于Binder IPC通信。

[-> ActivityManagerNative.java]

这里有两个Binder服务端对象 caller 和 receiver ，都代表执行注册广播动作所在的进程. AMP通过Binder驱动将这些信息发送给system_server进程中的AMS对象，接下来进入AMS.registerReceiver。

[-> ActivityManagerService.java]

其中 mRegisteredReceivers 记录着所有已注册的广播，以receiver IBinder为key, ReceiverList为value为HashMap。

在BroadcastQueue中有两个广播队列mParallelBroadcasts,mOrderedBroadcasts，数据类型都为ArrayList<broadcastrecord style="box-sizing: border-box;">：</broadcastrecord>

mLruProcesses数据类型为 ArrayList<ProcessRecord> ，而ProcessRecord对象有一个IApplicationThread字段，根据该字段查找出满足条件的ProcessRecord对象。

该方法用于匹配发起的Intent数据是否匹配成功，匹配项共有4项action, type, data, category，任何一项匹配不成功都会失败。

broadcastQueueForIntent(Intent intent)通过判断intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 来决定是前台或后台广播，进而返回相应的广播队列mFgBroadcastQueue或者mBgBroadcastQueue。

注册广播：

另外，当注册的是Sticky广播：

广播注册完, 另一个操作便是在广播发送过程.

发送广播是在Activity或Service中调用 sendBroadcast() 方法，而Activity或Service都间接继承于Context抽象类，真正干活是交给ContextImpl类。

[ContextImpl.java]

[-> ActivityManagerNative.java]

[-> ActivityManagerService.java]

broadcastIntent()方法有两个布尔参数serialized和sticky来共同决定是普通广播，有序广播，还是Sticky广播，参数如下：

broadcastIntentLocked方法比较长，这里划分为8个部分来分别说明。

这个过程最重要的工作是：

BroadcastReceiver还有其他flag，位于Intent.java常量:

主要功能：

这个过主要处于系统相关的10类广播,这里不就展开讲解了.

这个过程主要是将sticky广播增加到list，并放入mStickyBroadcasts里面。

其他说明：

AMS.collectReceiverComponents ：

广播队列中有一个成员变量 mParallelBroadcasts ，类型为ArrayList<broadcastrecord style="box-sizing: border-box;">，记录着所有的并行广播。</broadcastrecord>

动态注册的registeredReceivers，全部合并都receivers，再统一按串行方式处理。

广播队列中有一个成员变量 mOrderedBroadcasts ，类型为ArrayList<broadcastrecord style="box-sizing: border-box;">，记录着所有的有序广播。</broadcastrecord>

发送广播过程:

处理方式：

可见不管哪种广播方式，都是通过broadcastQueueForIntent()来根据intent的flag来判断前台队列或者后台队列，然后再调用对应广播队列的scheleBroadcastsLocked方法来处理广播；

在发送广播过程中会执行 scheleBroadcastsLocked 方法来处理相关的广播

[-> BroadcastQueue.java]

在BroadcastQueue对象创建时，mHandler=new BroadcastHandler(handler.getLooper());那么此处交由mHandler的handleMessage来处理：

由此可见BroadcastHandler采用的是”ActivityManager”线程的Looper

[-> BroadcastQueue.java]

此处mService为AMS，整个流程还是比较长的，全程持有AMS锁，所以广播效率低的情况下，直接会严重影响这个手机的性能与流畅度，这里应该考虑细化同步锁的粒度。

G. android 广播机制(2) 粘性广播

android的粘性广播，是指广播接收器一注册马上就能接收到广播的一种机制，当然首先系统要存在广播。而普通广播就是要先注册广播接收器，然后广播被发送到系统，广播接收器才能接收到广播。
所以他们的区别是：
粘性广播调用registerReceiver能马上接受广播，而普通广播不行。

对于粘性广播：
1.系统首先存在粘性广播

2.注册广播接收器

3.处理广播

下面用一个例子展示下他们的区别
主Acitivity

布局

布局有两个按钮，一个是注册粘性广播，一个是注册普通广播。点击注册粘性广播按钮会马上返回结果。而点击注册普通广播按钮则没有反应

H. android 的广播有几种类型分别如何使用

我刚才帮你查询了这个，一共分为六类的，直接打开就行了。

I. 说说Android的广播(1)

对于Activity的启动流程，我们已经有了几个版本的分析了。这里我们分析一个更容易一些的，四大组件中最简单的Broadcast Receiver。

关于Broadcast，有几点需要了解。首先是广播的类型，然后是广播的发送方法，最后是广播是如何被接收的。这三者相辅相承的，比如普通广播和有序广播只有在详细了解了广播的接收过程了之后，才能真正明白它的含义。

普通的广播是不在意顺序的，最简单的理解是同时可以收到这个广播。如果应用是动态注册这个广播的，且广播发送时这个进程还活着，那么当然可以并发的把广播尽快地传送出去是最好的。
但是，如果是通过AndroidManifest.xml静态注册的情况，也就是说这个广播首先要把一个进程启动起来，这时并发启动很多进程就是个问题了。Android目前的做法是，对这种静态的广播接收者，自动按有序广播的方式来串行处理。但是这对应用是透明的，应用不能假设系统已经把静态的无序广播当成有序广播来处理。

这个时候讲粘性广播有福了，因为从Android 5.0(API 21)开始，因为安全性的问题，官方已经正式废弃了粘性广播。

Context类提供两个方法可以用于发送普通广播：

差别是第二个设置权限。

发给特定的用户：

有序广播因为要处理消息的处理结果，所以要复杂一些。

如果只是想让广播可以按优先级来收取，并不在意处理的结果，可以用下面的版本：

同样，在多用户环境下，也可以选择给哪个用户发广播：

不管是普通的还是有序的广播都对应有粘性的版本：

以上的API都是定义于Context类中： https://developer.android.com/reference/android/content/Context.html

首先我们先看看发送端是如何发送的。
我们首先先放一个大图，让大家先有一个直观的印象，不管普通广播、有序广播、粘性广播如何组合，最终都汇集到一个大方法中。

我们先看应用发送普通广播的一个简单的例子：

非常简单，调用ContentWrapper的sendBroadcast方法就可以了。
然后我们顺藤摸瓜就好了。
Activity中的sendBroadcast，实际上调用的是：

我们来看frameworks/base/core/java/android/content/ContextWrapper.java中对sendBroadcast的定义：

ContextWrapper只是一个包装，真正的实现在ContextImpl中

我们来看/frameworks/base/core/java/android/app/ContextImpl.java中真正实现sendBroadcast的功能：

它会通过IPC去调用AMS的broadcastIntent。由于我们这个普通的广播的方法参数最少，所以好多都是传null。

加锁，定参数，然后调用真正的逻辑的实现。

我们先把broadcastIntentLocked的真正逻辑放一下，先看看有序广播是如何发送的。

ContextWrapper.sendOrderedBroadcast

Context是abstract方法，调用的是ContextWrapper的实现：

跟普通广播一样，还是会调用到ContextImpl.sendOrderedBroadcast

有序广播调用broadcastIntent的区别在于serialized参数，普通广播为false，有序广播为true.

原型为：

前面讲过带有回调的版本，我们看看它是如何实现的：

当然还是调用ContextImpl.sendOrderedBroadcast

这次变成只是一个封装了，它会调用一个更多参数的版本：

这次是一个全参数调用broadcastIntent的版本了，除了sticky就齐了

我们也不绕圈子了，直接看ContextImpl.sendStickyBroadcast.

J. Android系统广播(Broadcast)注册，发送，接收流程解析

以下广播简称Broadcast

   是Android四大组件之一，在四大组件的另外两个组件 和 拥有发送和接收广播的能力。Android 是在 进程间通信机制的基础上实现的，内部基于消息发布和订阅的事件驱动模型，广播发送者负责发送消息，广播接收者需要先订阅消息，然后才能收到消息。 进程间通信与 的区别在于：

   有三种类型

   存在一个注册中心，也可以说是一个调度中心，即 。广播接收者将自己注册到 中，并指定要接收的广播类型；广播发送者发送广播时，发送的广播首先会发送到 ， 根据广播的类型找到对应的 ，找到后边将广播发送给其处理。

   这里以普通广播为例子， 接收者有两种注册方式，一种是 ，一种是 ：

（广播的发送分为 两种，这里针对有序的广播） 中的android:priority=""和 中的IntentFilter.setPriority(int)可以用来设置广播接收者的优先级，默认都是0 , 范围是[-1000, 1000]，值越大优先级越高，优先级越高越早收到。

   在相同优先级接收同个类型广播时， 的广播接收器比 的广播接收者更快的接收到对应的广播，这个之后会进行分析。

   注：以下源码基于rk3399_instry Android7.1.2

   的流程可分为 ， 和 三个部分，这里依次分析下

   在Android系统的 机制中，前面提到， 作为一个注册和调度中心负责注册和转发 。所以 的注册过程就是把它注册到 的过程。

   这里我们分析 广播的过程， 和 有一个共同的父类 ，所以它们对应的注册过程其实是调用 ，接下来我们按照流程逐步分析调用流程的源码。

frameworks/base/core/java/android/content/ContextWrapper.java

   在之前的 Android应用程序启动入口ActivityThread.main流程分析 分析过，在我们启动 Activity 时会创建一个 对象，然后通过 传给我们启动的 ，其内部就会将该对象赋值给 ； 的 方法也是类似的赋值流程，这里放个简易的源码应该更好理解

   可以看到最后都会将生成的 对象赋值给对应的
对象。接下来继续分析 ， 即 函数。

/frameworks/base/core/java/android/app/ContextImpl.java

   这里我们首先看下如何将广播接收者 封装成一个 接口的 本地对象
/frameworks/base/core/java/android/app/LoadedApk.java

   每一个注册过广播接收者的 或 组件在<font color='Crimson'> LoadedApk </font>类中都有个对应的 对象，该对象负责将 与 组件关联起来。这些对象，以关联的 作为关键字保存在一个 中。之后对应的 又以 的 作为关键字保存在 的成员变量 对象中。最后通过 对应的 方法获得其 接口的 本地对象。之后再回到 注册方法内，将 对象发给 进行注册。

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

   在的 或 注册一个 时，并不是将其注册到<font color='OrangeRed'>AMS</font>中，而是将与它关联的<font color='OrangeRed'>InnerReceiver</font>对象注册到<font color='OrangeRed'>AMS</font>中，当<font color='OrangeRed'>AMS</font>接收到广播时，会根据 在内部找到对应的<font color='OrangeRed'>InnerReceiver</font>对象，然后在通过这个对象将这个广播发送给对应的 处理。

   注册过程这边画了一个简单的流程图:

   <font color='OrangeRed'>Broadcast</font>的发送过程可简单描述为以下几个过程：

frameworks/base/core/java/android/content/ContextWrapper.java

/frameworks/base/core/java/android/app/ContextImpl.java

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java