现在一起来分析Server端接收（来自APP端）Binder数据的整个过程，还是以ServiceManager这个Server为例进行分析,这是一个至下而上的分析过程。
在分析之前先思考ServiceManager是什么？它其实是一个独立的进程，由init解析init.rc文件并由它创建，要早于zygote进程，ServiceManager的main函数进程文件位于：framework/native/cmds/servicemanager/main.cpp
这个main函数运行意味着系统的SM进程开始运行了。下面是ServiceManager在init.rc中的描述。
下面是ServiceManager.rc文件
上面的rc文件描述说明servicemanager是一个系统的关键服务进程，不能重启的，因为 它一旦重启，将会restart如healthd,zygote, audioserver, surfaceflinger, inputflinger等一系列重要的其它进程。
下面先给出一个非常重要的结论，就是ServiceManager的父类继承关系，最顶层的父类是IServiceManager和BBinder，后面的源码分析的时候这个很有用，否则看不懂代码。
大家知道，每个android系统关键进程或app进程启动时会先创建binder，我们从SM的进程代码进行分析，如下：
main.cpp->main()-->char* driver="/dev/binder";//启动初始化binder驱动：普通app进程是通过ProcessState::self()->new ProcessState()来启动进程然后在构造函数中初始化binder,//与SM启动创建binder一样sp<ProcessState> ps = ProcessState::initWithDriver(driver);-->return new ProcessState();//在构造函数中open_driver(driver);//实例化ServiceManagersp<ServiceManager> manager = new ServiceManager(std::make_unique(Access));//设置服务端的BBinder对象//所以manager就是一个BBinder对象：因为class ServiceManager: public os:BnServiceManager{}//而BnServiceManager继承关系是： class BnServiceManager: public ::android::BnInterface<IServiceManager>{ }//BnInterface的继承关系（位于Interface.h): class BnInterface: public BBinder{ }//综上，manager就是一个BBinder对象。//注意BnServerManager.h这个头文件是需要根据IServerManager.aidl文件自己去编译生成的（//可以使用AIDL命令去编译）IPCThreadState::self()->setTheContextObject(manager); -->IPCThreadState.cpp->self():-->return new IPCThreadState(); //创建线程对象IPCThreadState.cpp->setTheContextObject(sp<BBinder> obj):-->the_context_object = obj;//设置成为binder驱动的context Manager,成为上下文的管理者，ps代表SM进程ps->becomeContextManager(nullptr, nullptr);//重点在下面://通过Looper epoll机制处理binder事务sp<Looper> looper = Looper::prepare(false);//设置callbackBinderCallback::setupTo(looper);//向Binder驱动发送BC_ENTER_LOOPER事务请求，并获得binder设备的文件描述符//监听binder_fd文件描述符的数据变化-->IPCThreadState::self()->setupPolling(&binder_fd);looper->addFd(binder_fd, Looper::POLL_CALLBACK,Looper::EVENT_INPUT, cb, nullptr);-->//当binder驱动发来消息后：调用下面的回调事件处理：int handleEvent(int fd int event){//从binder驱动接收到消息并处理。IPCThreadState::self()->handlePolledCommands();-->do //当读 缓存中数据未消费完时，持续循环读{result = getAndExecuteCommand();-->result = talkWithDriver();//从Binder驱动读入数据mIn-->cmd = mIn.readInt32(); //从数据中读取BR响应码-->executeCommand(cmd);-->case BR_TRANSACTION: //走这个分支//对SM来说，使用the_context_object这个BBinder对象//而transact应该在SM的父类中定义即BBinder-->the_context_object->transact(tr.code,buffer,&reply,tr.flags);-->BBinder.cpp->transact()://这里注意，下面调用的其实是子类的onTransact(即BnServiceManager.h中定义,但这只是一个头文件)//更进一步分析，其实是调用由IServiceManager.aidl生成的Bn端的cpp文件中(需要自己编译)--> onTransact();-->IServiceManager.cpp->BnServiceManager::onTransact():-->getService(); //其实是它的孩子即ServiceManager的接口-->ServiceManager.cpp->getService(name, sp<IBinder> * outBinder);//返回Binder*outBinder = tryGetService(name, true);-->std::map<string16, sp<IBinder>> mNameToService; //维持一张表--> auto it = mNameToService.find(name);service = &(it->second); //取出Service;out = service->binder;return out;}while(mIn.dataPosition() < mIn.dataSize()); //当我们清空执行完所有的命令后，最后处理BR_DECREFS和BR_RELEASEProcessPendingDerefs();FlushCommands(); }上面分析的应该比较详细了，下面再总结下整体流程：
总结：
- binder驱动收到请求后， SM的looperCallBack回调会进行处理（BinderCallback- >handleEvent）
- 然后调用IPCThread::self()->handlePolledCommands()解读命令，向上分发
- the_context_object(注意这是一个BBinder对象)即BBinder->transact();
- 转交给BBinder的子类BnServiceManager.onTransact()处理,但这个是AIDL提供的代码，所以真正实现的是ServiceManager.getService();
最后再画一张图描述下整个过程：
)
