安卓广播机制学习笔记

来源：互联网发布：怎么整一家淘宝店编辑：程序博客网时间：2024/06/05 19:24

一，基本概念

１．广播队列

安卓原生有两个广播队列，在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;

正确的姿势是减少频繁的commit/apply操作, 尽可能批量化;以及合理的拆分sp文件,

因为每一次sp参数的commit/apply, 都是全量写文件, 而非增量写.
(d) 不要滥用广播, 更不要什么广播都监听, 只为做一个统计的功能...

五.进程内的广播

localbroadcast

阅读全文

0 0