Android笔记--BroadcastReceiver

最新推荐文章于 2024-11-08 22:26:51 发布

dgd29756

最新推荐文章于 2024-11-08 22:26:51 发布

阅读量100

点赞数

文章标签：移动开发

原文链接：http://www.cnblogs.com/zharma/p/8387566.html

版权

BroadcastReceiver（一）--用法总结

一. BroadcastReceiver简介

BroadcastReceiver是Android四大组件之一，他的作用是监听并且接受系统或者其他App发出的广播，并对感兴趣的广播做处理。

二. 广播的应用场景

Android系统中各个组件之间的通信。

同一应用或者不同应用都可以做到。最开始的组件化解耦常用的办法就是利用广播。但是后续出来了更优秀的解耦框架比如ARouter等
对Android系统发出的特定广播进行监听。并做出相应的处理。

例如，看视频的时候，如果意外wifi断掉，该为了4G网络。那这种情况采用监听网络状态的广播就很实用。利用网络状态的变化对视频进行暂停，给用户一个有好的提示。
多线程通信

三. 内部流程

实现设计三个方面的内容：

广播接收方
广播发送方
AMS

三者中，广播接收方和广播发送方不直接交互。而是通过AMS利用Binder通信完成。接收方和发送方不会感知对方的存在。

要想完成一个完整的广播发送和接受的流程要按一下的过程执行：

广播接收方（BroadcastReceiver）注册到AMS中（Binder通信）
广播发送方（sendBroadcast）发送广播到AMS(Binder通信)
AMS会在自己所在的system_server进程中维护一个广播接收器的注册列表，当广播发送方将消息发送过来以后，AMS会根据广播发送方的IntentFilter和permission等信息在自己维护的注册表中匹配合适的广播接受器。一旦匹配成功，AMS就会利用Binder把广播消息发送到对应的广播接收器的消息循环队列。
广播接收器会在自己的消息循环对列中拿广播消息，并回调onReceive方法。

四. BroadcastReceiver实例构建

public class MyBroadcastReceiver extends BroadcastReceiver {


  @Override
  public void onReceive(Context context, Intent intent) {
    //重写onReceive方法。当接收到广播以后会回调这个方法
    }
}

其中需要注意onReceive方法不能执行耗时操作。

广播接收器注册

广播接收器注册有两种方式：

静态注册
动态注册

静态注册方式

和activity在manifest.xml的存在形式类似：

<receiver
    android:enabled=["true" | "false"]
    /*
    指定是否启用了接收机,也就是说,是否可以被系统实例化
    */

    android:exported=["true" | "false"]
    /*
    *exproted表示这个组件对于其他应用的可见性。可选值是true false
     true | 能被外部应用调用，但是可以通过permission选项做权限过滤
     fasle | 正好相反
     默认值：
        如果没有intent filter标签：
        那么activity, receiver,  service： 默认 false

        如果有intent filter标签:
        那么activity, receiver,  service： 默认 true

        不管有没有intent filter标签:
        contentProvider总是true

    *
    /


    android:icon="drawable resource"
    android:label="string resource"
    android:name=".MyBroadcastReceiver"//receiver的名称

    android:permission="string"//这个属性用于权限验证，限定只有启动本组件的Intent具有相同的permission值传过来，才能成功启动本组建。适用于四大组件


    android:process="string"
    //BroadcastReceiver运行所处的进程
//默认为app的进程，可以指定独立的进程
//注：Android四大基本组件都可以通过此属性指定自己的独立进程
    >

//用于指定此广播接收器将接收的广播类型
//本示例中给出的是用于接收网络状态改变时发出的广播
 <intent-filter>
<action android:name="这里可以自己编写，也可以写系统发的广播名称" />
    </intent-filter>
</receiver>

动态注册方式

在代码中调用context.registerReceiver（）方法即可

// 选择在Activity生命周期方法中的onResume()中注册
@Override
  protected void onResume(){
      super.onResume();

    // 1. 实例化BroadcastReceiver子类 &  IntentFilter
     MyBroadcastReceiver mBroadcastReceiver = new MyBroadcastReceiver();
     IntentFilter intentFilter = new IntentFilter();

    // 2. 设置接收广播的类型为自定义的广播
    intentFilter.addAction("com.demo.testaction");

    // 3. 动态注册：调用Context的registerReceiver（）方法
     registerReceiver(mBroadcastReceiver, intentFilter);
 }


// 注册广播后，要在相应位置记得销毁广播
// 当此Activity实例化时，会动态将该广播注册到系统中
// 当此Activity销毁时，动态注册的广播将不再接收到相应的广播。
 @Override
 protected void onPause() {
     super.onPause();
      //销毁广播
     unregisterReceiver(mBroadcastReceiver);
  }

注意：动态广播要在onResume中注册，在onPause中注销

如果不注销会导致内存泄露，重复注销和重复注册也是不允许的。在onResume()注册、onPause()注销是因为onPause()在App死亡前一定会被执行，从而保证广播在App死亡前一定会被注销，从而防止内存泄露。假设我们将广播的注销放在onStop()，onDestory()方法里的话，有可能在Activity被销毁后还未执行onStop()，onDestory()方法，即广播仍还未注销，从而导致内存泄露。但是，onPause()一定会被执行，从而保证了广播在App死亡前一定会被注销，从而防止内存泄露

两种注册方式的区别：
静态注册：伴随App启动而注册到AMS，在App存活状态下静态注册广播常驻内存中，不受其他组件的影响，一旦有感兴趣的广播到来就可以接受。
动态注册：在代码中调用context.registerReceiver()方法才注册进AMS，而且会跟随context的周期而存活。context结束即广播接收器结束。不能做到整个App存活状态接受广播。

两者的实质区别就是注册的方式，和存活的时间。

发送广播

发送刚播使用context.sendBroadcast方法发送,其中重要参数是Intent，而Intent是广播消息的载体

广播类型

现在上面介绍了广播接收器分类和写法，广播如何发送。接下来介绍广播实体有哪些类型

普通广播
有序广播
系统广播
App内部广播
粘性广播

普通广播

普通广播是最常用的一种：

Intent intent = new Intent();
//这里写要发送的广播的动作
intent.setAction(BROADCAST_SAMPLE);
sendBroadcast(intent)

对应的广播接收器如果要接受这个广播，就需要在action中指明

<receiver android:name=".MyBroadcastReceiver">
            <intent-filter>
                <action android:name="BROADCAST_SAMPLE"/>
            </intent-filter>
        </receiver>

有序广播

这种有序广播发出去以后，对于一些列接收者有先后循序要求。
规则是这样的：

广播接收者们按照priority属性指定的大小排序。值大的先接收到广播。
priority相同，那动态注册的先接受广播

其中：

广播接收者们按顺序依次收到广播。
先收到的接收器可以拦截消费掉/修改广播内容，消费掉以后后续接收器不会再收到广播。修改之后后续接收器收到的是修改过的广播。

使用方法：

sendOrderedBroadcast

系统广播

系统广播的发送者是系统本身。比如:

屏幕被关闭 Intent.ACTION_SCREEN_OFF

屏幕被打开 Intent.ACTION_SCREEN_ON

等等，都是系统发出的广播。作为系统广播，开发者只能按需实现接收器

App内部广播

App内部广播可以防止第三方得知intent-filter标签内容以后骚扰性地发广播给我们的应用。

App内部广播可理解为一种局部广播，广播的发送者和接收者都同属于一个App。
相比于全局广播（普通广播），App应用内广播优势体现在：安全，效率高

使用方法1：

注册广播标签中exported属性指定为false,这样就不会把这个组件暴露给外部应用
发送接受广播都设置权限
发送广播时指定该广播接收器所在的包名，此广播将只会发送到此包中的App内与之相匹配的有效广播接收器中

利用intent.setPackage(packageName)指定报名

使用方法2：
使用封装好的LocalBroadcastManager类

使用方式上与全局广播几乎相同，只是注册/取消注册广播接收器和发送广播时将参数的context变成了LocalBroadcastManager的单一实例

注：对于LocalBroadcastManager方式发送的应用内广播，只能通过LocalBroadcastManager动态注册，不能静态注册

粘性广播（5.0以后已失效）

粘性广播会滞留，不仅保证在广播发送之前注册了的接收器可以收到广播，也保证后续注册了该粘性广播的接收器也可以接收到这个广播。这种广播已经在5.0失效

这里需要注意的是permission的使用：

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.demo.viewdemo">
    <permission android:name="com..viewdemo.receivermusthave"/><!-- 这里生命的是发送者必须携带的权限 -->
    <permission android:name="com.demo.viewdemo.sendermusthave"/><!-- 这里声明的是接收者必须携带的权限 -->
    <uses-permission android:name="com.demo.viewdemo.receivermusthave"/><!-- uses-permission 是代表本应用拥有的权限，而发送者要求的权限，本App必须具备才可以 -->
    <uses-permission android:name="com.demo.viewdemo.sendermusthave"/><!-- 发送广播的应用必须具备这个权限，我们自己的应用才会去接收 -->
    <application>
        <receiver android:name=".MyBroadcastReceiver"
                  android:permission="com.demo.viewdemo.sendermusthave">
                <!-- permission属性是要求发送者必须具备的权限 -->
                <intent-filter>
                    <action android:name="con.demo.TT"/>
                </intent-filter>
         </receiver>
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>

                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>
        </activity>
    </application>

</manifest>

还需要注意的是在同一个应用里，
这种要求发送方必须具备的权限，即使省略，依旧可以收到这个广播。

但是最好都声明出来。避免不必要的麻烦

转载于:https://www.cnblogs.com/zharma/p/8387566.html