先大概描述下Android中S/C架构的基本面貌
由于采用linux内核，所以用户空间中得进程地址空间都是独立的，如果用户空间进程AB之间想进行通信,可以先将用户空间进程A要发送信息发送到内核，由于内核中得地址空间对于每个进程都是一样的，所以用户空间进程B可以读取内核收到的信息。
Android中得binder机制就是将这种调用进行了封装,将用户空间的进程分为三类，client,service,ManagerService
其中的ManagerService作用是记录所有的service信息，client访问service前先到ManagerService处去查询有无此服务
常用有如下情形1：添加service服务
过程
第一步：获取ManagerService服务代理BpBinder(0)和BpManagerService
第二步：通过BpManagerService中得addService方法将服务的一些信息打包，然后通过BpBinder(0)将信息发送到内核，等待ManagerService进程来读取，因为ManagerService进程中有一个Loop一直读取内核信息，所以很快就获取了service发给内核的信息，ManagerService进程就将service服务的一些信息添加到维护的列表中，将添加的结果发送给内核，然后service等到内核有回复后返回，将返回的信息解码分析。
第三步：执行一个Loop来从内核读取client的请求
代码
如下是添加一个service的代码
第一步：
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
第二步：
defaultServiceManager()->addService(String16("media.player"),new MediaPlayerService());
第三步：
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
代码分析
sp<ProcessState> proc(ProcessState::self());
创建一个ProcessState实例
ProcessState::mDriverFD=open_driver()
ProcessState::mVMstart = mmap(…,mDriverFD,…);
mmap(0,…,mDriverFD,0);//只是让通信更快，可以当作没有，直接用read/write(mDriverFD);
sp<IServiceManager> sm = defaultServiceManager();
主要执行如下代码
sp<IServiceManager> gDefaultServiceManager =interface_cast<IServiceManager>(PorcessState::self()->getContextObject(NULL));
其中PorcessState::self()->getContextObject(NULL)就是执行PorcessState::getStrongProxyForHandle(0);其主要是根据给定的参数(此处为0)创建对应的sp<IBinder> b = new BpBinder(0);
这边先说明interface_case这个模版类，这个模版类作用是将服务xxxService对应的BpBinder(x)转化为对应的BpxxxService如下：
sp<IxxxService> BpxxxService= interface_cast<IxxxService>(newBpBinder(x));
其本质是调用给定类型参数的asInterface方法，也就是IxxxService::asInterface(new BpBinder(x)),IxxxService继承publicIInterface
IxxxService用宏DECLARE_META_INTERFACE(xxxService)和IMPLEMENT_META_INTERFACE(xxxService,”android.os.IxxxService”)来实现asInterface方法，展开后如 new BpxxxService(new BpBinder(x))，这样就从BpBinder(x)得到了BpxxxService
如本例中给定的类型参数是IServiceManager，所以上述等价于
sp<IServiceManager> gDefaultServiceManager =IServiceManager::asInterface(new BpBinder(0)); IServiceManager继承publicIInterface
其中用宏DECLARE_META_INTERFACE(ServiceManager) 和IMPLEMENT_META_INTERFACE(ServiceManager,”android.os.IServiceManager”)来实现asInterface方法,这个asInterface方法最终执行new BpServiceManager(new BpBinder(0));
也就是sp<IServiceManager> sm = newBpServiceManager(new BpBinder(0));
由此得到BpBinder(0)和BpServiceManager
从这里可以得出，如果自己创建服务xxxService,按如下步骤
创建类 class IxxxService:publice IInterface
{
DECLARE_META_INTERFACE(xxxService);//声明asInterface方法
virtual function();//虚函数，由BpxxxService实现
…
}
IMPLEMENT_META_INTERFACE(xxxService,”android.os.IxxxService”);//定义asInterface
展开相当于sp<IxxxService>IxxxService::asInterface(BpBinder){
return new BpxxxService
}
当有这个服务的Bpbinder(x)后可通过如下获取BpxxxService
sp<IxxxService>sm = new BpxxxService (new BpBinder(x));
注意:
1:BpxxxService类型为sp<IxxxService>
2:BpBinder(x)相当于xxxService对应binder实体的代理
3:客户端为什么要通过BpBinder(X)再创建一个BpxxxService呢？因为BpxxxService对象的基类中的一个mRemote变量就是Bpbinder(x)，那为什么不直接用BpBinder(x)呢？因为BpxxxService对象中还实现了一些BpBinder(x)没有的业务逻辑(实现基类IxxxService中的方法)如BpServiceManager中提供了addService方法，这些方法在服务端有对应的服务，如addService方法将请求的命令”addService”和数据打包成Parcel类型，然后通过BpBinder(x)发送给xxxService，其实先发给驱动中binder设备，xxxService服务中会有Loop循环一直读取binder设备的消息，读取消息后解析成命令+数据，然后根据命令如”addService”会调取对应的服务，然后将结果反馈给binder设备，客户端接收到binder设备的反馈后将返回的数据也解析成命令+数据，然后根据命令和数据执行相应的逻辑
客户端 通过BpxxxService中方法将数据打包 -->Bpbinder(x)--> binder设备 --> 服务端Loop 获取数据解析成命令+数据-->调取命令指定的服务其中会涉及BBinder和BnxxxService，返回数据
客户端 解析返回的数据并执行相应逻辑 <--Bpbinder(x)<-- binder设备 <-- 服务端返回数据
由上可知，创建的服务还需创建BnxxxService和BpxxxService
class BpxxxService : public BpInterface<IxxxService>
{
…
vitural function(){
Parcel data,reply;
data.writeInterfaceToken(IxxxService::getInterfaceDescriptor());
data.writeInt32(pid);
remote()->transact(命令码，data,&reply);
}
}
class BnxxxService: public BnInterface<IxxxService>
{
public:
vitrual status_t onTransact(uint32_tcode,const Parcel& data,Parcel* reply,uint32_t flags = 0);
}
IMPLEMENT_META_INTERFACE(xxxService,”android.xxxService.IxxxService”);
status_t BnxxxService::onTransact(uint32_tcode,const Parcel& data,Parcel* reply,uint32_t flags)
{
switch(code){
case 命令码：
CHECK_INTERFACE(IxxxService,data,reply);
function()//自己实现的逻辑
break;
…
}
defaultServiceManager()->addService(String16("media.player"),new MediaPlayerService());
通过BpServiceManager(类型为sp<IServiceManager>)将数据打包成含”addService”命令，类型为parcel data的数据，调用BpBinder(0)这个对象的transact(),最终调到IPCThreadState::self()->transact(),
下面分析IPCThreadState，你暂时只需要知道每个线程有一个IPCThreadState实例，实例有属性mIn,mOut，其中mIn用来接受来自binder设备的parcel类型数据，mOut用来存储发往binder设备的parcel类型数据，IPCThreadState::self()->transact()最终完成与binder设备的交互，这个接口中先调用writeTransactionData把parcel类型的数据和int32_t类型的命令码封装成binder_transaction_data类型数据放到IPCThreadState实例的mOut中去，接下来IPCThreadState::self()->transact()会调用IPCThreadState::self()->waitForResponse接口,其中会调用talkWithDriver()与binder设备交换数据(talkwithDriver主要是实现是ioctl(mProcess->mDriverFD,BINDER_WRITE_READ, &bwr))，将返回来的数据存于IPCThreadState实例的mIn,然后调用executeCommand()根据mIn中得命令码和数据来解析，来调用各种业务逻辑
ServiceManager这个服务的Loop循环实现代码见下面：
struct binder_state *bs;
void *svcmgr = BINDER_SERVICE_MANAGER;
bs = binder_open(128*1024);//应该是打开binder设备吧
binder_become_context_manager(bs) //成为manager
svcmgr_handle = svcmgr;
binder_loop(bs, svcmgr_handler);//Loop
new MediaPlayerService()，MediaPlayerService继承BnMediaPlayService，BnMediaPlayService继承BnInterface, BnInterface继承BBinder ,BBinder继承 IBinder,所以MediaPlayerService继承了IBinder,addService第二个参数类型是IBinder 实例一个MediaPlayService也就是实例一个BnMediaPlaySerivce
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
创建一个MediaPlayerService服务后（也就是创建一个BnMediaPlaySerivce)后，将其加入serviceManage维护的一个列表中，接下来，BnMediaPlaySerivce也该起到服务的作用，创建一个Loop等待客户端client的请求，所以应该也有一个循环，也就是如下两段代码的作用
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
先分析ProcessState::self()->startThreadPool();
其调用
sp<Thread> t = new PoolThread(isMain);isMain是TRUE
t->run(buf);//这句话会导致t->threadLoop调用，这里面执行了IPCThreadState::self()->joinThreadPool(mIsMain);
所以归根结底最后都调用IPCThreadState::self()->joinThreadPool(mIsMain);
这里面主要是执行一个循环，
do {
int32_tcmd;
result =talkWithDriver();
result =executeCommand(cmd);
}
} while (result != -ECONNREFUSED && result !=-EBADF);
总结：调用talkWithDriver()与binder设备交换数据(talkwithDriver主要是实现是ioctl(mProcess->mDriverFD,BINDER_WRITE_READ, &bwr))，将返回来的数据存于IPCThreadState实例的mIn,然后调用executeCommand()根据mIn中得命令码和数据来解析，来调用自己(此处是BnMediaPlaySerivce)的各种业务逻辑，例如如果受到的命令是BR_TRANSACTION则会调用reinterpret_cast<BBinder*>(tr.cookie)->transact(tr.code,buffer, &reply, tr.flags);结果调用BnMediaPlaySerivce的oNTransact方法
这里面会根据获取的mIn中得命令码和数据来调用不同的业务逻辑,然后派发到派生类MediaService(自己创建的)的函数，由他们完成实际的工作
常用有如下情形2：client访问某个服务service
过程
第一步：获取ManagerService服务代理BpBinder(0)和BpManagerService
第二步：通过BpManagerService中得getService方法将服务的一些信息打包，然后通过BpBinder(0)将信息发送到内核，等待ManagerService进程来读取，因为ManagerService进程中有一个Loop一直读取内核信息，所以很快就获取了client发给内核的信息，ManagerService进程将client想知道的东西发送给内核，client等到内核有回复后返回，将返回的信息解码分析已得知有无某个service服务，如果有这个service则返回的信息中有这个service的Bpbinder(x),client可以通过sp<Iservice>Bpservice = interface_cast<Iservice>( Bpbinder(x));来获取BpService,BpService中有与service对应的服务
第三步：访问服务
client访问这些服务前先调BpService中对应特定服务其将数据及命令打包,通过Bpbinder(x)将信息发送到内核，应为service也有一个Loop一直在读取内核信息，所以service很快就获取了client发来的信息，解析后根据信息中得命令码将数据发送到Bnservice对象包含的方法中进行解析，然后将处理后的数据发送给内核，client等到内核的受到的消息后返回，将返回的消息解码然后处理
代码
如下是client获取service的的代码
第一步：
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm=defaultServiceManager();
见上
第二步：
sp<IBinder> binder = sm->getServices(String16(“media.player”));
sp<IMediaPlayService> sMediaPlayService =interface_cast<IMediaPlayService>(binder);
见上
第三步：
略
扫一扫
308
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
