从Android Bootanimation理解SurfaceFlinger的客户端建立

本文均属自己阅读源码的点滴总结，转账请注明出处谢谢。

欢迎和大家交流。qq:1037701636 email:gzzaigcn2012@gmail.com

Android源码版本Version：4.2.2; 硬件平台 全志A31

 

step1.前面的几张博文都在记录SurfaceFLinger侧，也就是所谓的Server端，接下去就和大家来看看客户端是如何将要处理的图形信息请求SF来传递出去的呢。大家学习的一个方式都是通过android启动的第一个开机画面来入手的，先来看看启动的函数，再来看这个类BootAnimation。

int main(int argc, char** argv)//由surfaceflinger来触发init进程来启动它
{
#if defined(HAVE_PTHREADS)
    setpriority(PRIO_PROCESS, 0, ANDROID_PRIORITY_DISPLAY);
#endif

    char value[PROPERTY_VALUE_MAX];
    property_get("debug.sf.nobootanimation", value, "0");
    int noBootAnimation = atoi(value);
    ALOGI_IF(noBootAnimation,  "boot animation disabled");
    if (!noBootAnimation) {

        sp<ProcessState> proc(ProcessState::self());
        ProcessState::self()->startThreadPool();//这里会进行binder的驱动初始化

        // create the boot animation object
        sp<BootAnimation> boot = new BootAnimation();//初始化并会调用BootAnimation的onFirstRef，启动一个线程
        boot->playBootMusic("/system/media/boot.wav");
        IPCThreadState::self()->joinThreadPool();

    }
    return 0;
}

我们会问Bootanimation是在哪里启动的呢，可以看我之前写的文章android从init到开机动画启动关闭流程一简易图(surfaceflinger启动的位置)里面讲到了SF启动之后init主进程才有可能启动它，因为bootanimation在init.rc是配置为disable，在SF里面会出现的readyToRun函数内的startBootAnim();//开启动画属性，通过设置内存属性值来触发Init进程来启动：

void SurfaceFlinger::startBootAnim() {
    // start boot animation
    property_set("service.bootanim.exit", "0");
    property_set("ctl.start", "bootanim");
}

其中property_set会将一个ctl.statrt属性发送到init中建立的property Service之中后调用handle_property_set_fd->handle_control_message，此时发送的属性值为bootanim即表示一个服务名，因为init.rc中是disable的所以没去启动，这里设置属性过程ctl.就表明需要start一个服务bootanim，也就是启动开机动画进程：

在BootAnimation的main函数中，开始新建类的对象。

BootAnimation::BootAnimation() : Thread(false)
{
    mSession = new SurfaceComposerClient();//SurfaceComposerClient，msession:sp<SurfaceComposerClient>
}

可以想象的到，作为线程类Thread的派生类，明显的很多事情是在thread的readyToRun和ThreadLoop里面发生的，而新线程也一般就是在OnFirstRef中启动run函数的。

在BootAnimation的构造函数中看到了一个SurfaceComposerClient类，理解为界面合成客户端，的确BootAnimation将会作为一个客户端请求SF去完成图层的渲染。那么SCC是如何和SF交互的呢，我们来看SCC的构造过程。

SurfaceComposerClient::SurfaceComposerClient()
    : mStatus(NO_INIT), mComposer(Composer::getInstance())
{
}

void SurfaceComposerClient::onFirstRef() {
    sp<ISurfaceComposer> sm(ComposerService::getComposerService());//获得SurfaceFlinger的proxy BpSurfaceComposer
    if (sm != 0) {
        sp<ISurfaceComposerClient> conn = sm->createConnection();//建立一个连接，获得SurfaceFlinger远程的客户端BpSurfaceComposerClient，对应于服务端的Client
        if (conn != 0) {
            mClient = conn;//BpISurfaceComposerClient保存在mclient
            mStatus = NO_ERROR;
        }
    }
}

在调用构造函数时初始化一个Composer类成员变量，且为单列模式。再来看onFirstRef中的操作，ComposerService::getComposerService：

sp<ISurfaceComposer> ComposerService::getComposerService() {
    ComposerService& instance = ComposerService::getInstance();//ComposerService对象创建，单列模式BpSurfaceComposer，保存在其成员mComposerService
    Mutex::Autolock _l(instance.mLock);
    if (instance.mComposerService == NULL) {
        ComposerService::getInstance().connectLocked();
        assert(instance.mComposerService != NULL);
        ALOGD("ComposerService reconnected");
    }
    return instance.mComposerService;//成员代码BpSurfaceComposer
}

内部又出现一个ComposerService这个单列模式，看看他的构造函数：

ComposerService::ComposerService()
: Singleton<ComposerService>() {
    Mutex::Autolock _l(mLock);
    connectLocked();
}

果然会调用一个connectLocked函数：

void ComposerService::connectLocked() {
    const String16 name("SurfaceFlinger");
    while (getService(name, &mComposerService) != NO_ERROR) {//返回surfaceflinger的代理到mComposerService
        usleep(250000);
    }

 很清楚的是getService，可以想象的是应该是和ServiceManger在交互了，如下：

status_t getService(const String16& name, sp<INTERFACE>* outService)
{
    const sp<IServiceManager> sm = defaultServiceManager();
    if (sm != NULL) {
        *outService = interface_cast<INTERFACE>(sm->getService(name));
        if ((*outService) != NULL) return NO_ERROR;
    }
    return NAME_NOT_FOUND;
}

果然在这里就是看到了通用的客户端和SM的交互过程了，这里就是实现了客户端请求SM返回SurfaceFlinger的服务端在本地的代理proxy。最终保存到mCompserService变量中且该对象的类型为BpSurfaceComposer和SF(实际上SF继承了BnSurfaceComposer这个本地对象)处建立起基于Binder的C/S通信架构。

好了上面的代码执行了这么多就是为了调用sm->createConnection()函数，这个就是典型的Binder通信方式了，可以看到：

    virtual sp<ISurfaceComposerClient> createConnection()
    {
        uint32_t n;
        Parcel data, reply;
        data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
        remote()->transact(BnSurfaceComposer::CREATE_CONNECTION, data, &reply);
        return interface_cast<ISurfaceComposerClient>(reply.readStrongBinder());//返回的Bpbinder转为SurfaceComposerClient
    }

最终返回的是一个BpSurfaceComposerClient，当然核心的处理都是SF在建立的。那么回到SurfaceFlinger里面看看这个BpSurfaceComposerClient对象在SF里的实际角色吧。

SF最终会调用createConnection()函数（这个过程分别经过了BnSurfaceComposer的onTransact处理，SF继承了BnSurfaceComposer）.

sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
{
    sp<ISurfaceComposerClient> bclient;
    sp<Client> client(new Client(this));//客户端远程调用时new一个BnSurfaceComposerClient
    status_t err = client->initCheck();
    if (err == NO_ERROR) {
        bclient = client;
    }
    return bclient;
}

可以看到这里是调用了这个Client，而基于Binder通信架构的话这个Client肯定是继承了BnSurfaceComposerClient，故BnSurfaceComposerClient在SF中其实是一个Client类，

status_t BnSurfaceComposer::onTransact(//内部函数由继承类SF来完成
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch(code) {
        case CREATE_CONNECTION: {
            CHECK_INTERFACE(ISurfaceComposer, data, reply);
            sp<IBinder> b = createConnection()->asBinder();//创建一个Bpbinder
            reply->writeStrongBinder(b);//返回给客户端一个BpBinder的handle
        } break;

最终转为Binder类型，写入到Binder分配一个唯一的handle，最终写回给BpSurfaceComposer客户端供进一步的BpSurfaceComposerClient和Client之间的通信，而这个Client的代理最终保存在SurfaceComposerClient类对象的成员函数mClient中去。

 

 step2.接着看Bootanimation里的readyToRun()，内部有如下的一个函数即创建本地的Surface。

    // create the native surface
    sp<SurfaceControl> control = session()->createSurface(String8("BootAnimation"),
            dinfo.w, dinfo.h, PIXEL_FORMAT_RGB_565);//请求surfaceflinger来创建一个surface

session()函数返回之前创建的SurfaceComposerClient，上述函数实际实现如下：

sp<SurfaceControl> SurfaceComposerClient::createSurface(
        const String8& name,
        uint32_t w,
        uint32_t h,
        PixelFormat format,
        uint32_t flags)
{
    sp<SurfaceControl> result;
    if (mStatus == NO_ERROR) {
        ISurfaceComposerClient::surface_data_t data;
        sp<ISurface> surface = mClient->createSurface(&data, name,
                w, h, format, flags);//对应的由SF侧的錍lient来完成， BpSurface
        if (surface != 0) {
            result = new SurfaceControl(this, surface, data);//将得到的surface关联到一个SurfaceControl
        }
    }
    return result;
}

很显然可以看到是有mClient来实现的，故在SF侧就是由之前的new Client处创建的一个Client来完成这个交互的。故回到Client的onTransact函数中去

status_t Client::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
     ....return BnSurfaceComposerClient::onTransact(code, data, reply, flags);//内部就是调用继承类Client的createSurface
}

接着往下看：

status_t BnSurfaceComposerClient::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
     switch(code) {
        case CREATE_SURFACE: {
            CHECK_INTERFACE(ISurfaceComposerClient, data, reply);
            surface_data_t params;
            String8 name = data.readString8();
            uint32_t w = data.readInt32();
            uint32_t h = data.readInt32();
            PixelFormat format = data.readInt32();
            uint32_t flags = data.readInt32();
            sp<ISurface> s = createSurface(¶ms, name, w, h,
                    format, flags);//创建一个surface
            params.writeToParcel(reply);
            reply->writeStrongBinder(s->asBinder());//本地的BBinder写入给客户端
            return NO_ERROR;
        } break;......

因为BnSurfaceComposerClient被Client继承，故实际调用的还是Client的createrSurface()函数，相关的实现见下一博文SurfaceFlinger中Surface和Layer的建立。