沈阳网站建设索王道下拉,网站制作公司员工,阿里云网络服务,wordpress手机图片站现在一起来分析Server端接收#xff08;来自APP端#xff09;Binder数据的整个过程#xff0c;还是以ServiceManager这个Server为例进行分析,这是一个至下而上的分析过程。 在分析之前先思考ServiceManager是什么#xff1f;它其实是一个独立的进程#xff0c;由init解析i…现在一起来分析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一样spProcessState ps ProcessState::initWithDriver(driver);--return new ProcessState();//在构造函数中open_driver(driver);//实例化ServiceManagerspServiceManager manager new ServiceManager(std::make_unique(Access));//设置服务端的BBinder对象//所以manager就是一个BBinder对象因为class ServiceManager: public os:BnServiceManager{}//而BnServiceManager继承关系是 class BnServiceManager: public ::android::BnInterfaceIServiceManager{ }//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(spBBinder obj):--the_context_object obj;//设置成为binder驱动的context Manager,成为上下文的管理者ps代表SM进程ps-becomeContextManager(nullptr, nullptr);//重点在下面://通过Looper epoll机制处理binder事务spLooper 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, spIBinder * outBinder);//返回Binder*outBinder tryGetService(name, true);--std::mapstring16, spIBinder 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();
最后再画一张图描述下整个过程
