broadcastandroid
① 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
② 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锁，所以广播效率低的情况下，直接会严重影响这个手机的性能与流畅度，这里应该考虑细化同步锁的粒度。
③ 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
④ 为什么Android要使用各种BroadcastReceiver
作为Android四大组件之一的BroadcastReceiver（广播接收者），同Activity（活动）一样，经常被大家用到，网上也是一堆对它的讲解，那么为什么Android要用广播接收者这种机制呢？
广播分为：普通广播和有序广播
1.Normal broadcasts（普通广播）：Normal broadcasts是完全异步的可以同一时间被所有的接收者接收到。消息的传递效率比较高。但缺点是接收者不能将接收的消息的处理信息传递给下一个接收者也不能停止消息的传播。可以利用Context.sendBroadcast发送。
2.Ordered broadcasts（有序广播）：Ordered broadcasts的接收者按照一定的优先级进行消息的接收。一次传送到一个接收器。 随着每个接收器依次执行，它可以将结果传播到下一个接收器，或者它可以完全中止广播，使得它不会被传递到其他接收器。 命令接收器运行可以用匹配的意图过滤器的android:priority属性控制; 具有相同优先级的接收器将以任意顺序运行。可以利用Context.sendOrderedBroadcast发送。
官网上介绍广播是用的监听系统网络状况的例子，其实关键字在于“监听”。
(1) 创建广播接收者
BroadcastReceiver是一个抽象类，所以我们要创建自己的广播接收者就要继承它，继承后会有提示重写onReceive方法。
public class NetworkBroadcastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals(ConnectivityManager.CONNECTIVITY_ACTION)) {
ConnectivityManager manager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo activeNetwork = manager.getActiveNetworkInfo();
if (activeNetwork != null && activeNetwork.isAvailable()) {
Toast.makeText(context, "有网络连接", Toast.LENGTH_SHORT).show();
} else {
Toast.makeText(context, "无网络连接", Toast.LENGTH_SHORT).show();
}
}
}
}
广播接收者的生命周期是从接收广播开始，到onRecevier方法执行完成结束，时间很短，一般不允许处理大批量耗时操作。这里顺便给出打印NetworkInfo的信息以供参考：
NetworkInfo:
type: WIFI[,type_ext: WIFI],
state: CONNECTED/CONNECTED,
reason: (unspecified),
extra: "TP-LINK_EFE8",
roaming: false,
failover: false,
isAvailable: true,
: false,
isIpv4Connected: true,
isIpv6Connected: false
[type: MOBILE[LTE],
state: CONNECTED/CONNECTED,
reason: connected,
extra: cmnet,
roaming: false,
failover: false,
isAvailable: true,
: false]
(2) 静态注册广播
静态注册广播，需要在AndroidManifest.xml中，添加<recevier/> 标签，将广播接收者注册到应用中。要添加过滤器IntentFilter，由于系统网络变化时会发送ConnectivityManager.CONNECTIVITY_ACTION ("android.net.conn.CONNECTIVITY_CHANGE")的广播，所以我们要监听这条广播。
<receiver android:name=".NetworkBroadcastReceiver">
<intent-filter android:priority="1000">
<action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
</intent-filter>
</receiver>
这里priority代表的是执行顺序的优先级，取值[-1000,1000]，后面的有序广播会讲到。
(3) 动态注册广播
i.意图过滤器 IntentFilter 用于给BroadcastReceiver绑定监听广播类型
ii.自定义的BroadcastReceiver，例如上文的
iii.注册方法 Context.registerReceiver(Receiver, IntentFilter)
iv.反注册方法 unregisterReceiver(Receiver)
IntentFilter mFilter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
mReceiver = new ();
registerReceiver(mReceiver, mFilter);
@Override
public void onDestroy() {
super.onDestroy();
unregisterReceiver(mReceiver);
}
这段代码是成对出现的，可以在onCreate的时候注册，在onDestroy的时候反注册，也可以在onResume和onPause中执行这写方法。不过Google API推荐的做法，在activity的onResume()中注册，在onPause()反注册。效果是当界面pause时，就不接收广播，从而减少不必要的系统开销。还有就是一定要主动反注册你的广播，否则会出现异常。
动态注册和静态注册的差别：动态注册后，广播接收者会依赖Activity的生命周期，而静态注册的广播不会，只要是系统有发出的广播，它都会接收，与程序是否启动无关。
(4) 发送普通广播
具体使用的方法是sendBroadcast(Intent intent)，通过隐式调用就可以，注意action是你自定义的，意思就是不可以发送系统广播，我试了，直接就崩了。
Intent intent = new Intent();
intent.setAction("com.fleming.chen.mybroadcast");
sendBroadcast(intent);
针对(3)(4)两点，如果你要用到的广播仅仅是应用里的，那么你可以用LocalBroadcastManager这个类，它与上述描述中的区别在于：
LocalBroadcastManager.getInstance(context).registerReceiver(mReceiver, mFilter);
LocalBroadcastManager.getInstance(context).unregisterReceiver(mReceiver);
LocalBroadcastManager.getInstance(context).sendBroadcast(intent);
通过sendBroadcast发送的广播，不会被通过LocalBroadcastManager类注册的广播接收者接收，反之也是如此，两者是不可以”互通友谊“的，推荐使用LocalBroadcastManager来管理广播。
(5) 发送有序广播
上面讲了那么多都是普通广播，那什么又是有序广播呢？
有序广播关键在于这类广播是有序的，上文中提到priority，这是IntentFilter的属性，用来让不同的广播拥有不同的执行顺序，即优先级不同。
定义三种不同优先级的广播接收者：
public class MyBroadcastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
String message = getResultData();
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
setResultData("这是修改后的数据");//第一个接收后处理一下，再交给下一个
}
}
}
public class MyBroadcastReceiver2 extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
String message = getResultData();//得到上一个的处理结果
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
abortBroadcast();//主动停止广播，不再继续传下去
}
}
}
public class MyBroadcastReceiver3 extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
//此时虽然该广播接收者也监听了，不过也没有内容
Toast.makeText(context, getResultData(), Toast.LENGTH_SHORT).show();
}
}
}
<receiver android:name=".MyBroadcastReceiver" >
<intent-filter android:priority="1000">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
<receiver android:name=".MyBroadcastReceiver2">
<intent-filter android:priority="0">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
<receiver android:name=".MyBroadcastReceiver3">
<intent-filter android:priority="-1000">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
Intent intent = new Intent();
intent.setAction("com.fleming.chen.myreceiver");
sendOrderedBroadcast(intent, null, null, null, 0, "这是初始的数据", null);
对于广播的内容，在Android 7.0上做了修改，即Project Svelte：后台优化
Android 7.0 移除了三项隐式广播，以帮助优化内存使用和电量消耗。此项变更很有必要，因为隐式广播会在后台频繁启动已注册侦听这些广播的应用。删除这些广播可以显着提升设备性能和用户体验。
移动设备会经历频繁的连接变更，例如在 WLAN 和移动数据之间切换时。目前，可以通过在应用清单中注册一个接收器来侦听隐式 CONNECTIVITY_ACTION 广播，让应用能够监控这些变更。由于很多应用会注册接收此广播，因此单次网络切换即会导致所有应用被唤醒并同时处理此广播。
同理，在之前版本的 Android 中，应用可以注册接收来自其他应用（例如相机）的隐式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 广播。当用户使用相机应用拍摄照片时，这些应用即会被唤醒以处理广播。
为缓解这些问题，Android 7.0 应用了以下优化措施：
面向 Android 7.0 开发的应用不会收到 CONNECTIVITY_ACTION 广播，即使它们已有清单条目来请求接受这些事件的通知。在前台运行的应用如果使用 BroadcastReceiver 请求接收通知，则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。
应用无法发送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 广播。此项优化会影响所有应用，而不仅仅是面向 Android 7.0 的应用。
如果您的应用使用任何 intent，您仍需要尽快移除它们的依赖关系，以正确适配 Android 7.0 设备。Android 框架提供多个解决方案来缓解对这些隐式广播的需求。例如，JobScheler API 提供了一个稳健可靠的机制来安排满足指定条件（例如连入无限流量网络）时所执行的网络操作。您甚至可以使用 JobScheler 来适应内容提供程序变化。
所以说，在Android的世界，到处都充满着广播，就是为了用来监听手机的各种状态，给用户提醒，这是一种很好的用户体验，不过任何事情都是如此，广播也不可以多用哦，