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对象。

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

看下一章