3.4　触发器组件Broadcast Receiver解析

对于Android应用而言，不仅需要通过界面直接和用户打交道，及时处理用户的请求，还需要监听系统或系统中其他应用发生的事件，做出响应。

最常见的场景就是很多应用都监听系统的开机事件。当设备开机时，应用需要检查数据的变化状况，把一些新消息通知给用户。在Android中，类似的事件监听工作都是通过触发器组件来实现的。

从实现来看，所谓的触发器组件，是派生自android.content.BroadcastReceiver的子类型，它的实现集中在BroadcastReceiver.onReceive方法中，典型实现如下：

//子类com.duguhome.test.SimpleBroadcastReceiver

public class SimpleBroadcastReceiver extends

BroadcastReceiver{

@Override

Protected void onReceive（Intent intent）{

//对Intent消息进行处理

…

}

}

//在配置文件中添加组件信息

…

＜application…＞

＜receiver android：name="SimpleBroadcastReceiver"＞

…#此处可以添加Intent filter信息

＜/receiver＞

＜/application＞

以上的实现，几乎是触发器组件的全部。从实现的复杂度和代码量来看，触发器组件无疑是最迷你的Android组件，它的实现代码往往是寥寥数行。因此，对于触发器组件而言，开发绝对谈不上难度，关键在于理解它的功能和特征，学会正确地使用它。

3.4.1　触发器组件的功能和特征

Android的触发器组件，在工作方式上更接近于函数，而不是对象。典型的对象不仅包括算法逻辑，还包含一些用于存储数据的成员变量，但触发器组件对象被构造出来后，通常只执行BroadcastReceiver.onReceive方法，便结束了其生命周期。因此，在使用触发器组件时，只能够把它当作一个函数来使用。除了一些初始构造时传入的成员变量，^[1]其余都没有用武之地，不会有机会被用到。

和所有组件一样，触发器组件对象也是在应用进程的主线程中被构造，因此，其功能函数BroadcastReceiver.onReceive的执行必须是同步且快速的，否则会阻塞与用户交互的当前进程，影响用户的体验。常见的触发器组件使用模式如图3-11所示，当触发器接收到相关的广播事件消息（载体同样是Intent对象）时，会针对事件类型做简单的判断和处理，接着，或利用Android的通知机制（Notification）将相关消息通知给用户，或通过Context.startActivity函数展示相关界面组件与用户进行交互，或是利用Context.startService函数调用对应的服务组件进行后续的复杂处理。

图　3-11　Android触发器组件工作模式

触发器组件的设计，解决了应用开发中一个很重要的问题，就是后台事件的监听。这项工作在其他平台往往是一件吃力不讨好的事情。比如，在Symbian中做一个来电归属地提示之类的应用，就必须让该应用进程始终运行着，并一直在后台默默地等待着相关事件的发生。为了防止用户意外关闭，进程还需要想方设法隐藏运行的痕迹。这样不但白白耗费了系统资源，还使得应用落下了流氓软件的骂名。

而在Android中，只有当事件真正发生时，组件管理服务才会根据配置信息通知对应的触发器组件对象，构造执行组件的进程。这样不但节约了系统的开销，而且还极大地降低了开发的复杂性。

[1]在热插拔的模式下，开发者可以自行定义触发器组件的构造函数，传入所需的变量；但如果是冷插拔的触发器组件，则必须使用默认的构造函数。