你遗漏的Android广播知识点
你遗漏的Android广播知识点
原理简介
广播是Android系统提供的一种可以在进程或者线程之间的通信，分为广播接受者和发送者；一般来说接受者先注册之间receiver，系统会通过binder机制将其注册到系统的AMS上，当发送者发送广播时，将Intent发送给AMS，AMS会查看已注册的广播，根据其intentFilter和优先级来发送，接受者收到消息后回调它的onReceive方法
注册
广播注册分为静态注册和动态注册，静态注册在AndroidManifest.xml，动态注册一般用在Activity的onResume和onPause里面；
静态注册
静态注册在AndroidManifest里面声明自己receiver，如下：
<receiver
android:name="com.xxx.receiver"
android:exported="true"
android:permission="1"
android:process=":bdservice_v1">
<intent-filter>
<action android:name="com.xxxx.action.PUSH_SERVICE" />
</intent-filter>
</receiver>
name: 广播名字
export: 是否可以接受到其他App的广播
process: 为其创建一个新的进程，进程名
permission: 具有相同权限的才能接受到
intentFilter: 过滤广播，接收特定的广播
一般来说静态注册的广播，当App退出以后也能收到系统发来的广播，但是现在Android系统对App的存活状态进行了严格的查看，而且对广播的intent增加了Flag：FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES，默认是不会发送给STOPPED状态的App
动态注册
动态注册一般用在onResume时注册register，onPause里面取消注册unregister，退出当前这个页面就不会在收到广播
广播分类
- 普通广播
- 有序广播
- 系统广播
- 粘性广播（5.1已废弃）
- 应用内广播（局部广播）
普通广播
Context.sendBroadcast(Intent)发送的普通广播，这类广播是无序的，不确定收到时的先后顺序
有序广播
sendOrderedBroadcast(Intent, permission) 这类广播接受者是有序的，接收是会根据注册的优先级，依次接收，并且接受者收到广播后可以修改广播内容setResult，还可决定是否继续向下发送abort，类似一个责任链模式；接收者的顺序按照protity(在intentFilter内定义)大小决定先后顺序接收，动态注册由于静态注册
系统广播
系统广播是由系统发送，具有特定的Intent意图，常见的有屏幕亮息、电池电量低、电话接收等，由于是系统发送的，不能为其添加Flag，所以App退出了不一定能收到系统广播
应用内广播
//发送
LocalBroadcastManager manager = LocalBroadcastManager.getInstance(this);
manager.sendBroadcast(Intent);
//接收
LocalBroadcastManager.getInstance(this).registerReceiver(BroadcastReceiver, IntentFilter);
//结束时
LocalBroadcastManager.getInstance(this).unregisterReceiver(BroadcastReceiver);
只能当前应用内接收，且必须使用LocalBroadcastManager进行发送接收，其安全性能较好注意局部广播不是binder机制，是handler机制
粘性广播（已废弃）
sendStickyBroadcast() 发送广播时，系统会暂存广播，App退出后收不到没关系，下次启动时会收到
使用建议
广播通常是用于接收App之外的数据消息，如果有这个需求建议使用；如果只是接收当前App内部的消息，建议自己App内部逻辑回调处理，不然使用广播，消息还要去系统走一圈，效率不好，如果处于安全性的考虑，可以使用局部广播
扩展阅读
我们都知道Activity的内部类Handler会引起Activity的内存泄漏，其原因在于Handler内部类持有外部类Activity的引用，而Handler发送消息的Message持有Handler引用，而Message又被MessageQueue添加到队列，而MessageQueue又被Looper持有，而Looper呢？自然被ActivityThread持有，从而导致Activity到Root节点的引用链可达，而GC不认为Activity是垃圾，所以也就不会被回收，而一直保留着！
解决办法就是： 将Handler类型设置为static，切断最开始的引用持有！那同理，内部类BroadcastReceiver，我们使用static，在onResume我们注册register广播，但是不unregister这样可以解决内存泄漏吗？
动态广播引起的内存泄漏
如果按照上面的广播场景，就算设置static仍然还是会引起内存泄漏了，为什么？这就必须要分析register和Activity之间的引用链持有关系！
简单分析下源码！我们都知道registerBroadcastReceiver是Activity自身方法，其层层调用会走到Context的逻辑，而Context是一个ContextImpl类型，在其内部逻辑如下：
注意getOuterContext()参数方法，很关键，而且scheduler传递过来是null
public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter,
String broadcastPermission, Handler scheduler) {
return registerReceiverInternal(receiver, getUserId(),
filter, broadcastPermission, scheduler, getOuterContext(), 0);
}
private Intent registerReceiverInternal(BroadcastReceiver receiver, int userId,
IntentFilter filter, String broadcastPermission,
Handler scheduler, Context context, int flags) {
IIntentReceiver rd = null;
if (receiver != null) {
if (mPackageInfo != null && context != null) {
.......
} else {
if (scheduler == null) {
scheduler = mMainThread.getHandler();
}
将注册的receiver再次封装为ReceiverDispatcher，注意传递进去的context参数，返回
rd，为IIntentReceiver
rd = new LoadedApk.ReceiverDispatcher(
receiver, context, scheduler, null, true).getIIntentReceiver();
}
}
try {
将rd注册到AMS，也就是ActivityManagerService，rd的生命周期会长长
final Intent intent = ActivityManager.getService().registerReceiver(
mMainThread.getApplicationThread(), mBasePackageName, rd, filter,
broadcastPermission, userId, flags);
....
return intent;
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
从这里得知，IIntentReceiver会被注册到AMS，AMS那边就不继续分析了，但是IIntentReceiver被AMS持有，说明IIntentReceiver生命周期很长长，我们进入ReceiverDispatcher看看:
registered=true
ReceiverDispatcher(BroadcastReceiver receiver, Context context,
Handler activityThread, Instrumentation instrumentation,
boolean registered) {
if (activityThread == null) {
throw new NullPointerException("Handler must not be null");
}
这里mIIntentReceiver就是传递到AMS的，而它的构造方法传this，也就是ReceiverDispatcher，说明ReceiverDispatcher也会很长的生命周期
mIIntentReceiver = new InnerReceiver(this, !registered);
mReceiver = receiver;
mContext = context;
mActivityThread = activityThread;
mInstrumentation = instrumentation;
mRegistered = registered;
mLocation = new IntentReceiverLeaked(null);
mLocation.fillInStackTrace();
}
strong=true
InnerReceiver(LoadedApk.ReceiverDispatcher rd, boolean strong) {
mDispatcher = new WeakReference<LoadedApk.ReceiverDispatcher>(rd);
强引用持有
mStrongRef = strong ? rd : null;
}
从上可知，ReceiverDispatcher会被InnerReceiver强引用持有，所以ReceiverDispatcher生命周期会长，所以ReceiverDispatcher内部持有的参数生命周期都会很长，其内部的mContext是什么呢？
会不会是就是receiver的外部类Activity呢？
答案是的！
看上面代码，你会发现ReceiverDispatcher传入的context来源于ContextImpl的getOuterContext，它是其成员变量mOuterContext，这个由setOuterContext方法设置进去的！
这里我们要分清楚ContextImpl在App进程里面只有一个，会被ActivityThread和每个Activity持有，而其内部的mOuterContext是外部Context，他会在ActivityThead的performLaunchActivity方法中设置进去：
启动的Activity
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
ActivityInfo aInfo = r.activityInfo;
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
创建Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
......
} catch (Exception e) {
.....
}
try {
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
......
if (activity != null) {
......
appContext是ContextImpl类型，其设置Activity作为其外部context
appContext.setOuterContext(activity);
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback);
.....
}
这样就确定其mOuterContext就是Activity了，总结下其引用持有关系！如下图：
广播回调onReceive执行
如上图，IIntentReceiver是一个aidl的接口，会涉及binder通信，当有广播发送到AMS时，会binder调用IIntentReceiver接口，执行performReceive方法，然后在执行ReceiverDispatcher的performReceive方法，如下代码：
public void performReceive(Intent intent, int resultCode, String data,
Bundle extras, boolean ordered, boolean sticky, int sendingUser) {
final Args args = new Args(intent, resultCode, data, extras, ordered,
sticky, sendingUser);
....
把args的runnable添加到主Looper的定时执行
if (intent == null || !mActivityThread.post(args.getRunnable())) {
if (mRegistered && ordered) {
IActivityManager mgr = ActivityManager.getService();
if (ActivityThread.DEBUG_BROADCAST) Slog.i(ActivityThread.TAG,
"Finishing sync broadcast to " + mReceiver);
通知AMS执行完成
args.sendFinished(mgr);
}
}
}
public final Runnable getRunnable() {
return () -> {
ClassLoader cl = mReceiver.getClass().getClassLoader();
intent.setExtrasClassLoader(cl);
intent.prepareToEnterProcess();
setExtrasClassLoader(cl);
receiver.setPendingResult(this);
调用onreceive方法
receiver.onReceive(mContext, intent);
....
}
如上代码，AMS回调aidl接口，最后把我们的执行onReceiver方法封装到Runnable传递给主线程的Looper执行，这也确定了onReceive方法是在主线程执行的，所以也要注意不要太耗时
最后，看了这么多，发现在引用链ReceiverDispatcher可以不用持有Activity的引用，但是Android为何会如此设计呢？
可能在于onReceive方法通常要与我们的Activity的交互，这样强制让Activity存在，即使出现内存泄漏，从而不会出现奔溃现象！
