Android_广播

广播

Android中的每个应用程序都可以对自己感兴趣的广播进行注册,这些广播可能是来自于系统的,也可能是来自于其他应用程序的。

Android提供了一套完整的API,允许应用程序自由地发送和接收广播。

广播主要可以分为两种类型:标准广播和有序广播。

标准广播

完全异步执行。广播发出之后,所有的BroadcastReceiver几乎会在同一时间收到这条广播消息。这种广播效率比较高,同时也意味着它是无法截断的。

有序广播

有序广播是一种同步执行的广播,广播发出之后,同一时刻只会有一个BroadcastReceiver能够收到这条广播消息,当这个BroadcastReceiver中的逻辑执行完毕后,广播才会继续传递。

优先级较高的BroadcastReceiver可以先收到广播消息,并且前面的BroadcastReceiver还可以截断正在传递的广播,这样后面的BroadcastReceiver就无法收到广播消息了。

接收系统广播

Android内置了很多系统级别的广播,可以在应用程序中通过监听这些广播来得到各种系统的状态信息。比如手机开机完成后会发出一条广播,电池的电量发生变化会发出一条广播,系统时间发生改变也会发出一条广播,等等。如果想要接收这些广播,就需要使用BroadcastReceiver。

应用可以根据感兴趣的广播,自由地注册BroadcastReceiver,这样当有相应的广播发出时,相应的BroadcastReceiver就能够收到该广播,并可以在内部进行逻辑处理。

注册BroadcastReceiver的方式一般有两种:在代码中注册和在AndroidManifest.xml中注册。其中前者也被称为动态注册,后者也被称为静态注册。

动态注册监听时间变化

创建一个BroadcastReceiver其实只需新建一个类,让它继承自BroadcastReceiver,并重写父类的onReceive方法就行了。这样当有广播到来时,onReceive方法就会得到执行,具体的逻辑就可以在这个方法中处理。

下面先通过动态注册的方式编写一个能够监听时间变化的程序,体会BroadcastReceiver的基本用法。新建一个BroadcastTest项目,然后修改MainActivity中的代码。

如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class MainActivity : AppCompatActivity() {
inner class TimeChangeReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Toast.makeText(context, "Time has changed", Toast.LENGTH_SHORT).show()
}
}

lateinit var timeChangeReceiver: TimeChangeReceiver

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val intentFilter = IntentFilter()
intentFilter.addAction("android.intent.action.TIME_TICK")
timeChangeReceiver = TimeChangeReceiver()
registerReceiver(timeChangeReceiver, intentFilter)
}

override fun onDestroy() {
super.onDestroy()
unregisterReceiver(timeChangeReceiver)
}
}

在MainActivity中定义了一个内部类TimeChangeReceiver,这个类是继承自BroadcastReceiver的,并重写了父类的onReceive方法。这样每当系统时间发生变化时,onReceive方法就会得到执行,这里只是简单地使用Toast提示了一段文本信息。

然后观察onCreate方法,首先我们创建了一个IntentFilter的实例,并给它添加了一个值为android.intent.action.TIME_TICK的action,每当系统时间发生变化时,系统发出此值的广播。BroadcastReceiver想要监听什么广播,就在这里添加相应的action。

接下来创建了一个TimeChangeReceiver的实例,然后调用registerReceiver方法进行注册,将TimeChangeReceiver的实例和IntentFilter的实例都传了进去,这样TimeChangeReceiver就会收到所有值为android.intent.action.TIME_TICK的广播,也就实现了监听系统时间变化的功能。

最后要记得,一定要注销动态注册的BroadcastReceiver才行,在onDestroy方法中通过调用unregisterReceiver方法来实现。

现在运行一下程序,然后静静等待时间发生变化。系统每隔一分钟就会发出一条android.intent.action.TIME_TICK的广播,因此最多只需要等待一分钟就可以收到这条广播。

总结

接收其他系统广播的用法是一模一样的。Android 系统还会在亮屏熄屏、电量变化、网络变化等场景下发出厂播。完整的系统厂播列表到如下的路径中查看:<Android SDK>/platforms/<任意android api版本>/data/broadcast_actions.txt

静态注册实现开机启动

动态注册的BroadcastReceiver可以自由地控制注册与注销,在灵活性方面有很大的优势。但是它存在着一个缺点,即必须在程序启动之后才能接收广播,因为注册的逻辑是写在onCreate方法中的。

让程序在未启动的情况下也能接收广播需要使用静态注册的方式。从理论上来说,动态注册能监听到的系统广播,静态注册也应该能监听到,在过去的Android系统中确实是这样。但是由于大量恶意的应用程序利用这个机制在程序未启动的情况下监听系统广播,从而使任何应用都可以频繁地从后台被唤醒,严重影响了用户手机的电量和性能,因此Android系统几乎每个版本都在削减静态注册BroadcastReceiver的功能。

隐式广播

在Android 8.0系统之后,所有隐式广播都不允许使用静态注册的方式来接收了。隐式广播指的是那些没有具体指定发送给哪个应用程序的广播,大多数系统广播属于隐式广播,但是少数特殊的系统广播目前仍然允许使用静态注册的方式来接收。这些特殊的系统广播列表详见https://developer.android.google.cn/guide/components/broadcast-exceptions.html。

在这些特殊的系统广播当中,有一条值为android.intent.action.BOOT_COMPLETED的广播,是一条开机广播,用它来举例。

实现一个开机启动的功能。在开机的时候,应用程序肯定是没有启动的,因此这个功能显然不能使用动态注册的方式来实现,而应该使用静态注册的方式来接收开机广播,然后在onReceive方法里执行相应的逻辑,这样就可以实现开机启动的功能了。

1
2
3
4
5
class BootCompleteReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Toast.makeText(context, "Boot Complete", Toast.LENGTH_LONG).show()
}
}

静态的BroadcastReceiver一定要在AndroidManifest.xml文件中注册才可以使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.broadcasttest">
<application android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
...
<!-- + -->
<receiver
android:name=".BootCompleteReceiver"
android:enabled="true"
android:exported="true">
</receiver>
</appLication>
</manifest>

可以看到,<application>标签内出现了一个新的标签<receiver>所有静态的BroadcastReceiver都是在这里进行注册的。它的用法其实和<activity>标签非常相似,也是通过android:name指定具体注册哪一个BroadcastReceiver,Exported属性表示是否允许这个BroadcastReceiver接收本程序以外的广播,Enabled属性表示是否启用这个BroadcastReceiver。

不过目前的BootCompleteReceiver是无法收到开机广播的,还需要对AndroidManifest.xml文件进行修改才行,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.broadcasttest">
<!-- + -->
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<application android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:roundIcon="@mipmap/ic_launcher_round"
android:supportsRtl="true"
android:theme="@style/AppTheme">
...
<receiver
android:name=".BootCompleteReceiver"
android:enabled="true"
android:exported="true">
<!-- + -->
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
</appLication>
</manifest>

由于Android系统启动完成后会发出一条值为android.intent.action.BOOT_COMPLETED的广播,因此我们在<receiver>标签中又添加了一个<intent-filter>标签,并在里面声明了相应的action。

另外,Android系统为了保护用户设备的安全和隐私,做了严格的规定:如果程序需要进行一些对用户来说比较敏感的操作,必须在AndroidManifest.xml文件中进行权限声明。否则程序将会直接崩溃。比如这里接收系统的开机广播就是需要进行权限声明的,所以我们在上述代码中使用<uses-permission>标签声明了android.permission.RECEIVE_BOOT_COMPLETED——接收系统开机广播的权限。Android 6.0系统中引入了更加严格的运行时权限,从而能够更好地保证用户设备的安全和隐私。

重新运行程序,则程序已经可以接收开机广播了。重启设备,在启动完成之后就会收到开机广播。

总结

需要注意的是,不要在onReceive方法中添加过多的逻辑或者进行任何的耗时操作,因为BroadcastReceiver中是不允许开启线程的,当onReceive方法运行了较长时间而没有结束时,程序就会出现错误。

发送自定义广播

前面讲的是系统广播,现在看一下在应用程序中发送自定义的广播。

发送标准广播

在发送广播之前,我们还是需要先定义一个BroadcastReceiver来准备接收此广播,不然发出去也是白发。因此新建一个MyBroadcastReceiver,并在onReceive方法中加人如下代码:

1
2
3
4
5
class MyBroadcastReceiver : BroadcastReceiver() {
override fun onReceiver(context: Context, intent: Intent) {
Toast.makeText(context, "received in MyBroadcastReceiver", Toast.LENGTH_SHORT).show()
}
}

当MyBroadcastReceiver收到自定义的广播时。就会弹出"received in MyBroadcastReceiver"的提示。然后在AndroidManifest.xml中对这个BroadcastReceiver进行修改:

1
2
3
4
5
6
7
8
9
10
11
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<application
...>
<receiver android:name=".MyBroadcastReceiver"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="com.example.broadcasttest.MY_BROADCAST"/>
</intent-filter>
</receiver>
</application>

可以看到,这里让MyBroadcastReceiver接收一条值为com.example.broadcasttest.MY_BROADCAST的广播,因此待会儿在发送广播的时候,我们就需要发出这样的一条广播。

接下来修改activity_main.xml中的代码,如下:

1
2
3
4
5
6
7
8
9
10
11
12
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Send Broadcast">
</Button>

</LinearLayout>

这里在布局文件中定义了一个按钮。用于作为发送广播的触发点。

然后修改MainActivity中的代码,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class MyBroadcastReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Toast.makeText(context, "received in MyBroadcastReceiver",
Toast.LENGTH_LONG).show()
}
}
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val button: Button = findViewById(R.id.button)
button.setOnClickListener {
val intent = Intent("com.example.broadcasttest.MY_BROADCAST")
intent.setPackage(packageName)
sendBroadcast(intent)
}
}
}

可以看到,我们在按钮的点击事件里面加入了发送自定义广播的逻辑。

首先构建了一个Intent对象并把要发送的广播的值传入。然后调用Intent的setPackage方法,并传入当前应用程序的包名。packageName是getPackageName的语法糖写法,用于获取当前应用程序的包名。最后调用sendBroadcast方法将广播发送出去,这样所有监听com.example.broadcasttest.MY_BROADCAST这条广播的BroadcastReceiver就会收到消息了。

此时发出去的广播就是一条标准广播

对setPackage方法进行更详细的说明:前面已经说过,在Android8.0系统之后,静态注册的BroadcastReceiver是无法接收隐式广播的,而默认情况下我们发出的自定义广播恰恰都是隐式广播。因此这里一定要调用setPackage方法,指定这条广播是发送给哪个应用程序的,从而让它变成一条显式广播,否则静态注册的BroadcastReceiver将无法接收到这条广播。

现在重新运行程序并点击"Send Broadcast"按钮,即可看到效果。

另外,由于广播是使用Intent来发送的、因此你还可以在Intent中携带一些数据传递给相应的BroadcastReceiver,这一点和Activity的用法是比较相似的。

发送有序广播

和标准广播不同,有序广播是一种同步执行的广播,并且是可以被截断的。为了验证这一点,我们需要再创建一个新的BroadcastReceiver。新建AnotherBroadcastReceiver,代码如下所示:

1
2
3
4
5
6
class AnotherBroadcastReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Toast.makeText(context, "received in AnotherBroadcastReceiver",
Toast.LENGTH_SHORT).show()
}
}

很简单,这里仍然是在onReceive方法中弹出了一段文本信息。

然后在AndroidManifest.xml中对这个BroadcastReceiver的配置进行修改,代码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<application
...>
<receiver
android:name=".AnotherBroadcastReceiver"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="com.example.broadcasttest.MY_BROADCAST" />
</intent-filter>
</receiver>
</application>

可以看到,AnotherBroadcastReceiver同样接收的是com.example.broadcasttest.MY_BROADCAST这条广播。现在重新运行程序,并点击"Send Broadcast"按钮,就会分别弹出两次提示信息。

不过,到目前为止,程序发出的都是标准广播。现在我们来尝试一下发送有序广播。重新回到BroadcastTest项目,然后修改MainActivity中的代码,如下所示:

1
2
3
4
5
6
7
8
9
10
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val button: Button = findViewById(R.id.button)
button.setOnClickListener {
val intent = Intent("com.example.broadcasttest.MY_BROADCAST")
intent.setPackage(packageName)
// modify
sendOrderedBroadcast(intent, null)
}

可以看到,发送有序广播只需要改动一行代码,即将sendBroadcast方法改成sendOrderedBroadcast方法。send0rderedBroadcast方法接收两个参数:第一个参数仍然是Intent;第二个参数是一个与权限相关的字符串,这里传入null就行了。现在重新运行程序,并点击"Send Broadcast"按钮,你会发现,两个BroadcastReceiver仍然都可以收到这条广播。

看上去好像和标准广播并没有什么区别。不过别忘了,这个时候的BroadcastReceiver是有先后顺序的,而且前面的BroadcastReceiver还可以将广播截断,以阻止其继续传播。

设定BroadcastReceiver的先后顺序:在注册的时候进行设定。修改AndroidManifest.xml中的代码,如下所示:

1
2
3
4
5
6
7
8
9
<receiver
android:name=".MyBroadcastReceiver"
android:enabled="true"
android:exported="true">
<!-- + -->
<intent-filter android:priority="100">
<action android:name="com.example.broadcasttest.MY_BROADCAST"/>
</intent-filter>
</receiver>

可以看到,我们通过android:priority属性给BroadcastReceiver设置了优先级,优先级比较高的BroadcastReceiver就可以先收到广播。这里将MyBroadcastReceiver的优先级设成了100。以保证它一定会在AnotherBroadcastReceiver之前收到广播。

既然已经获得了接收广播的优先权,那么MyBroadcastReceiver就可以选择是否允许广播继续传递了。修改MyBroadcastReceiver中的代码,如下所示:

1
2
3
4
5
6
7
8
class MyBroadcastReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
Toast.makeText(context, "received in MyBroadcastReceiver",
Toast.LENGTH_SHORT).show()
// modify
abortBroadcast()
}
}

如果在onReceive方法中调用了abortBroadcast方法,就表示将这条广播截断,后面的BroadcastReceiver将无法再接收到这条广播。

现在重新运行程序,并点击"Send Broadcast"按钮,你会发现只有MyBroadcastReceiver中的Toast信息能够弹出,说明这条广播经过MyBroadcastReceiver之后确实终止传递了。

Linux_vim_"."命令

.命令

.命令可以让我们重复上次的修改,它是vim中最为强大的多面手。

首先我们要问∶"究竟什么是修改?"

"上次修改"可以指很多东西,一次修改的单位可以是字符、整行,甚至是整个文件。

例子:删除x、dd

x命令会删除光标下的字符,在这种情况下使用。命令"重复上次修改"时,就会让Vim删除光标下的字符。

image-20220831180112530

dd命令也做删除操作,但它会把整行一起删掉。如果在dd后使用、命令,那么"重复上次修改"会让 Vim删除当前行。

例子:缩进>G

最后,>G命令会增加从当前行到文档末尾处的缩进层级。如果在此命令后使用命令,那么"重复上次修改"会让Vim增加从当前行到文档末尾的缩进层级。在下例中,让光标从第二行开始(vim中,j代表向下,k代表向上,h代表向左,l代表向右),以便一目了然地看出差别。

image-20220831201942872

总结

j代表向下,k代表向上,h代表向左,l代表向右。

vim会记录每一个按键操作:.命令是一个微型的宏

xdd以及>命令都是在普通模式中执行的命令,不过,每次进入插入模式时,也会形成一次修改。从进入插入模式的那一刻起(例如,输入i),直到返回普通模式时为止(输入<Esc>),Vim会记录每一个按键操作。做出这样一个修改后再用命令的话,它将会重新执行所有这些按键操作(在插入模式中移动光标也会重置修改状态)。

vim可以录制任意数目的按键操作,然后在以后重复执行它们。这让我们可以把最常重复的工作流程录制下来,并用一个按键重放它们。可以把.命令当成一个很小的宏(macro)。

减少无关的移动

在每行的结尾添加一个分号。要实现这一点,先得把光标移到行尾,然后切换到插入模式进行修改。$命令可以完成移动动作,接着就可以执行a;<Esc>完成修改了。

要完成全部修改,需要对所有行做完全相同的操作,但是,由于命令可以重复上次的修改,因此不必重复之前的操作,而是执行两次j$.。一个.键顶3个a;<Esc>,虽然每次省得并不多,不过在重复操作时,累积效应可不小。

j命令使光标下移一行,而$命令把光标移到行尾。我们用了两下按键,仅仅是为了把光标移到指定位置,以便可以用.命令。应该还有改进的余地。

a命令在当前光标之后添加内容,A命令则在当前行的结尾添加内容。不管光标当前处于什么位置,输入A都会进入插入模式,并把光标移到行尾。换句话说,它把$a封装成了一个按键操作。Vim提供了不少这样的复合命令。

image-20220831210516363

A来代替$a,大大提升了.命令的效率。不必再把光标移到行尾,只需保证它位于该行内就行了(可在任意位置)。现在可以重复执行足够多次的j.,完成对后续行的修改。

一个键移动,另一个键操作,请留意这种应用模式,更多的例子中将看到它的身影。

虽然这一模式对这个简短的例子来说很好用,但它不是万能的。试想一下,如果我们不得不给连续50行添加分号,即便每修改一次输一次j,看起来也是一项很繁重的工作。

一箭双雕

我们可以这样说,A命令把两个动作($a)合并成了一次按键,不过它不是唯一一个这样的命令,很多Vim的单键命令都可以被看成两个或多个其他命令的组合,下表列出了类似的一些例子,找出它们之间别的共同点。

复合命令 等效的长命令
C c$
s cl
S ^C
` `
A $a
o A<CR>
O ko

比如:输入ko,等于输入了k$a<CR>

它们全都会从普通模式切换到插入模式。这对.命令可能产生影响。

使修改、移动可重复:;s命令

在一个字符前后各添加一个空格。以像下面这样在+号前后各添加一个空格,让肉眼更容易识别。

1
var foo = "method(" + argument1 + "," + argument2 + ")";

s命令把两个操作合并为一个:它先删除光标下的字符,然后进入插入模式。在删除+号后,先输入空格 + 空格,然后退出插入模式。

先后退一步,然后前进三步,这是个奇怪的小花招,看起来可能不够直接。但这样做最大的好处是:我们可以用.命令重复这一修改。我们所要做的只是把光标移到下一个+号处,然后用.命令重复这一操作即可。

但是移动光标到指定位置还是太麻烦了。

f{char}命令让Vim查找下一处指定字符出现的位置,如果找到了,就直接把光标移到那里。因此,输入f+时,光标会直接移到下一个+号所在的位置。

完成第一处修改后,可以重复按f+命令跳到下一个+号所在的位置。不过,还有一种更好的方法可以用:;命令会重复查找上次f命令所查找的字符,因此不用输入4次f+,而是只输入一次,后面跟着再用3次;命令。

;命令带我们到下一个目标字符上,.命令则重复上次的修改。因此,可以连续输入3次;.来完成全部修改。与其和Vim区分模式的编辑模型做斗争,倒不如与它一起协同工作。然后,就能把特定任务变得容易——在面对重复性工作时,我们需要让移动动作和修改都能够重复,这样就可以达到最佳编辑模式。

总结

  1. s键先删除光标下的字符,然后进入插入模式
  2. f{char}命令查找下一处指定字符出现的位置,如果找到了,就直接把光标移到那里
  3. ;命令会重复查找上次f命令所查找的字符
  4. .命令重复上次的修改

几对儿重复和回退

如果我们知道如何重复之前的操作,而无需每次都输入整条命令,那么就会获得更高的效率。可以先执行一次,随后只需重复即可。

然而,这么少的按键就可以完成这么多的事情,需要很小心地操作才行,不然就很容易出错。当一遍又一遍地连续按j.j.j.j,向下一行)时,那种感觉就像是在敲鼓。可是,如果不小心在一行上敲了两次j键,或敲了两次.键,就很麻烦。当Vim让一个操作或移动可以很方便地重复时,它总是会提供某种方式能回退回来。对命令而言,可以按u键撤销上次的修改。如果在使用f{char}命令后,不小心按了太多次;键,就会偏离我们的目标。不过可以再按,键跳回去,这个命令会反方向查找上次f{char}所查找的字符。

Vim中可重复执行的命令,以及相应的回退方式。

目的 操作 重复 回退
做出一个修改 {edit} . u
在行内查找下一指定字符 f{char}/t{char} ; ,
在行内查找上一指定字符 F{char}/T{char} ; ,
文档中查找下一处匹配字符串 /pattern<CR> n N
文档中查找上一处匹配字符串 ?pattern<CR> n N
执行替换 :s/target/replacement & u
执行一系列修改 qx{changes}q @x u

.范式

我们想在一系列行的结尾添加分号。我们先用A[进入插入模式] ;<Esc>修改了第一行,做完这步准备后,就可以使用.命令对后续行重复此修改。我们使用了j命令在行间移动,要完成剩余的修改,只需简单地按足够多次j.就可以了。

我们想为每个+号的前后各添加一个空格。先用f+命令跳到目标字符上,然后用s命令把一个字符替换成3个,做完这步准备后,就可以按若干次;.完成此任务。

我们想把每处出现单词"content"的地方都替换成"copy"。使用*命令来查找目标单词,然后用cw命令修改第一处地方。做完这步准备后,就可以用n键跳到下一匹配项,然后用.键做相同的修改。要完成这项任务,只需简单地按足够多次n.就行了。

理想模式:用一键移动,另一键执行

所有这些例子都利用.命令重复上次的修改,不过这不是它们唯一的共同点,另外的共同点是它们都只需要按一次键就能把光标移到下一个目标上。

用一次按键移动,另一次按键执行,再没有比这更好的了,这就是理想的解决方案。这一编辑模式,把它叫做".范式"。

总结

按键 作用
A 移到行尾并进入插入模式
j 光标向下一行
f{char} 光标移到下一个char字符
s 把光标下一个字符删除,进入插入模式
; 找下一个指定的字符
* 查找当前光标下的单词,并把光标移到下一个单词
cw 删除光标下的单词,进入插入模式

.命令记录的是从进入插入模式后,到退出插入模式输入的命令