android binder机制Bp端对象理解

我们知道通过当前进程的serviceManager对象，能够通过名称获取到当前的service对象。获取的这个对象是什么？

使用获得的sm对象，调用getService接口。我们看看getService实现了什么。

virtual sp<IBinder> getService(const String16& name) const

{

unsigned n;

for (n = 0; n < 5; n++){

sp<IBinder> svc = checkService(name);

if (svc != NULL) return svc;

LOGI("Waiting for service %s...\n", String8(name).string());

sleep(1);

}

return NULL;

}

调用了checkService，返回值就是Ibinder对象。下面是checkService的代码。

virtual sp<IBinder> checkService( const String16& name) const

{

Parcel data, reply;

data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());

data.writeString16(name);

remote()->transact(CHECK_SERVICE_TRANSACTION, data, &reply);

return reply.readStrongBinder();

}

reply是个parcel对象，相应的代码在Parcel.cpp里面

sp<IBinder> Parcel::readStrongBinder() const

{

sp<IBinder> val;

unflatten_binder(ProcessState::self(), *this, &val);

return val;

}

我们看看unflatten_binder这里面做了什么。

status_t unflatten_binder(const sp<ProcessState>& proc,

const Parcel& in, sp<IBinder>* out)

{

const flat_binder_object* flat = in.readObject(false);

if (flat) {

switch (flat->type) {

case BINDER_TYPE_BINDER:

*out = static_cast<IBinder*>(flat->cookie);

return finish_unflatten_binder(NULL, *flat, in);

case BINDER_TYPE_HANDLE:

*out = proc->getStrongProxyForHandle(flat->handle);

return finish_unflatten_binder(

static_cast<BpBinder*>(out->get()), *flat, in);

}

}

return BAD_TYPE;

}

不难理解，这个地方，第一次创建的时候，flat->type应该是BINDER_TYPE_HANDLE。

getStrongProxyForHandle这个里面创建了真正的BpBinder对象。

根据handle的不同创建了BpBinder对象。

那它怎么转化成实际的服务端对象的呢？

看下一章