上文《Android系统的Binder机制之一——Service Manager》我们学习了Service Manager在Android Binder中的作用——服务（Service）注册，服务（Service）查询的功能。本文我们一起学习服务（Service）在客户端中的代理机制。重点介绍其核心对象BpBinder。
1、服务代理的原理
如下是客户端请求service服务的场景：
1、首先客户端向Service manager查找相应的Service。上文《Android系统的Binder机制之一——Service Manager》有比较详细的介绍。注意客户端和Service可能在两个不同的进程中。
2、Android系统将会为客户端进程中创建一个Service代理。下文将详细介绍该创建过程。
3、客户端视角只有Service代理，他所有对Service的请求都发往Service代理，然后有Service代理把用户请求转发给Service本身。Service处理完成之后，把结果返回给Service代理，Service代理负责把处理结果返回给客户端。注意客户端对Service代理的调用都是同步调用（调用挂住，直到调用返回为止），这样客户端视角来看调用远端Service的服务和调用本地的函数没有任何区别。这也是Binder机制的一个特点。
2、Android进程环境——ProcessState类型和对象
在Android系统中任进程何，要想使用Binder机制，必须要创建一个ProcessState对象和IPCThreadState对象。当然如果Android进程不使用Binder机制，那么这两个对象是不用创建的。这种情况很少见，因为Binder机制是整个Android框架的基础，可以说影响到Android方方面面。所以说了解这两个对象的作用非常重要。
台湾的高焕堂先生一片文章《认识ProcessState类型和对象》，可以在我的博文《（转）高焕堂——Android框架底层结构知多少？》中找到。可以先通过这篇文章对ProcessState进行一个大概了解。
ProcessState是一个singleton类型，一个进程只能创建一个他的对象。他的作用是维护当前进程中所有Service代理（BpBinder对象）。一个客户端进程可能需要多个Service的服务，这样可能会创建多个Service代理（BpBinder对象），客户端进程中的ProcessState对象将会负责维护这些Service代理。
我们研究一下创建一个Service代理的代码：
1: sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
2: {
3: sp<IBinder> result;
4:
5: AutoMutex _l(mLock);
6:
7: handle_entry* e = lookupHandleLocked(handle);
8:
9: if (e != NULL) {
10: // We need to create a new BpBinder if there isn't currently one, OR we
11: // are unable to acquire a weak reference on this current one. See comment
12: // in getWeakProxyForHandle() for more info about this.
13: IBinder* b = e->binder;
14: if (b == NULL || !e->refs->attemptIncWeak(this)) {
15: b = new BpBinder(handle);
16: e->binder = b;
17: if (b) e->refs = b->getWeakRefs();
18: result = b;
19: } else {
20: // This little bit of nastyness is to allow us to add a primary
21: // reference to the remote proxy when this team doesn't have one
22: // but another team is sending the handle to us.
23: result.force_set(b);
24: e->refs->decWeak(this);
25: }
26: }
27:
28: return result;
29: }
当前进程首先调用lookupHandleLocked函数去查看当前进程维护的Service代理对象的列表，该待创建Service代理对象是否已经在当前进程中创建，如果已经创建过了，则直接返回其引用就可以了。否则将会在Service代理对象的列表增加相应的位置（注意系统为了减少分配开销，可能会多分配一些空间，策略是“以空间换时间”），保存将要创建的代理对象。具体代码请参考lookupHandleLocked的源码。
后面代码就好理解了，如果Service代理对象已经创建过了，直接增加引用计数就行了。若没有创建过，则需要创建一个新的Service代理对象。
3、Android进程环境——IPCThreadState类型和对象
Android进程中可以创建一个ProcessState对象，该对象创建过程中会打开/dev/binder设备，并保存其句柄。并初始化该设备。代码如下：
1: ProcessState::ProcessState()
2: : mDriverFD(open_driver())
3: , mVMStart(MAP_FAILED)
4: , mManagesContexts(false)
5: , mBinderContextCheckFunc(NULL)
6: , mBinderContextUserData(NULL)
7: , mThreadPoolStarted(false)
8: , mThreadPoolSeq(1)
9: {
10: if (mDriverFD >= 0) {
11: // XXX Ideally, there should be a specific define for whether we
12: // have mmap (or whether we could possibly have the kernel module
13: // availabla).
14: #if !defined(HAVE_WIN32_IPC)
15: // mmap the binder, providing a chunk of virtual address space to receive transactions.
16: mVMStart = mmap(0, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE | MAP_NORESERVE, mDriverFD, 0);
17: if (mVMStart == MAP_FAILED) {
18: // *sigh*
19: LOGE("Using /dev/binder failed: unable to mmap transaction memory./n");
20: close(mDriverFD);
21: mDriverFD = -1;
22: }
23: #else
24: mDriverFD = -1;
25: #endif
26: }
27: if (mDriverFD < 0) {
28: // Need to run without the driver, starting our own thread pool.
29: }
30: }
1: friend class IPCThreadState;
IPCThreadState也是一个singleton的类型，一个进程中也只能有一个这样的对象。我们查看一下它的talkWithDriver函数：
1: ...........
2: if (ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
3: err = NO_ERROR;
4: else
5: err = -errno;
6: ...........
1、维护当前进程中所有对/dev/binder的读写。换句话说当前进程通过binder机制进行跨进程调用都是通过IPCThreadState对象来完成的。
2、 IPCThreadState也可以理解成/dev/binder设备的封装，用户可以不直接通过ioctl来操作binder设备，都通过IPCThreadState对象来代理即可。
4、Service代理对象BpBinder
1: BpBinder::BpBinder(int32_t handle)
2: : mHandle(handle)
3: , mAlive(1)
4: , mObitsSent(0)
5: , mObituaries(NULL)
6: {
7: LOGV("Creating BpBinder %p handle %d/n", this, mHandle);
8:
9: extendObjectLifetime(OBJECT_LIFETIME_WEAK);
10: IPCThreadState::self()->incWeakHandle(handle);
11: }
客户进程对Service的请求都通过调用BpBinder的transact方法来完成：
1: status_t BpBinder::transact(
2: uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
3: {
4: // Once a binder has died, it will never come back to life.
5: if (mAlive) {
6: status_t status = IPCThreadState::self()->transact(
7: mHandle, code, data, reply, flags);
8: if (status == DEAD_OBJECT) mAlive = 0;
9: return status;
10: }
11:
12: return DEAD_OBJECT;
13: }
5、Android系统对Binder机制的抽象——IBinder
上面我们讲解了Binder机制比较底层的机制，这些机制直接用还是比较麻烦的，比如使用binder设备的ioctl，需要记住很多ioctl的代码。
Android为了是Binder机制容易使用，对Binder机制进行了抽象，定义了IBinder接口，该接口在C/C++和Java层都有定义。IBinder定义了一套使用Binder机制使用和实现客户程序和服务器的通讯协议。可以理解如下定义：
1、向Android注册的Service也必须是IBinder（继承扩展IBinder接口）对象。后续文章中我们讨论Service的时候我们会介绍到这方面的内容。
2、客户端得到Service代理对象也必须定义成IBinder（继承扩展IBinder接口）对象。这也是为什么BpBinder就是继承自IBinder。3、客户端发送请求给客户端，调用接口的Service代理对象IBinder接口的transact方法。
4、Android系统Binder机制将负责把用户的请求，调用Service对象IBinder接口的onTransact方法。具体实现我们将在以后介绍Service的时候讨论。
6、Service Manager代理对象
我们知道Service Manager是Android Binder机制的大管家。所有需要通过Binder通讯的进程都需要先获得Service Manager的代理对象才能进行Binder通讯。Service Manager即在C/C++层面提供服务代理，又在Java层面提供服务代理，本文先介绍一下C/C++层面的服务代理，Java层面的服务代理将在后续文章中介绍。
进程在C/C++层面上面，Android在Android命名空间中定义了一个全局的函数defaultServiceManager（定义在framework/base/libs/binder），通过这个函数可以使进程在C/C++层面获得Service Manager的代理。我们先看一下该函数的定义：
1: sp<IServiceManager> defaultServiceManager()
2: {
3: if (gDefaultServiceManager != NULL) return gDefaultServiceManager;
4:
5: {
6: AutoMutex _l(gDefaultServiceManagerLock);
7: if (gDefaultServiceManager == NULL) {
8: gDefaultServiceManager = interface_cast<IServiceManager>(
9: ProcessState::self()->getContextObject(NULL));
10: }
11: }
12:
13: return gDefaultServiceManager;
14: }
我们可以看到defaultServiceManager是调用ProcessState对象的getContextObject方法获得Service Manager的getContextObject方法获得Service Manager代理对象。我们再看一下getContextObject函数的定义：
1: sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
2: {
3: if (supportsProcesses()) {
4: return getStrongProxyForHandle(0);
5: } else {
6: return getContextObject(String16("default"), caller);
7: }
8: }
我们可以看出其实是调用我们上面描述过的getStrongProxyForHandle方法，并以句柄0为参数来获得Service Manager的代理对象。
ProcessState::self()->getContextObject(NULL)返回一个IBinder对象，怎样把它转化成一个IServiceManager的对象呢？这就是模板函数interface_cast<IServiceManager>的作用了。调用的是IServiceManager.asInterface方法。IServiceManager的asInterface方法通过DECLARE_META_INTERFACE和IMPLEMENT_META_INTERFACE宏来定义，详细情况请查看IServiceManager类的定义。IMPLEMENT_META_INTERFACE宏关于asInterface的定义如下：
1: android::sp<I##INTERFACE> I##INTERFACE::asInterface( /
2: const android::sp<android::IBinder>& obj) /
3: { /
4: android::sp<I##INTERFACE> intr; /
5: if (obj != NULL) { /
6: intr = static_cast<I##INTERFACE*>( /
7: obj->queryLocalInterface( /
8: I##INTERFACE::descriptor).get()); /
9: if (intr == NULL) { /
10: intr = new Bp##INTERFACE(obj); /
11: } /
12: } /
13: return intr; /
14: } /
最终asInterface将会用一个IBinder对象创建一个BpServiceManager对象，并且BpServiceManager继承自IServiceManager，这样我们就把IBinder对象转换成了IServiceManager对象。如果你仔细查看BpServiceManager的定义，你会发现查询Service，增加Service等方法其实都是调用底层的IBinder对象来完成的。
当我们在C/C++层面编写程序使用Binder机制的时候将会调用defaultServiceManager函数来获得Service Manager，比如：很多Android系统Service都是在C/C++层面实现的，他们就需要向Service Manager注册其服务，那么这些服务将调用defaultServiceManager获得Service Manager代理对象。我们在后续介绍Android系统Service的时候将会详细介绍。
7、总结
本文中我们介绍了C++层面的Service代理，后续文章我们将介绍Java层面的Service代理。
Android进程的C/C++层面和Java层
Android中程序大部分都是java开发，底层通过JNI调用C/C++的代码。这样一个程序就分为了两个层面C/C++层面和Java层面。运行状态下，我们说它们都在一个进程之中，拥有相同的进程属性（UID，GID等等）。
Binder客户程序的C/C++层面的对象和原理我们在上文《Android系统的Binder机制之二——服务代理对象（1）》已经学习。下面我们将介绍客户程序怎样在Java层面通过JNI调用底层C/C++代码的创建服务代理。
ServiceManager类型和对象
我在《Android系统的Binder机制之一——Service Manager》中介绍过，客户端要想获得服务代理，首先要向ServiceManager查询Service。在Java层面也是这样，所以我们首先分析Java层面ServiceManager类。
我们通过查看ServiceManager的源码我们发现，ServiceManager类型也是一个Singleton类型。所有的方法都是静态方法，所有静态方法都是访问它的IServiceManager类型的静态变量sServiceManager，定义如下：
1: private static IServiceManager sServiceManager;
所以可以理解ServiceManager就是IServiceManager对象的一个代理。为创建和访问这个变量都是通过ServiceManager的getIServiceManager方法，定义如下：
1: private static IServiceManager getIServiceManager() {
2: if (sServiceManager != null) {
3: return sServiceManager;
4: }
5:
6: // Find the service manager
7: sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
8: return sServiceManager;
9: }
通过上面的代码，非常清晰的告诉我们ServiceManager类型是一个Singleton类型。现在我们主要研究sServiceManager对象怎样创建的。如下代码创建IServiceManager对象：
1: sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
我们首先查看BinderInternal类的getContextObject方法的代码，发现是Native代码（哈哈！有终于到达C/C++层面了，我们已经熟悉了），对应的代码为android_util_binder.cpp中的android_os_BinderInternal_getContextObject函数，代码如下：
1: static jobject android_os_BinderInternal_getContextObject(JNIEnv* env, jobject clazz)
2: {
3: sp<IBinder> b = ProcessState::self()->getContextObject(NULL);
4: return javaObjectForIBinder(env, b);
5: }
终于看到我们上文《Android系统的Binder机制之二——服务代理对象（1）》介绍过的ProcessState对象了，我们再去查看ProcessState对象的getContextObject方法，代码如下：
1: sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& caller)
2: {
3: if (supportsProcesses()) {
4: return getStrongProxyForHandle(0);
5: } else {
6: return getContextObject(String16("default"), caller);
7: }
8: }
我们看到在当前进程的ProcessState对象其实是调用getStrongProxyForHandle方法来创建binder句柄为0的服务代理对象——BpBinder对象，我们在《Android系统的Binder机制之一——Service Manager》提到过ServiceManager的binder句柄是一个闻名句柄0。上文《Android系统的Binder机制之二——服务代理对象（1）》已经介绍过ProcessState对象的getStrongProxyForHandle方法，这里就不多说了。
我们可以看出Java调用C/C++，创建一个服务代理对象BpBinder，在查看BpBinder的定义我们发现继承自IBinder接口，然后在android_util_binder.cpp中的方法android_os_BinderInternal_getContextObject中，把C/C++层面的IBinder对象封装成Java层面的IBinder对象。具体实现可以查看上文的android_os_BinderInternal_getContextObject方法。
至此我们已经清楚BinderInternal.getContextObject()，返回的是ServiceManager的服务代理对象——BpBinder对象。那么ServiceManagerNative类的静态方法asInterface做什么用呢？我们还是通过代码来分析，在ServiceManagerNative.java中，asInterface的代码如下：
1: static public IServiceManager asInterface(IBinder obj)
2: {
3: if (obj == null) {
4: return null;
5: }
6: IServiceManager in =
7: (IServiceManager)obj.queryLocalInterface(descriptor);
8: if (in != null) {
9: return in;
10: }
11:
12: return new ServiceManagerProxy(obj);
13: }
将会用IBinder对象创建一个ServiceManagerProxy对象，ServiceManagerProxy类型继承了IServiceManager接口，所以asInterface方法最终目的是用一个IBinder对象创建一个IServiceManager对象。
为什么要用IBinder对象创建一个IServiceManager对象呢？通过ServiceManager的代理对象——IBinder对象（BpBinder对象）应该可以直接请求ServiceManager中的服务了啊？我们在前文《Android系统的Binder机制之二——服务代理对象（1）》简单介绍了一下IBinder类型，客户端通过transact方法向Service发送请求，客户端的onTransact被调用处理客户端的请求，请求通过请求代码来区分。具体请参考Android手册。如果客户端直接用调用ServiceManager的代理对象的IBinder接口，那么客户端必须要记住所有请求的请求代码，对客户端来说不太友好。所以在ServiceManagerNative类中就把ServiceManager的代理对象——IBinder对象（BpBinder对象）封装成ServiceManagerProxy对象，暴露给客户程序一个IServiceManager接口，这样IServiceManager对象将会代理客户程序发往ServiceManager的代理对象的请求。并且是调用IServiceManager对象的方法来给ServiceManager发送请求，这样对客户程序来讲和本地的函数调用是一致的，接口非常友好。比如我们客户程序需要调用IServiceManager的getService方法来查询一个Service，ServiceManagerProxy实现代码如下：
1: public IBinder getService(String name) throws RemoteException {
2: Parcel data = Parcel.obtain();
3: Parcel reply = Parcel.obtain();
4: data.writeInterfaceToken(IServiceManager.descriptor);
5: data.writeString(name);
6: mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
7: IBinder binder = reply.readStrongBinder();
8: reply.recycle();
9: data.recycle();
10: return binder;
11: }
我们可以非常清晰的看到ServiceManagerProxy对象将客户程序的请求转换成对ServiceManager代理对象——IBinder对象（BpBinder对象）的调用。后文我们将会详细介绍怎样通过IServiceManager查询和获得一个系统Service代理对象。
到这里我们已经分析完了，ServiceManager的Singleton对象——sServiceManager的创建。如果有不清楚的地方请查看代码。
查询和获得Service代理对象
客户程序通过调用ServiceManager类型的静态方法asInterface获得了IServiceManager对象，但是最终目的一般都是要查询和获得其他的Service，一般都是要调用IServiceManager的getService方法，向ServiceManager获得其他的Service。比如：
1: IBinder b = ServiceManager.getService(Context.NETWORKMANAGEMENT_SERVICE);
上面的代码中就是调用ServiceManager的静态方法获得网络管理服务代理对象。我们顺藤摸瓜，看看系统是怎样生成这个Service代理对象的。这里只是简单说明一下调用顺序，详细过程请查看源码。
1、调用ServiceManager.java中的ServiceManager静态方法getService。
2、调用ServiceManagerNative.java中的ServiceManagerProxy方法getService。代码如下：
1: public IBinder getService(String name) throws RemoteException {
2: Parcel data = Parcel.obtain();
3: Parcel reply = Parcel.obtain();
4: data.writeInterfaceToken(IServiceManager.descriptor);
5: data.writeString(name);
6: mRemote.transact(GET_SERVICE_TRANSACTION, data, reply, 0);
7: IBinder binder = reply.readStrongBinder();
8: reply.recycle();
9: data.recycle();
10: return binder;
11: }
请注意IBinder的transact方法是同步方法（本例中ServiceManager处理完成请求之后才会返回），我们可以看出调用transact之后，调用reply.readStrongBinder()来读取IBinder对象。
3、查看Parcel.java中的readStrongBinder方法，发现是Native方法，将会调用到C/C++的代码。
4、查看android_util_binder.cpp中的android_os_Parcel_readStrongBinder函数。代码如下：
1: static jobject android_os_Parcel_readStrongBinder(JNIEnv* env, jobject clazz)
2: {
3: Parcel* parcel = parcelForJavaObject(env, clazz);
4: if (parcel != NULL) {
5: return javaObjectForIBinder(env, parcel->readStrongBinder());
6: }
7: return NULL;
8: }
parcel->readStrongBinder()将会产生一个IBinder对象。
5、查看Parcel.cpp中，Parcel的方法readStrongBinder。代码如下：
1: sp<IBinder> Parcel::readStrongBinder() const
2: {
3: sp<IBinder> val;
4: unflatten_binder(ProcessState::self(), *this, &val);
5: return val;
6: }
6、查看Parcel.cpp中，Parcel的方法unflatten_binder。代码如下：
1: status_t unflatten_binder(const sp<ProcessState>& proc,
2: const Parcel& in, sp<IBinder>* out)
3: {
4: const flat_binder_object* flat = in.readObject(false);
5:
6: if (flat) {
7: switch (flat->type) {
8: case BINDER_TYPE_BINDER:
9: *out = static_cast<IBinder*>(flat->cookie);
10: return finish_unflatten_binder(NULL, *flat, in);
11: case BINDER_TYPE_HANDLE:
12: *out = proc->getStrongProxyForHandle(flat->handle);
13: return finish_unflatten_binder(
14: static_cast<BpBinder*>(out->get()), *flat, in);
15: }
16: }
17: return BAD_TYPE;
18: }
终于看到调用我们的老朋友ProcessState对象的getStrongProxyForHandle方法了，这样将会创建一个BpBinder对象，然后该BpBinder对象将会被转换成IBinder对象返回给Java层。
7、Java层为了用使用Service方便，可以把Service代理对象——BpBinder对象（IBinder对象）封装成一个对客户程序友好的代理对象，就如前面ServiceManagerProxy所示那样。
8、用户程序就可以通过该代理对象访问相应Service了。
通过所述，我们了解了Service代理对象在Java层的创建和使用。Android系统的Binder机制博大精深，我在本文中很多方面都是蜻蜓点水，如果想深入学习请参阅Android的源码。
1、系统Service实例——Media server
首先我们先看一下Android一个实例Media Service，代码位于framework/base/media/mediaserver/main_mediaserver.cpp文件：
1: // System headers required for setgroups, etc.
2: #include <sys/types.h>
3: #include <unistd.h>
4: #include <grp.h>
5:
6: #include <binder/IPCThreadState.h>
7: #include <binder/ProcessState.h>
8: #include <binder/IServiceManager.h>
9: #include <utils/Log.h>
10:
11: #include <AudioFlinger.h>
12: #include <CameraService.h>
13: #include <MediaPlayerService.h>
14: #include <AudioPolicyService.h>
15: #include <private/android_filesystem_config.h>
16:
17: using namespace android;
18:
19: int main(int argc, char** argv)
20: {
21: sp<ProcessState> proc(ProcessState::self());
22: sp<IServiceManager> sm = defaultServiceManager();
23: LOGI("ServiceManager: %p", sm.get());
24: AudioFlinger::instantiate();
25: MediaPlayerService::instantiate();
26: CameraService::instantiate();
27: AudioPolicyService::instantiate();
28: ProcessState::self()->startThreadPool();
29: IPCThreadState::self()->joinThreadPool();
30: }
我们发现Media Server是一个进程，并且该程序的实现表面上也挺简单，其实并不简单，让我们慢慢分析一下Media Server。
1、第一句创建创建一个ProcessState的引用，但是这个对象后面并没有被调用到，那么为什么创建呢？请回想一下我在博文《Android系统的Binder机制之二——服务代理对象（1）》中介绍ProcessState对象时提到：如果一个进程要使用Binder机制，那么他的进程中必须要创建一个ProcessState对象来负责管理Service的代理对象。
2、第二句调用defaultServiceManager获得一个Service Manager代理对象，我在《Android系统的Binder机制之二——服务代理对象（1）》已经对此有了详细的介绍这里就不赘述了。
3、后面几行都是创建具体的Service，我们展开之后发现都是一些调用Service Manager的addService进行注册的函数，以AudioFlinger为例，instantiate代码如下：
1: void AudioFlinger::instantiate() {
2: defaultServiceManager()->addService(
3: String16("media.audio_flinger"), new AudioFlinger());
4: }
4、最后调用ProcessState的startThreadPool方法和IPCThreadState的joinThreadPool使Media Server进入等待请求的循环当中。
我们可以看出一个进程中可以有多个Service，Media Server这个进程中就存在AudioFlinger，MediaPlayerService，CameraService，AudioPolicyService四个Service。
2、系统Service的基础——BBinder
我们仔细查看一下Media Server中定义的四个Service我们将会发现他们都是继承自BBinder，而BBinder又继承自IBinder接口，详细情况请自行查看他们的代码。每个Service都改写了BBinder的onTransact虚函数，当用户发送请求到达Service时，框架将会调用Service的onTransact函数，后面我们将会详细的介绍这个机制。
3、Service注册
每个Service都需要向“大管家”Service Manager进行注册，调用Service Manager的addService方法注册。这样Service Manager将会运行客户端查询和获取该Service（代理对象），然后客户端就可以通过该Service的代理对象请求该Service的服务。
4、Service进入等待请求的循环
每个Service必须要进入死循环，等待客户端请求的到达，本例中最后两句就是使Service进行等待请求的循环之中。ProcessState的startThreadPool方法最终调用的也是IPCThreadState的joinThreadPool方法，具体请查看代码。IPCThreadState的joinThreadPool方法的代码如下：
1: void IPCThreadState::joinThreadPool(bool isMain)
2: {
3: ......
4: do {
5: int32_t cmd;
6:
7: ......
8:
9: // now get the next command to be processed, waiting if necessary
10: result = talkWithDriver();
11: if (result >= NO_ERROR) {
12: ......
13:
14: result = executeCommand(cmd);
15: }
16:
17: ......
18: } while (result != -ECONNREFUSED && result != -EBADF);
19:
20: ......
21: }
Service在IPCThreadState的joinThreadPool方法中，调用talkWithDriver方法和Binder驱动进行交互，读取客户端的请求。当客户端请求到达之后调用executeCommand方法进行处理。
我们再看一下Service怎样处理客户端的请求？我们们查看一下executeCommand方法的源码：
1: status_t IPCThreadState::executeCommand(int32_t cmd)
2: {
3: BBinder* obj;
4: RefBase::weakref_type* refs;
5: status_t result = NO_ERROR;
6:
7: switch (cmd) {
8: ......
9: case BR_TRANSACTION:
10: {
11: ......
12: if (tr.target.ptr) {
13: sp<BBinder> b((BBinder*)tr.cookie);
14: const status_t error = b->transact(tr.code, buffer, &reply, 0);
15: if (error < NO_ERROR) reply.setError(error);
16:
17: }
18: ......
19: }
20: break;
21:
22: ......
23: }
24:
25: if (result != NO_ERROR) {
26: mLastError = result;
27: }
28:
29: return result;
30: }
可以看到IPCThreadState将会直接调用BBinder的transact方法来处理客户端请求，我们再看一下BBinder的transact方法：
1: status_t BBinder::transact(
2: uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
3: {
4: data.setDataPosition(0);
5:
6: status_t err = NO_ERROR;
7: switch (code) {
8: case PING_TRANSACTION:
9: reply->writeInt32(pingBinder());
10: break;
11: default:
12: err = onTransact(code, data, reply, flags);
13: break;
14: }
15:
16: if (reply != NULL) {
17: reply->setDataPosition(0);
18: }
19:
20: return err;
21: }
我们发现他将会叫用自己的虚函数onTransact。我们前面提到所有的Service都集成自BBinder，并且都改写了onTransact虚函数。那么IPCThreadState将会调用Service定义onTransact方法来响应客户请求。