GUI系统之SurfaceFlinger(4)opengl es本地窗口SurfaceTextureClient

- 日理万妓 2022-10-02 03:54 271阅读 0赞

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

### 1.1.1 SurfaceTextureClient ###

针对应用程序端的本地窗口是SurfaceTextureClient，和FramebufferNativeWindow一样，它必须继承ANativeWindow：

class SurfaceTextureClient

: publicANativeObjectBase<ANativeWindow, SurfaceTextureClient,RefBase>

这个本地窗口当然也需要实现ANativeWindow所制定的“协议”，我们的重点是关注它与前面的FramebufferNativeWindow有什么不同。SurfaceTextureClient的构造函数只是简单地调用了init函数，后者则对ANativeWindow::dequeueBuffer等函数指针及内部变量赋了初值。由于整个函数的功能很简单，我们只摘录其中的一部分：

/\*frameworks/native/libs/gui/SurfaceTextureClient.cpp\*/

void SurfaceTextureClient::init() \{

/\*给ANativeWindow中的函数指针赋值\*/

ANativeWindow::setSwapInterval  =hook\_setSwapInterval;

ANativeWindow::dequeueBuffer    = hook\_dequeueBuffer;

…

/\*为各内部变量赋值，因为此时用户还没有真正发起申请，所以基本是0\*/

mReqWidth = 0;

mReqHeight = 0;

…

mDefaultWidth = 0;

mDefaultHeight = 0;

mUserWidth = 0;

mUserHeight = 0;…

SurfaceTextureClient是面向Android系统中所有UI应用程序的，也就是说它承担着单个应用进程中的UI显示需求。基于这点考虑，可以推测出它的内部实现至少会有以下几点：

Ø  提供给上层(主要是java层)绘制图像的“画板”

前面说过，这个本地窗口分配的内存应该不是来自于帧缓冲区，那么具体是由谁分配的，又是如何管理的呢？

Ø  它与SurfaceFlinger间是如何分工的

显然SurfaceFlinger需要收集系统中所有应用程序绘制的图像数据，然后集中显示到物理屏幕上。在这个过程中，SurfaceTextureClient扮演了什么样的角色呢？

我们先来解释下这个类中的一些重要的成员变量，如下表所示：

表格 11‑4 SurfaceTextureClient部分成员变量一览

<table style="color:rgb(0,0,0); font-family:Arial; font-size:14.399999618530273px; line-height:26px"> 
 <tbody> 
 <tr> 
 <td style="background-color:rgb(191,191,191)"> 成员变量 </td> 
 <td style="background-color:rgb(191,191,191)"> 说明 </td> 
 </tr> 
 <tr> 
 <td> sp&lt;ISurfaceTexture&gt; mSurfaceTexture </td> 
 <td> 这个变量是SurfaceTextureClient的核心，很多“协议”就是通过它实现的，后面会有详细讲解 </td> 
 </tr> 
 <tr> 
 <td> BufferSlot mSlots[NUM_BUFFER_SLOTS] </td> 
 <td> 从名称上可以看出，这是Client内部用于存储buffer的地方，容量NUM_BUFFER_SLOTS最多达32个。BufferSlot类内部又由一个GraphicBuffer和一个dirtyRegion组成，当有用户dequeueBuffer时就会分配真正的空间 </td> 
 </tr> 
 <tr> 
 <td> uint32_t &nbsp;mReqWidth </td> 
 <td> SurfaceTextureClient中有多组相似的宽高变量，它们之间是有区别的。这里的宽和高是指下一次dequeue时将会申请的尺寸，初始值都是1 </td> 
 </tr> 
 <tr> 
 <td> uint32_t &nbsp;mReqHeight </td> 
 </tr> 
 <tr> 
 <td> uint32_t mReqFormat </td> 
 <td> 和上面的两变量类似，这是指下次dequeue时将会申请的buffer的像素格式，初始值是PIXEL_FORMAT_RGBA_8888 </td> 
 </tr> 
 <tr> 
 <td> uint32_t mReqUsage </td> 
 <td> 指下次dequeue时将会指定的usage类型 </td> 
 </tr> 
 <tr> 
 <td> Rect mCrop </td> 
 <td> Crop表示“修剪”，这个变量将在下次queue时用于修剪缓冲区，可以调用setCrop来设置具体的值 </td> 
 </tr> 
 <tr> 
 <td> int mScalingMode </td> 
 <td> 同样，这个变量将用于下次queue时对缓冲区进行scale，可以调用setScalingMode来设置具体的值 </td> 
 </tr> 
 <tr> 
 <td> uint32_t mTransform </td> 
 <td> 用于下次queue时的图形翻转等操作(Transform) </td> 
 </tr> 
 <tr> 
 <td> uint32_t mDefaultWidth </td> 
 <td> 默认情况下的缓冲区宽高值 </td> 
 </tr> 
 <tr> 
 <td> uint32_t mDefaultHeight </td> 
 </tr> 
 <tr> 
 <td> uint32_t mUserWidth </td> 
 <td> 如果不为零的话，就是应用层指定的值，将会覆盖前面的mDefaultWidth/ mDefaultHeight </td> 
 </tr> 
 <tr> 
 <td> uint32_t mUserHeight </td> 
 </tr> 
 <tr> 
 <td> sp&lt;GraphicBuffer&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mLockedBuffer </td> 
 <td> 这三个值需要锁的保护，接下来还会有分析 </td> 
 </tr> 
 <tr> 
 <td> sp&lt;GraphicBuffer&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mPostedBuffer </td> 
 </tr> 
 <tr> 
 <td> Region mDirtyRegion </td> 
 </tr> 
 </tbody> 
</table>

从这些内部变量的描述中，我们可以大概了解到两点：SurfaceTextureClient中将通过mSurfaceTexture来获得buffer，而且这些缓冲区会被记录在mSlots数组中。接下来就来分析其中的实现细节。

前面SurfaceTextureClient构造函数里我们看到ANativeWindow中的函数指针赋予的是各种以hook开头的函数，这些函数内部又直接调用了SurfaceTextureClient中真正的实现，比如hook\_dequeueBuffer对应的是dequeueBuffer。这就好像是“钩子”一样，所以称之为hook。

int SurfaceTextureClient::dequeueBuffer(android\_native\_buffer\_t\*\*buffer) \{…

Mutex::Autolocklock(mMutex);

int buf = -1;

/\*Step1. 宽高计算\*/

int reqW = mReqWidth ?mReqWidth : mUserWidth;

int reqH = mReqHeight ? mReqHeight :mUserHeight;

/\*Step2. dequeueBuffer得到一个缓冲区\*/

status\_t result =mSurfaceTexture->dequeueBuffer(&buf, reqW, reqH,mReqFormat, mReqUsage);

…

sp<GraphicBuffer>& gbuf(mSlots\[buf\].buffer);//注意buf只是一个int值，代表的是mSlots数组序号

…

/\*Step3. requestBuffer\*/

if ((result &ISurfaceTexture::BUFFER\_NEEDS\_REALLOCATION) || gbuf == 0) \{

result =mSurfaceTexture->requestBuffer(buf, &gbuf);

…

\*buffer = gbuf.get();

return OK;

Step1@ SurfaceTextureClient::dequeueBuffer。用于UI绘制的图形缓冲区一定有宽高属性，具体的值由mReqWidth/mReqHeight或者mUserWidth/mUserHeight决定，其中前者的优先级比后者高

Step2@ SurfaceTextureClient::dequeueBuffer。可以看到，真正执行dequeueBuffer操作的确实是mSurfaceTexture(ISurfaceTexture)。这个变量的赋值有两个来源：作为SurfaceTextureClient的构造函数参数传入，然后间接调用setISurfaceTexture来设置的;或者SurfaceTextureClient的子类通过直接调用setISurfaceTexture来生成。

在应用进程环境中，属于后面一种情况。

具体流程就是：当Java层的Surface进行init时，实际上执行的函数是Surface\_init@android\_view\_Surface.cpp。这个JNI函数将进一步调用SurfaceComposerClient::createSurface生成一个SurfaceControl，后者是用于管理Surface的类。它将在SurfaceControl::getSurface时生成一个Surface实例，在构造时通过SurfaceControl:: getSurfaceTexture来获得一个ISurfaceTexture。而Surface类实际上又继承自SurfaceTextureClient，所以它可以调用setISurfaceTexture。

由于Android源码有多处称为Surface的地方，取名极其混乱，我们下面通过一张完整的流程图来帮助大家把这些关系理顺：

![20130521130442658][]

图 11‑10 ISurfaceTexture创建流程

从这个图中可以看到，ISurfaceTexture是由ISurface::getSurfaceTexture生成的，而ISurface则是由SurfaceFlinger生成的。在这一过程中，总共使用到了三个匿名binderserver，它们所提供的接口整理如下表：

表格 11‑5 与Surface相关的三个匿名binder

由此可见，这三个匿名binder是一环扣一环的，也就是说我们访问的顺序只能是ISurfaceComposerClientàISurfaceàISurfaceTexture。当然，第一个匿名binder就一定是需要由一个实名binder来提供，它就是SurfaceFlinger，而SurfaceFlinger则是在ServiceManager中“注册在案”的。具体是在SurfaceComposerClient::onFirstRef()这个函数中，通过向ServiceManager查询名称为“SurfaceFlinger”的binder server来获得的。不过和其它常见binder server不同的是，SurfaceFlinger虽然在ServiceManager中注册的名称为“SurfaceFlinger”，但它在server端实现的binder接口却是ISurfaceComposer，因而SurfaceComposerClient得到的其实是ISurfaceComposer，这点大家要特别注意，否则可能会搞乱。

//我们可以从SurfaceFlinger的继承关系中看出这一区别，如下代码片断

class SurfaceFlinger :

publicBinderService<SurfaceFlinger>, //在ServiceManager中注册为“SurfaceFlinger”

public BnSurfaceComposer, //实现的接口却叫ISurfaceComposer，不知道为什么要这么设计。。。

绕了一大圈后，我们接着分析前面dequeueBuffer函数的实现。很显然SurfaceTextureClient只是一个中介，它间接调用mSurfaceTexture也就是ISurfaceTexture的服务。那么ISurfaceTexture在Server端又是由谁来完成的呢？

![20130521130459080][]

图 11‑11 ISurfaceTexture的本地端实现

因为这里面牵扯到很多新的类，我们先不做过多解释，到后面BufferQueue小节再详细分析其中的依赖关系。

当mSurfaceTexture->dequeueBuffer返回后，buf变量就是mSlots\[\]数组中可用的成员序号。接下来就要通过这个序号来获取真正的buffer地址，即mSlots\[buf\].buffer。

Step3@ SurfaceTextureClient::dequeueBuffer。假如返回值result中的标志包含了BUFFER\_NEEDS\_REALLOCATION，说明BufferQueue为这个Slot重新分配了空间，具体细节请参见下一个小节。此时我们还需要另外调用requestBuffer来确定gbuf的值，这其中又牵涉到很多东西，我们放在下面小节统一解释原因。

通过这两个小节，我们学习了显示系统中两个重要的本地窗口，即FramebufferNativewindow和SurfaceTextureClient。第一个窗口是专门为SurfaceFlinger服务的，它由Gralloc提供支持，相对逻辑上很好理解。而SurfaceTextureClient则是为应用程序服务的，同时它从本质上还是由SurfaceFlinger服务统一管理的，因而涉及到很多跨进程的通信细节。这个小节我们只是简单地勾勒出其中的框架，接下去就要分几个方面来做完整的分析了。

Ø  BufferQueue

为应用程序服务的本地窗口SurfaceTextureClient在server端的实现是BufferQueue。我们将详细解析BufferQueue的内部实现，并结合应用程序端的使用流程来理解清楚它们之间的关系。

Ø  Buffer、Consumer、Producer是“生产者-消费者”模型中的三个参与对象，如何协调好它们的工作是应用程序能否正常显示UI的关键。在接下来内容的安排上，我们先讲解Buffer(BufferQueue)与Producer(应用程序)间的交互，然后再专门切入Consumer(SurfaceFlinger)做详细分析

[20130521130442658]: /images/20220113/fd915d894afb486a87933f482f617623.png
[20130521130459080]: /images/20220113/901f417a04404cfe869383bd1d4a022b.png