安卓广播机制学习笔记

一,基本概念

1.广播队列

安卓原生有两个广播队列,在AMS中初始化,由构造函数可以看出5个构造参数意义

        前台广播队列: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;
    }


二.广播发送

广播发送者可以决定:

1.通过设置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



你可能感兴趣的:(安卓广播机制学习笔记)