android—匿名binder

前面的一篇文章《android—binder进程间通讯流程分析》分析过，service一般都是需要先去service manager注册后，然后才能去使用。而匿名binder就是没有去service manager注册的service，既然没去注册，那么内核中就没有相应的binder_node和binder_ref结构，那么如何使用？下面以BufferQueue的mGraphicBufferAlloc对象产生为例。

BufferQueue::BufferQueue(const sp<IGraphicBufferAlloc>& allocator) :    mDefaultWidth(1),    mDefaultHeight(1),    mMaxAcquiredBufferCount(1),    mDefaultMaxBufferCount(2),    mOverrideMaxBufferCount(0),    mConsumerControlledByApp(false),    mDequeueBufferCannotBlock(false),    mUseAsyncBuffer(true),    mConnectedApi(NO_CONNECTED_API),    mAbandoned(false),    mFrameCounter(0),    mBufferHasBeenQueued(false),    mDefaultBufferFormat(PIXEL_FORMAT_RGBA_8888),    mConsumerUsageBits(0),    mTransformHint(0){    // Choose a name using the PID and a process-unique ID.    mConsumerName = String8::format("unnamed-%d-%d", getpid(), createProcessUniqueId());    ST_LOGV("BufferQueue");    if (allocator == NULL) {        //①获取BpSurfaceComposer        sp<ISurfaceComposer> composer(ComposerService::getComposerService());        //②获取mGraphicBufferAlloc        mGraphicBufferAlloc = composer->createGraphicBufferAlloc();        if (mGraphicBufferAlloc == 0) {            ST_LOGE("createGraphicBufferAlloc() failed in BufferQueue()");        }    } else {        mGraphicBufferAlloc = allocator;    }}

上面BufferQueue的构造函数中，
首先在①中获取了BpSurfaceComposer，前面有介绍，不展开；
②是获取mGraphicBufferAlloc ，下面详细分析。

sp<IGraphicBufferAlloc> mGraphicBufferAlloc;

从定义看，mGraphicBufferAlloc应该是GraphicBufferAlloc服务的代理对象，但是GraphicBufferAlloc并没有去service manager去注册。

下面看BpSurfaceComposer的createGraphicBufferAlloc()函数。

    virtual sp<IGraphicBufferAlloc> createGraphicBufferAlloc()    {        uint32_t n;        Parcel data, reply;        data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());        remote()->transact(BnSurfaceComposer::CREATE_GRAPHIC_BUFFER_ALLOC, data, &reply);        //从reply中，即内核的返回值中readStrongBinder        return interface_cast<IGraphicBufferAlloc>(reply.readStrongBinder());    }

主要的代码就是interface_cast(reply.readStrongBinder());，从reply.readStrongBinder()中返回BpBinder(handle)，然后通过interface_cast转换为BpGraphicBufferAlloc对象。
那么这个binder对象是如何从server，即surface flinger中传过来的？下面看server端代码，

status_t BnSurfaceComposer::onTransact(    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){        case CREATE_GRAPHIC_BUFFER_ALLOC: {            CHECK_INTERFACE(ISurfaceComposer, data, reply);            //调用surface flinger的createGraphicBufferAlloc函数            //GraphicBufferAlloc类继承自BnInterface            sp<IBinder> b = createGraphicBufferAlloc()->asBinder();            //将binder实体写入            reply->writeStrongBinder(b);            return NO_ERROR;        }}

sp<IGraphicBufferAlloc> SurfaceFlinger::createGraphicBufferAlloc(){    //真实的服务是GraphicBufferAlloc    //class GraphicBufferAlloc : public BnGraphicBufferAlloc    sp<GraphicBufferAlloc> gba(new GraphicBufferAlloc());    return gba;}

GraphicBufferAlloc类继承自BnInterface，这里调用BnInterface的onAsBinder()，所以返回的就是GraphicBufferAlloc new出来的指针。

template<typename INTERFACE>IBinder* BnInterface::onAsBinder(){    return this;}

调用reply->writeStrongBinder(b);，将GraphicBufferAlloc对象传入内核，这个在前面文章已经介绍过，当将binder实体GraphicBufferAlloc对象传入内核后，内核会为实体所对应的进程的binder_proc，也就是surface flinger，中创建一个实体对应的binder_node，然后在目标进程，也就是BufferQueue所在的进程中创建一个binder_ref指向前面的binder_node，然后返回给BufferQueue所在的进程一个handle，这个就打通了binder的传递流程。
从上面的分析，得到以下结论：
① service不是必须去service manager中注册后才能去使用；
② 匿名binder必须是建立在一个实名binder之上的，实名binder就是在service manager中注册过的。首先client和server通过实名binder建立联系，然后把匿名binder通过这个实名通道“传递过去”，对方也可以正确获取service的代理对象Bpxxx；
③ 为何需要匿名binder？对于android graphic系统来说，一个Layer对应一个BufferQueue，所以一个应用程序可能会有多个BufferQueue。当BufferQueue构造时，会去surface flinger进程中去创建一个new GraphicBufferAlloc()，所以一个应用程序会在surface flinger进程中创建多个GraphicBufferAlloc对象，我认为匿名Binder一般都是在这种情景中出现的，service有多个实体，在需要使用时，现场创建Binder实体。而一般实名Binder，即是去service manager中注册的service，都只会有一个service实体，即只会new一次。

更多相关文章

随机推荐