Android8.0 静态广播的接收方式改变

Android O 广播机制的改变


  在Android O之前,Broadcast广播作为Android系统的四大组件之一,其使用简单,操作方便,占用资源小等优点,使其成为了Android开发中最常用的夸进程通讯方案(比AIDL、ContentProvider使用的更为频繁)。但由此带来的隐患也是显而易见的,并且这种隐患快要达到不可控制的地步。主要表现在:

  • 导致大量的第三方应用程序开机自启动。因为每个应用都有监听开机广播的权利,每个程序都可以在开机后迅速自我启动,最终导致大量进程在后台运行,系统资源消耗过度,带来系统运行卡顿、机器发热等问题。
  • 肆意的广播发送和监听,再配合Android的Service组件,可以很容易的实现所谓的”不死程序“,各大第三方应用为了抢占市场,几乎都将自己变成”不死程序“,这更加剧了系统资源的占用和消耗,可以说,Android系统就是在这种恶意竞争中逐渐沦为”Android机不行,三个月之后就会越来越卡,能用两年已经很了不起了!“

  基于以上种种原因,从Android O开始,Google做了一系列规避措施,最直接的体现在两个方面:

  1. 取消静态广播的支持。
    以前很好用的静态广播消息将接收不到,比如开机广播:“android.intent.action.BOOT_COMPLETED”,网络状态发生改变广播:“android.net.conn.CONNECTIVITY_CHANGE”。必须以动态的方式才能接收到,这就保证了”只有用户将你的应用置为前台应用,也就是用户正在使用你的应用的时候,该应用才有可能收到广播“。这一举措旨在解决应用开机自启动泛滥的问题。
  2. 更改Service的启动方式。
    如果一个应用在后台去startService(比如在broadcast中),企图在后台悄悄的运行跑流量,这将直接抛出异常。和广播类似,要启动一个服务,必须是”用户正在使用你的应用期间“才可行,或者你的服务是一个前台服务。这一举措旨在解决”应用后台自启动,成为不死应用,占用大量资源“的问题。

开机广播

对于android.intent.action.BOOT_COMPLETED 这个广播,虽然被禁用了,但是在实际的开发中还是很有必要的存在,很多操作还是需要该广播的支持。所以Google也没有把这个广播完全封死,如果应用的android:sharedUserId=“android.uid.system”,那么该应用还是可以以静态广播的方式注册和监听到它。而对于第三方应用,显然已经无法再收到这条广播了。


网络状态改变广播

对于android.net.conn.CONNECTIVITY_CHANGE,显然就没这么友好了,即使是android:sharedUserId=“android.uid.system” 的应用,也将收不到静态注册的广播消息。如要接收该消息,只能是两种方式:

  1. 以动态注册广播形式注册
  2. 以静态注册广播形式注册,在AndroidManifest.xml中指明该应用的SDK为低于26,比如 < uses-sdk android:minSdkVersion=“23” android:targetSdkVersion=“23” />。

你可能感兴趣的:(android系统开发)