一，基本概念
１．广播队列
安卓原生有两个广播队列，在AMS中初始化，由构造函数可以看出５个构造参数意义
前台广播队列：mFgBroadcastQueue = new BroadcastQueue(this, mHandler,
"foreground", BROADCAST_FG_TIMEOUT, false)
后台广播队列：mBgBroadcastQueue = new BroadcastQueue(this, mHandler,
"background", BROADCAST_BG_TIMEOUT, true);
BroadcastQueue(ActivityManagerService service, Handler handler,
String name, long timeoutPeriod, boolean allowDelayBehindServices) {
mService = service;
mHandler = new BroadcastHandler(handler.getLooper());
mQueueName = name;//广播队列名字
mTimeoutPeriod = timeoutPeriod;//延迟时间(前台:10s? 后台:60s)
mDelayBehindServices = allowDelayBehindServices;
}
二.广播发送
广播发送者可以决定：
１.通过设置flag来决定是否为前台广播，默认是后台广播
2.有序广播还是无序广播。
三.广播接收器注册
3.1静态注册:在manifest文件中注册的广播接收器
3.2动态注册:context.registerReceiver()注册的广播接收器
四.广播分发(调度)
4.1广播分发是AMS调度的
无序广播：首先是将无序的广播一次全部分发给他的动态接收者(如果该广播有动态注册的接收器)，不阻塞，无延迟。其次将广播依次发送给它的静态注册者。
会阻塞，有延迟。
有序广播：不管接收者是动态注册还是静态注册，都是依次分发。
从系统的角度理解：对于无序广播，动态注册的接收器所在的进程都活着，系统不用起大量的线程，直接将广播发送给接收者，执行相关业务逻辑，但是对于无序广播的
静态接收者，其所在的进程有可能没有起来，系统为了避免短时间拉起很多进程，增加系统负担，采用了依次分发。对于有序广播，不管其接收者是动态静态都是按照顺序分发。
4.2分发过程中遇到的延迟以及广播执行过程中的ANR
对于依次分发的广播(包括有序和无序)，若果一个广播发生了延迟，势必会导致后续的广播延迟发送，这样会导致广播接收者延迟接收，对那些依赖于广播的UI交互，体验变得
非常差，比如：一个progressDialog的消失依赖与一个广播，这个广播延迟发送，导致一直等待状态。
ANR:
1.广播的处理是在onReceive中，该回调是在app的主线程中，如果做了耗时操作，势必会导致ANR,所以主线程最好只做UI相关的业务，这也是为什么主线程也叫UI线程
2.对于有序广播， AMS,AMS收到反馈之后接着调度下一个receiver，这种场景下，即使在onreceiver()中开启一个工作线程去处理业务，也可能会导致ANR，开启该工作线程的作用只是让主线程不阻塞，但是工作线程如果是耗时的，如果回调AMS时超过timeout(10s或60s)，则AMS会让你的app ANR。
4.3对于以上问题的改进
(1) 由当前BroadcastReceiver启动新的Service，在新的Service中操作
=>?再启动一个service,?并非好的方式,?? 正确姿势:?直接post message到异步handler thread.
(2) 使用goAsync(), 将操作在异步线程中执行
==>goAsync只是采用异步,?可以做到不阻塞app的主线程解决部分问题, 依然阻塞广播分发. 无法解决问题,
(3) 在特殊的场景下，广播阻塞也许会影响电话、短信等基础体验，如果不加以规范控制，后果会很严重。
==> a.影响电话/短信, 如果电话/短信的实现方式是要等待串行广播的onReceive才往下走的话, 那的确会阻塞, ?但这种情况电话/短信应该考虑修改实现方式;
b. 更多的影响电话/短信的场景, 可能是系统比较繁忙, 比如ams同步锁抢占比较严重.
(4) 系统广播的频繁注册和使用问题, 以及如何减少广播anr
==> 针对这个问题: ?我说几点建议
(a)?app可以尽可能将自己的实现采用异步架构;
(b)?如果只是自己app内的通信, 应该采用LocalBroadcastManager 来替代BroadcastReceiver;
(c) 合理使用SharedPreferences, 并非把所有的操作commit改为apply, 就解决了anr.
正确的姿势是减少频繁的commit/apply操作, 尽可能批量化;以及合理的拆分sp文件,
因为每一次sp参数的commit/apply, 都是全量写文件, 而非增量写.
(d) 不要滥用广播, 更不要什么广播都监听, 只为做一个统计的功能...
五.进程内的广播
localbroadcast
