在其他情况下，首先通过本地词库来查词，从而兼顾腰包和体验，一举两得一石二鸟一箭双
雕（注，真实在有道词典中有这样的能力，但不是通过

 Broadcast Receiver 实现的，仅以

为例

...）。而这样的监听，只需要在其工作状态下保持就好，不运行的时候，管你是天大的网

路变化，与我何干。其模式可以归结为：启动应用

 -> 监听事件 -> 发生时进行处理。除了接

受消息的一方有多种模式，发送者也有很重要的选择权。通常，发送这有两类，一个就是系

统本身，我们称之为系统

Broadcast 消息，在 reference/android/content/Intent.html 

的

Standard Broadcast Actions，可以求到相关消息的详情。除了系统，自定义的应用可

以 放 出

Broadcast 消 息 ， 通 过 的 接 口 可 以 是   Context.sendBroadcast ， 抑 或 是

Context.sendOrderedBroadcast。前者发出的称为 Normal broadcast，所有关注该消息

的

Receiver，都有机会获得并进行处理；后者放出的称作 Ordered broadcasts，顾名思

义，接受者需要按资排辈，排在后面的只能吃前面吃剩下的，前面的心情不好私吞了，后面

的只能喝西北风了。当

Broadcast Receiver 接收到相关的消息，它们通常做一些简单的处

理，然后转化称为一条

Notification，一次振铃，一次震动，抑或是启动一个 Activity 进行

进一步的交互和处理。所以，

虽然 Broadcast 整个逻辑不复杂，却是足够有用和好用，它统

一了 Android 的事件广播模型，让很多平台都相形见绌了。更多 Broadcast Receiver 相关
内容，参见：/reference/android/content/BroadcastReceiver.html。

Content Provider

Content Provider，听着就和数据相关，没错，这就是 Android 提供的第三方应

用数据的访问方案。在

Android 中，对数据的保护是很严密的，除了放在 SD 卡中的数据，

一个应用所持有的数据库、文件、等等内容，都是不允许其他直接访问的，但有时候，沟通是

必要的，不仅对第三方很重要，对应用自己也很重要。比如，一个联系人管理的应用。如果不

允许第三方的应用对其联系人数据库进行增删该查，整个应用就失去了可扩展力，必将被其

他应用抛弃，然后另立门户，自个玩自个的去了。

Andorid 当然不会真的把每个应用都做成

一座孤岛，它为所有应用都准备了一扇窗，这就是

Content Provider。

应用想对外提供的数

据，可以通过派生 ContentProvider 类， 封装成一枚 Content Provider，每个 Content 
Provider

都用一个 uri 作为独立的标识，形如：content://com.xxxxx。所有东西看着像

REST 的样子，但实际上，它比 REST 更为灵活。和 REST 类似，uri 也可以有两种类型，一

种是带

id 的，另一种是列表的，但实现者不需要按照这个模式来做，给你 id 的 uri 你也可以

返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的

REST。

另外，Content 

Provider

不和 REST 一样只有 uri 可用，还可以接受 Projection，Selection，OrderBy 等

参数，这样，就可以像数据库那样进行投影，选择和排序。查询到的结果，以 Cursor（参
见：reference/android/database/Cursor.html  ）的形式进行返回，调用者可以移动
Cursor

来访问各列的数据。

Content Provider 屏蔽了内部数据的存储细节，向外提供了上述统一的接口模型，

这样的抽象层次，大大简化了上层应用的书写，也对数据的整合提供了更方便的途径 。