Android

中 用 来 做 数 据 序 列 化 的 类 是

Parcel ， 参 见 ：

/reference/android/os/Parcel.html，封装了序列化的细节，向外提供了足够对象化的访

问 接 口，

Android 号称实现非常高效。

还有就是 AIDL (Android Interface Definition 

Language) 

，一种接口定义的语言，服务的 RPC 接口，可以用 AIDL 来描述，这样，ADT

就可以帮助你自动生成一整套的代理模式需要用到的类，都是想起来很乏力写起来很苦力的
那种。更多内容，可以再看看：guide/developing/tools/aidl.html，如果有兴致，可以找
些其他 PRC 实现的资料 lou 几眼。

关 于 Service 的 实 现 ， 还 强 推 参 看 API  Demos 这 个 Sample 里 面 的

RemoteService

实现。它完整的展示了实现一个 Service 需要做的事情：那就是定义好需

要接受的

Intent，提供同步或异步的接口，在上层绑定了它后，通过这些接口（很多时候都

是

RPC 的...）进行通信。在 RPC 接口中使用的数据、回调接口对象，如果不是标准的系统实

现（系统可序列化的），则需要自定义

aidl，所有一切，在这个 Sample 里都有表达，强荐

Service 从实现角度看，最特别的就是这些 RPC 的实现了，其他内容，都会接近于 Activity

的一些实现，也许不再会详述了。

Broadcast Receiver

在实际应用中，我们常需要等，等待系统抑或其他应用发出一道指令，为自己的应

用擦亮明灯指明方向。而这种等待，在很多的平台上，都会需要付出不小的代价。比如，在

Symbian 中，你要等待一个来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷

偷摸摸的开机启动，消隐图标隐藏任务项，潜伏在后台，监控着相关事件，等待转瞬即逝的

出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，

这真是卖力不讨好的正面典型。

在 Android 中，充分考虑了广泛的这类需求，于是就有了 Broadcast Receiver 这

样的一个组件。每个 Broadcast Receiver 都可以接收一种或若干种 Intent 作为触发事件
（有不知道 Intent 的么，后面会知道了...），当发生这样事件的时候，系统会负责唤醒或传
递消息到该 Broadcast Receiver，任其处置。在此之前和这以后，Broadcast Receiver
是否在运行都变得不重要了，及其绿色环保。这个实现机制，显然是基于一种注册方式的，
Broadcast Receiver 将其特征描述并注册在系统中，根据注册时机，可以分为两类，被我

冠名为冷热插拔。

所谓冷插拔，就是 Broadcast Receiver 的相关信息写在配置文件中（求

配置文件详情？稍安，后续奉上...），系统会负责在相关事件发生的时候及时通知到该
Broadcast Receiver

，这种模式适合于这样的场景。某事件方式 -> 通知 Broadcast -> 

启动相关处理应用。比如，监听来电、邮件、短信之类的，都隶属于这种模式。而热插拔，顾
名思义，插拔这样的事情，都是由应用自己来处理的，通常是在

 OnResume 事件中通过

registerReceiver 进行注册，在 OnPause 等事件中反注册，通过这种方式使其能够在运行

期间保持对相关事件的关注。比如，一款优秀的词典软件（比如，有道词典

...），可能会有在

运行期间关注网络状况变化的需求，使其可以在有廉价网络的时候优先使用网络查询词汇，