GUI系统之SurfaceFlinger(11)SurfaceComposerClient

Bertha 。 2022-01-11 01:01 385阅读 0赞

文章都是通过阅读源码分析出来的，还在不断完善与改进中，其中难免有些地方理解得不对，欢迎大家批评指正。  
转载请注明：From LXS. http://blog.csdn.net/uiop78uiop78/  
  
GUI系统之SurfaceFlinger章节目录：  
blog.csdn.net/uiop78uiop78/article/details/8954508

### 1.1.1 SurfaceComposerClient ###

![20130521134450939][]

图 11‑28 每个应用程序在SurfaceFlinger中都对应一个Client

SurfaceFlinger运行于SystemServer这一系统进程中，需要UI界面显示的应用程序则通过binder服务与它进行跨进程通信。在音频系统的学习中，每一个AudioTrack在AudioFlinger中都可以找到一个对应的Track实现。这种设计方式同样适用于显示系统，即任何有UI界面的程序都在SurfaceFlinger中有且仅有一个Client实例。

Client这个类名并没有完全表达出它的含义，因为在Android系统的很多其它地方你都可以找到同名的类。应用程序与SurfaceFlinger间的接口是ISurfaceComposerClient，Client的父类是BnSurfaceComposerClient,它是这一接口的本地端实现。

/\*frameworks/native/include/gui/ISurfaceComposerClient.h\*/

class ISurfaceComposerClient : public IInterface

\{   …

virtual sp<ISurface>createSurface( surface\_data\_t\* data, const String8& name, DisplayIDdisplay,

uint32\_t w,uint32\_t h, PixelFormat format, uint32\_t flags) = 0;

virtual status\_t    destroySurface(SurfaceID sid) = 0;

\};

接口中最重要的两个方法createSurface()和destroySurface()分别用于向SurfaceFlinger申请和销毁一个ISurface。那么既然有了Client，为什么还要再引出另一个binder对象呢？

这是因为每个SurfaceFlinger的客户程序都只会有唯一一个Client连接，但它们内部拥有的Surface数量却很可能有多个。通常情况下，同一个Activity中的UI布局共用系统分配的Surface进行绘图，但像SurfaceView这种UI组件就是特例——它独占一个Surface进行绘制。举个例子来说，如果我们制作一个带SurfaceView的视频播放器，其所在的应用程序最终就会有不止一个的Surface存在。这样设计是必须的，因为播放视频对刷新频率要求很高，采用单独的Surface既可以保证视频的流畅度，也同时能让用户的交互动作(比如触摸屏操作)及时得到响应。

Client的继承关系图如下所示：

![20130521134526579][]

图 11‑29 ISurfaceComposerClient的本地端实现

1. SurfaceFlinger::createConnection

由于Client属于匿名binder服务，外界的进程不可能直接获取到，因而首先需要借助SurfaceFlinger这一实名binder Service，源码实现如下：

sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()

sp<ISurfaceComposerClient> bclient;

sp<Client>client(new Client(this));

status\_t err =client->initCheck();

if (err == NO\_ERROR) \{

bclient = client;

return bclient;

首先新建一个Client本地对象，initCheck初始化完成后如果没有错误的话，就可以ISurfaceComposerClient强指针返回。其中initCheck在目前版本中并没有做本质工作，它会直接返回NO\_ERROR。

2. Client::createSurface

Client只是建立起了UI程序与SurfaceFlinger间的纽带，真正的图形层(Surface)创建需要另外申请，即调用Client提供的如下接口：

/\*frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp\*/

sp<ISurface> Client::createSurface(…)

class MessageCreateSurface: public MessageBase \{…

SurfaceFlinger\*flinger;

Client\* client;

…

public:

MessageCreateSurface(…): flinger(flinger), params(params),client(client), name(name),

display(display), w(w), h(h), format(format), flags(flags)

\{//构造函数主要是对成员变量进行初始化

sp<ISurface>getResult() const \{ return result; \}

virtual bool handler()\{

result =flinger->createSurface(params, name, client, display, w, h, format, flags);

return true;

\};

sp<MessageBase> msg = newMessageCreateSurface(mFlinger.get(),params, name, this,

display,w, h, format, flags);

mFlinger->postMessageSync(msg); //将这一Message推送到SurfaceFlinger线程中

return  static\_cast<MessageCreateSurface\*>(msg.get() )->getResult();

这个函数比较特别的地方，是它先在内部创建了一个MessageCreateSurface类，剩余部分代码就是围绕这个类展开的。那么MessageCreateSurface有什么作用呢？从名称上看，它应该和Message有关，其父类是MessageBase，定义在MessageQueue.h中，如下关系图所示：

![20130521134557906][]

图 11‑30 MessageCreateSurface

从这个继承图中可以大概看出一点端倪，即MessageCreateSurface是一个Message的承载体，并且内部提供了处理这条Message的handler()函数。这是不是和Java层的Handler很像？可能也是这个原因，所以其“祖谱”中有一个类取名为MessageHandler。回过头来看createSurface中的最后几行，程序将一个MessageCreateSurface对象msg发送到了SurfaceFlinger中：

mFlinger->postMessageSync(msg);

为什么要这么做呢？

大家还记不记得在进程章节讲述Message、Looper、Handler的关系时曾经举过一个例子，为了方便阅读我们再把它列出来：

“。。。

打个比方来说，某天你和朋友去健身房运动，正当你在跑步机上气喘吁吁时，旁边有个朋友跟你说：“哥们，最近手头紧，借点钱花花”。那么这时候你就有两个选择：

Ø 马上执行

这就意味着你要从跑步机上下来，问清借多少钱，然后马上打开电脑进行转账汇款

Ø 稍后执行

上面的方法在某些场合下是有用的，不过大部分情况下“借钱”这种事并不是刻不容缓的，因而你可以跟你朋友说：“借钱没问题，你先和我秘书约时间，改天我们具体谈细节”。那么在这种情况下，这个“借钱事件”就通过秘书这个MessageQueue进入了排队，所以你并不需要从跑步机上下来，中断健身运动。后期秘书会一件件通知你MessageQueue上的待办事宜(当然你也可以主动问秘书)，直到“借钱事件”时你才需要和这位朋友进一步商谈。在一些场合下这样的处理方式是合情合理的。比如说健身房一小时花费是10万，而你朋友只借一百块，那么在这时处理这一事件就不合理了

”

这个例子在createSurface()这个场景中也是同样适用的，如下图所示：

![20130521134659953][]

图 11‑31 createSurface中的消息投递与执行

函数postMessageSync是SurfaceFlinger提供的一个接口，它通过mEventQueue将Msg压入队列中，并且还会进入等待状态，如下：

status\_t SurfaceFlinger::postMessageSync(constsp<MessageBase>& msg, nsecs\_t reltime, uint32\_t flags) \{

status\_t res =mEventQueue.postMessage(msg, reltime);

if (res == NO\_ERROR) \{

msg->wait();

return res;

MessageBase::wait()调用内部的Barrier::wait来实现等待，这意味着发送消息的线程将暂时停止执行，那么什么时候才能继续呢？显然得有人唤醒它才行。这个唤醒的地方隐藏在MessageBase::handleMessage()中，即：

/\*frameworks/native/services/surfaceflinger/MessageQueue.cpp\*/

void MessageBase::handleMessage(const Message&) \{

this->handler();

barrier.open();

\};

这其中的流程有点乱，我们以下图做下整理：

![20130521134730856][]

图 11‑32 Client::createSurface流程图

另外SurfaceFlinger中还有一个相似的消息推送函数postMessageAsync，从名称上就可以看出它是要求异步执行的，通俗来讲就是推送过后就直接返回了，无需等待执行结果，读者可以自行分析下源码。

绕了一圈后，终于轮到SurfaceFlinger工作线程来处理createSurface()了，这个函数我们在前面讲解“应用程序与BufferQueue的关系”时已经详细分析过了，这里不再赘述。

[20130521134450939]: /images/20220110/6f13a767b2774b0aa4f7eb1c826ee7c2.png
[20130521134526579]: /images/20220110/02fe48eb9e0f4c29bb1e92217a8bd971.png
[20130521134557906]: /images/20220110/70955a5e51ff4093bd784aaae3033816.png
[20130521134659953]: /images/20220110/74c0025fe31d41e3af9ced406318730e.png
[20130521134730856]: /images/20220110/6d1b11fa76ea4912b24f6cdb6152c0e9.png