Android组件

Android的RPC实现，如上图所示（好吧，也是从SDK中拿来主义的...），无甚稀奇，基于代理模式的一个实现，在调用端和服务端都去生成一个代理类，做一些序列化和反序列化的事情，使得调用端和服务器端都可以像调用一个本地接口一样使用RPC接口。

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的一些实现，也许不再会详述了。

在实际应用中，我们常需要等，等待系统抑或其他应用发出一道指令，为自己的应用擦亮明灯指明方向。而这种等待，在很多的平台上，都会需要付出不小的代价。

比如，在Symbian中，你要等待一个来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，消隐图标隐藏任务项，潜伏在后台，监控着相关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。

在Android中，充分考虑了广泛的这类需求，于是就有了 Broadcast Receiver这样的一个组件。每个Broadcast Receiver都可以接收一种或若干种Intent作为触发事件（有不知道Intent的么，后面会知道了...），当发生这样事件的时候，系统会负责唤醒或传递消息到该Broadcast Receiver，任其处置。在此之前和这以后，Broadcast Receiver是否在运行都变得不重要了，及其绿色环保。

这个实现机制，显然是基于一种 注册方式的，Broadcast Receiver将其特征描述并注册在系统中，根据注册时机，可以分为两类，被我冠名为 冷热插拔。所谓 冷插拔，就是Broadcast Receiver的相关信息写在配置文件中（求配置文件详情？稍安，后续奉上...），系统会负责在相关事件发生的时候及时通知到该Broadcast Receiver，这种模式适合于这样的场景。 某事件方式 -> 通知Broadcast -> 启动相关处理应用。比如，监听来电、邮件、短信之类的，都隶属于这种模式。而 热插拔，顾名思义，插拔这样的事情，都是由应用自己来处理的，通常是在OnResume事件中通过 registerReceiver进行注册，在OnPause等事件中反注册，通过这种方式使其能够在运行期间保持对相关事件的关注。比如，一款优秀的词典软件（比如， 有道词典...），可能会有在运行期间关注网络状况变化的需求，使其可以在有廉价网络的时候优先使用网络查询词汇，在其他情况下，首先通过本地词库来查词，从而兼顾腰包和体验，一举两得一石二鸟一箭双雕（注，真实在有道词典中有这样的能力，但不是通过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，听着就和数据相关，没错，这就是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屏蔽了内部数据的存储细节，向外提供了上述统一的接口模型，这样的抽象层次，大大简化了上层应用的书写，也对数据的整合提供了更方便的途径。Content Provider内部，常用数据库来实现，Android提供了强大的 Sqlite支持，但很多时候，你也可以封装文件或其他混合的数据。

在Android中， ContentResolver是用来发起Content Provider的定位和访问的。不过它仅提供了同步访问的Content Provider的接口。但通常，Content Provider需要访问的可能是数据库等大数据源，效率上不足够快，会导致调用线程的拥塞。因此Android提供了一个 AsyncQueryHandler（参见： reference/android/content/AsyncQueryHandler.html），帮助进行异步访问Content Provider。

在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供 异步访问的接口，而Content Provider不论效率如何，都提供的是约定的 同步访问接口。我想这遵循的就是 场景导向设计的原则，因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据；而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。

四大组件说完了，四大组件幕后的英雄也该出场了，那就是每个应用都会有一份的配置文件，名称是 AndroidManifest.xml，在工程的根目录下。在这个配置文件中，不仅会描述一些应用相关的信息，很重要的，会包含一个应用中所有组件的信息。如果你派生Activity或者Service实现了一个相关的类，这只是把它组件化的第一步，你需要把这个类的相关信息写到配置文件中，它才会作为一个组件被应用到，否则只能默默无闻的黯淡度过余生。