前文曾分析过ServiceManager的作用，一个Client想要得到某个Service的信息，就必须先和ServiceManager打交道，通过调用getService函数来获取对应Service的信息。请看来源于IMediaDeathNotifier.cpp中的例子getMediaPlayerService()，它的代码如下所示： **IMediaDeathNotifier.cpp** ~~~ /* 这个函数通过与ServiceManager通信，获得一个能够与MediaPlayerService通信的BpBinder， 然后再通过障眼法interface_cast，转换成一个BpMediaPlayerService。 */ IMediaDeathNotifier::getMediaPlayerService() { sp<IServiceManager> sm = defaultServiceManager(); sp<IBinder> binder; do { //向ServiceManager查询对应服务的信息，返回BpBinder。 binder = sm->getService(String16("media.player")); if(binder != 0) { break; } //如果ServiceManager上还没有注册对应的服务，则需要等待，直到对应服务注册 //到ServiceManager中为止。 usleep(500000); }while(true); /* 通过interface_cast，将这个binder转化成BpMediaPlayerService， binder中的handle标识的一定是目的端MediaPlayerService。 */ sMediaPlayerService = interface_cast<IMediaPlayerService>(binder); } returnsMediaPlayerService; } ~~~ 有了BpMediaPlayerService，就能够使用任何IMediaPlayerService提供的业务逻辑函数了。例如createMediaRecorder和createMetadataRetriever等。 显而易见的是，调用的这些函数都将把请求数据打包发送给Binder驱动，由BpBinder中的handle值找到对应端的处理者来处理。这中间经历过如下的过程： （1）通讯层接收到请求。 （2）递交给业务层处理。 想了解这中间的过程吗？下面就对此做详细分析。