SurfaceComposerClient的出现是因为： Java层SurfaceSession对象的构造函数会调用Native的SurfaceSession_init函数，而该函数的主要目的就是创建SurfaceComposerClient。 先回顾一下SurfaceSession_init函数，代码如下所示： **android_view_Surface.cpp** ~~~ static void SurfaceSession_init(JNIEnv* env,jobject clazz) { //new 一个SurfaceComposerClient对象 sp<SurfaceComposerClient> client = newSurfaceComposerClient; //sp的使用也有让人烦恼的地方，有时需要显式地增加强弱引用计数，要是忘记，可就麻烦了 client->incStrong(clazz); env->SetIntField(clazz, sso.client,(int)client.get()); } ~~~ 上面代码中，显式地构造了一个SurfaceComposerClient对象。接下来看它是何方神圣。 1. 创建SurfaceComposerClient SurfaceComposerClient这个名字隐含的意思是： 这个对象会和SurfaceFlinger进行交互，因为SurfaceFlinger派生于SurfaceComposer。 通过它的构造函数来看是否是这样的。代码如下所示： **SurfaceComposerClient.cpp** ~~~ SurfaceComposerClient::SurfaceComposerClient() { //getComposerService()将返回SF的Binder代理端的BpSurfaceFlinger对象 sp<ISurfaceComposer> sm(getComposerService()); //先调用SF的createConnection，再调用_init _init(sm, sm->createConnection()); if(mClient != 0) { Mutex::Autolock _l(gLock); //gActiveConnections是全局变量，把刚才创建的client保存到这个map中去 gActiveConnections.add(mClient->asBinder(), this); } } ~~~ 果然如此，SurfaceComposerClient建立了和SF的交互通道，下面直接转到SF的createConnection函数去观察。 （1）createConnection的分析 直接看代码，如下所示： **SurfaceFlinger.cpp** ~~~ sp<ISurfaceFlingerClient>SurfaceFlinger::createConnection() { Mutex::Autolock _l(mStateLock); uint32_t token = mTokens.acquire(); //先创建一个Client。 sp<Client> client = new Client(token, this); //把这个Client对象保存到mClientsMap中，token是它的标识。 status_t err = mClientsMap.add(token, client); /* 创建一个用于Binder通信的BClient，BClient派生于ISurfaceFlingerClient， 它的作用是接受客户端的请求，然后把处理提交给SF，注意，并不是提交给Client。 Client会创建一块共享内存，该内存由getControlBlockMemory函数返回 */ sp<BClient> bclient = new BClient(this, token,client->getControlBlockMemory()); returnbclient; } ~~~ 上面代码中提到，Client会创建一块共享内存。熟悉Audio的读者或许会认为，这可能是Surface的ControlBlock对象了！是的。CB对象在协调生产/消费步调时，起到了决定性的控制作用，所以非常重要，下面来看： **SurfaceFlinger.cpp** ~~~ Client::Client(ClientID clientID, constsp<SurfaceFlinger>& flinger) :ctrlblk(0), cid(clientID), mPid(0), mBitmap(0), mFlinger(flinger) { const int pgsize = getpagesize(); //下面这个操作会使cblksize为页的大小，目前是4096字节。 constint cblksize = ((sizeof(SharedClient)+(pgsize-1))&~(pgsize-1)); //MemoryHeapBase是我们的老朋友了，不熟悉的读者可以回顾Audio系统中所介绍的内容 mCblkHeap = new MemoryHeapBase(cblksize, 0, "SurfaceFlinger Clientcontrol-block"); ctrlblk = static_cast<SharedClient *>(mCblkHeap->getBase()); if(ctrlblk) { new(ctrlblk) SharedClient; //再一次觉得眼熟吧？使用了placement new } } ~~~ 原来，Surface的CB对象就是在共享内存中创建的这个SharedClient对象。先来认识一下这个SharedClient。 （2）SharedClient的分析 SharedClient定义了一些成员变量，代码如下所示： ~~~ class SharedClient { public: SharedClient(); ~SharedClient(); status_t validate(size_t token) const; uint32_t getIdentity(size_t token) const;//取出标识本Client的token private: Mutexlock; Condition cv; //支持跨进程的同步对象 //NUM_LAYERS_MAX为31，SharedBufferStack是什么？ SharedBufferStack surfaces[ NUM_LAYERS_MAX ]; }; //SharedClient的构造函数，没什么新意，不如Audio的CB对象复杂 SharedClient::SharedClient() :lock(Mutex::SHARED), cv(Condition::SHARED) { } ~~~ SharedClient的定义似乎简单到极致了，不过不要高兴得过早，在这个SharedClient的定义中，没有发现和读写控制相关的变量，那怎么控制读写呢？ 答案就在看起来很别扭的SharedBufferStack数组中，它有31个元素。关于它的作用就不必卖关子了，答案是： 一个Client最多支持31个显示层。每一个显示层的生产/消费步调都由会对应的SharedBufferStack来控制。而它内部就用了几个成员变量来控制读写位置。 认识一下SharedBufferStack的这几个控制变量，如下所示： **SharedBufferStack.h** ~~~ class SharedBufferStack{ ...... //Buffer是按块使用的，每个Buffer都有自己的编号，其实就是数组中的索引号。 volatile int32_t head; //FrontBuffer的编号 volatile int32_t available; //空闲Buffer的个数 volatile int32_t queued; //脏Buffer的个数，脏Buffer表示有新数据的Buffer volatile int32_t inUse; //SF当前正在使用的Buffer的编号 volatilestatus_t status; //状态码 ...... } ~~~ 注意，上面定义的SharedBufferStack是一个通用的控制结构，而不仅是针对于只有两个Buffer的情况。根据前面介绍的PageFlipping知识，如果只有两个FB，那么，SharedBufferStack的控制就比较简单了： 要么SF读1号Buffer，客户端写0号Buffer，要么SF读0号Buffer，客户端写1号Buffer。 图8-13是展示了SharedClient的示意图： :-:  图8-13 SharedClient的示意图 从上图可知： - SF的一个Client分配一个跨进程共享的SharedClient对象。这个对象有31个SharedBufferStack元素，每一个SharedBufferStack对应于一个显示层。 - 一个显示层将创建两个Buffer，后续的PageFlipping就是基于这两个Buffer展开的。 另外，每一个显示层中，其数据的生产和消费并不是直接使用SharedClient对象来进行具体控制的，而是基于SharedBufferServer和SharedBufferClient两个结构，由这两个结构来对该显示层使用的SharedBufferStack进行操作，这些内容在以后的分析中还会碰到。 * * * * * **注意**，这里的显示层指的是Normal类型的显示层。 * * * * * 来接着分析后面的_init函数。 （3）_init函数的分析 先回顾一下之前的调用，代码如下所示： **SurfaceComposerClient.cpp** ~~~ SurfaceComposerClient::SurfaceComposerClient() { ...... _init(sm, sm->createConnection()); ...... } ~~~ 来看这个_init函数，代码如下所示： **SurfaceComposerClient.cpp** ~~~ void SurfaceComposerClient::_init( const sp<ISurfaceComposer>& sm, constsp<ISurfaceFlingerClient>& conn) { mPrebuiltLayerState = 0; mTransactionOpen = 0; mStatus = NO_ERROR; mControl = 0; mClient = conn;//mClient就是BClient的客户端 mControlMemory =mClient->getControlBlock(); mSignalServer = sm;// mSignalServer就是BpSurfaceFlinger //mControl就是那个创建于共享内存之中的SharedClient mControl = static_cast<SharedClient*>(mControlMemory->getBase()); } ~~~ _init函数的作用，就是初始化SurfaceComposerClient中的一些成员变量。最重要的是得到了三个成员： - mSignalServer ，它其实是SurfaceFlinger在客户端的代理BpSurfaceFlinger，它的主要作用是，在客户端更新完BackBuffer后（也就是刷新了界面后），通知SF进行PageFlipping和输出等工作。 - mControl，它是跨进程共享的SharedClient，是Surface系统的ControlBlock对象。 - mClient，它是BClient在客户端的对应物。 2. 到底有多少种对象？ 这一节，出现了好几种类型的对象，通过图8-14来看看它们： :-:  图8-14 类之间关系展示图 从上图中可以看出： - SurfaceFlinger是从Thread派生的，所以它会有一个单独运行的工作线程。 - BClient和SF之间采用了Proxy模式，BClient支持Binder通信，它接收客户端的请求，并派发给SF执行。 - SharedClient构建于一块共享内存中，SurfaceComposerClient和Client对象均持有这块共享内存。 在精简流程中，关于SurfaceComposerClient就分析到这里，下面分析第二个步骤中的SurfaceControl对象。