GUI系统之SurfaceFlinger(6)BufferQueue中的缓冲区分配

我不是女神ヾ 2022-01-12 19:43 144阅读 0赞

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

### 1.1.1 BufferQueue中的缓冲区分配 ###

我们知道，BufferQueue中有一个mSlots数组用于管理其内的各缓冲区，最大容量为32。从它的声明方式来看，这个mSlots在程序一开始就静态分配了32个BufferSlot大小的空间。不过这并不代表缓冲区也是一次性静态分配的，恰恰相反，从BufferSlot的内部变量指针mGraphicBuffer可以看出，缓冲区的空间分配应当是动态的(从下面的注释也能看出一些端倪)：

// mGraphicBuffer points to the buffer allocated for this slot or isNULL if no buffer has been allocated.

sp<GraphicBuffer> mGraphicBuffer;

现在的问题就转移为，在什么情况下会给一个Slot实际的分配空间呢？

首先能想到的就是dequeueBuffer。理由如下：

Ø 缓冲区的空间分配应该既要满足使用者的需求，又要防止浪费。后面这一点mSlots已经满足了，因为它并没有采取一开始就静态预分配的方式

Ø 既然Producer对buffer的操作是“主动”的，那么就意味着它是整个需求的发起者。换句话说，只要它没有dequeueBuffer，或者dequeueBuffer时能获取到可用的缓冲区，那当然就没有必要再重新分配空间了

来详细分析下这个函数：

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

status\_t BufferQueue::dequeueBuffer(int \*outBuf, uint32\_t w,uint32\_t h, uint32\_t format, uint32\_t usage) \{…

status\_t  returnFlags(OK);

…

\{ // Scope for the lock

Mutex::Autolocklock(mMutex); /\*这里采用了自动锁，所以上面需要加个“\{”，这样当lock变量生

命期结束后锁也就自动释放了。这种写法非常常见\*/

…

int found = -1;

int foundSync = -1;

int dequeuedCount = 0;

bool tryAgain = true;

while (tryAgain) \{/\*Step1. 循环查找符合要求的slot\*/

…

found = INVALID\_BUFFER\_SLOT;//初始值

foundSync =INVALID\_BUFFER\_SLOT;

dequeuedCount = 0;

for (int i = 0; i< mBufferCount; i++) \{

const intstate = mSlots\[i\].mBufferState;

/\*Step2.统计dequeued buffer数量，后面会用到\*/

if (state ==BufferSlot::DEQUEUED) \{

dequeuedCount\++;

if (false) \{

//肯定不会走这边

\} else \{

if (state== BufferSlot::FREE) \{ /\*Step3.寻找符合要求的Slot\*/

boolisOlder = mSlots\[i\].mFrameNumber <mSlots\[found\].mFrameNumber;

if(found < 0 || isOlder) \{

foundSync = i;

found = i; //找到符合要求的Slot

\}// if (state ==BufferSlot::FREE)结束

\}//if(false)else结束

\}// for循环结束

/\*Step4.如果Client没有设置buffer count的话，就不允许dequeue一个以上的buffer\*/

if(!mClientBufferCount && dequeuedCount) \{

ST\_LOGE("dequeueBuffer:can't dequeue multiple buffers without setting the buffer count");

return-EINVAL;

…

/\*Step5. 判断是否要重试\*/

tryAgain = found== INVALID\_BUFFER\_SLOT;

if (tryAgain) \{

mDequeueCondition.wait(mMutex);

\}//while循环结束

if (found ==INVALID\_BUFFER\_SLOT) \{

/\*因为前面while循环如果没找到的话是不会返回的，所以理论上不会出现这种情况\*/

ST\_LOGE("dequeueBuffer: no available buffer slots");

return -EBUSY;

const int buf = found;

\*outBuf = found; //返回值

/\*成功找到可用的Slot序号，接下来就开始对这个指定的Slot进行初始操作，及状态变迁等\*/

…

mSlots\[buf\].mBufferState = BufferSlot::DEQUEUED;/\*Step6.Buffer状态改变\*/

constsp<GraphicBuffer>& buffer(mSlots\[buf\].mGraphicBuffer);

if ((buffer == NULL)|| (uint32\_t(buffer->width)  != w) ||(uint32\_t(buffer->height) != h) ||

(uint32\_t(buffer->format) != format) || ((uint32\_t(buffer->usage)& usage) != usage))

status\_t error;

/\*Step7. 分配GraphicBuffer空间\*/

sp<GraphicBuffer> graphicBuffer(mGraphicBufferAlloc->createGraphicBuffer(

w,h, format, usage, &error));

…

mSlots\[buf\].mGraphicBuffer = graphicBuffer; //这个Slot终于分配到空间了

…

returnFlags |=ISurfaceTexture::BUFFER\_NEEDS\_REALLOCATION;

…

\}  // 自动锁lock结束的地方

…

return returnFlags;

因为这个函数很长，我们尽量只留下最核心的部分。从大的方向上看，Step1-Step5是在查找一个可用的Slot序号。从Step6开始，就针对这一指定的Slot进行操作了。下面我们分步来解释。

Step1@BufferQueue::dequeueBuffer。进入while循环，退出的条件是tryAgain为false。这个变量默认值是true，如果一轮循环结束后found的值不再是INVALID\_BUFFER\_SLOT，就会变成false，从而结束整个while循环。

循环的主要功能就是查找符合要求的Slot，其中found变量是一个int值，指的是这个BufferSlot在mSlots数组中的序号。

Step2@BufferQueue::dequeueBuffer。统计当前已经被dequeued的buffer数量，这将用于后面的判断，即假如Client没有设置buffer count的话，那么它会被禁止dequeue一个以上的buffer。

Step3@BufferQueue::dequeueBuffer。假如当前的buffer状态是FREE，那么这个Slot就可以进入备选了。为什么只是备选而不是直接返回这一结果呢？因为当前的mSlots中很可能有多个符合条件的Slot，当然需要挑选其中最匹配的。判断的依据是当前符合要求的Slot的mFrameNumber是否比上一次选中的最优Slot的mFrameNumber小。代码如下：

bool isOlder =mSlots\[i\].mFrameNumber <mSlots\[found\].mFrameNumber;

Step4@BufferQueue::dequeueBuffer。这里的判断来源于前面第二步的计算结果，一旦发现dequeue的数量“超标”，就直接出错返回

Step5@BufferQueue::dequeueBuffer。经过上述几个步骤，我们已经扫描了一遍mSlots中的所有成员了，这时就要决定是否可以退出循环。前面已经说过，如果成功找到有效的Slot就可以不用再循环查找了，否则tryAgain仍然是true。假如是后一种情况，证明当前已经没有FREE的Slot了，这时如果直接进入下一次循环，结果通常也是一样的，反而浪费了CPU资源。所以就需要使用条件锁，代码如下：

mDequeueCondition.wait(mMutex);

当有Buffer被释放时，这个锁的条件就会满足。

Step6@BufferQueue::dequeueBuffer。根据Buffer的状态迁移图，当处于FREE状态的Buffer被dequeue成功后，它将进入DEQUEUED,所以这里我们需要改变mBufferState。

Step7@BufferQueue::dequeueBuffer。通过上述几个步骤的努力，现在我们已经成功地寻找到可用的Slot序号了，但是这并不代表这个Slot可以直接使用，为什么？最明显的一个原因就是这个Slot可能还没有分配空间。

因为BufferSlot:: mGraphicBuffer初始值是NULL，假如我们是第一次使用它，必然是需要为它分配空间的。另外，即便mGraphicBuffer不为空，但如果用户所需要的Buffer属性(比如width、height、format等等)和当前这个不符合，那么也还是要重新分配。

分配空间使用的是mGraphicBufferAlloc这个Allocator，这里暂不深究其中的实现了。

如果重新分配了空间，那么最后的返回值中需要加上BUFFER\_NEEDS\_REALLOCATION标志。客户端在发现这个标志后，它还应调用requestBuffer()来取得最新的buffer地址。

我们前一小节SurfaceTextureClient::dequeueBuffer()的Step3就是其中一个例子，这里统一解释一下为什么。为了方便阅读，再把这部分代码简单地列出来：

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

/\*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;

当mSurfaceTexture->dequeueBuffer成功返回后，buf得到了mSlots中可用数组成员的序号(对应这一小节的found变量)。但一个很显然的问题是，既然客户端和BufferQueue运行于两个不同的进程中，那么它们两者中的mSlots\[buf\]会指向同一块物理内存吗？

先来看下BpSurfaceTexture中是如何发起binder申请的：

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

class BpSurfaceTexture : public BpInterface<ISurfaceTexture>

\{ …

virtualstatus\_t requestBuffer(int bufferIdx, sp<GraphicBuffer>\* buf) \{//函数入参有两个

Parcel data, reply;

data.writeInterfaceToken(ISurfaceTexture::getInterfaceDescriptor());

data.writeInt32(bufferIdx);//只写入了bufferIdx，也就是BnSurfaceTexture实际上是看不到buf的

status\_t result=remote()->transact(REQUEST\_BUFFER, data, &reply);

…

bool nonNull =reply.readInt32();//读取的是什么？我们可以去BnSurfaceTexture中去确认下

if (nonNull) \{

\*buf = newGraphicBuffer(); //生成一个GraphicBuffer，看到没，这是一个本地实例

reply.read(\*\*buf);/\*buf是一个sp指针,那么\*\*sp实际上得到的就是这个智能指针所指向的

对象。在这个例子中指的是mSlots\[buf\].buffer\*/

result =reply.readInt32();/\*读取结果\*/

return result;

Native层的BpXXX/BnXXX与Java层的不同之处在于，后者通常都是依赖于aidl来自动生成这两个类，而前者则是手工完成的。也正因为是手工，使用起来才也更灵活。比如在ISurfaceTexture这个例子中，开发者就耍了点技巧——SurfaceTextureClient中调用了ISurfaceTexture::requestBuffer(intslot, sp<GraphicBuffer>\* buf)，这个函数虽然形式上有两个参数，但只有第一个是入参，后一个则是出参。在实际的binder通信中，只有slot这个int值传递给了对方进程，而buf则自始至终都是SurfaceTextureClient进程在处理，只不过从调用者的角度来讲，好像是由ISurfaceTexture的Server端完成了对buf的赋值。

从BpSurfaceTexture::requestBuffer这个函数实现中可以看到，Client端进程向server端请求了一个REQUEST\_BUFFER服务，然后通过读取返回值来获得缓冲区信息。为了让大家能看清楚这其中的细节，我们有必要先分析下BnSurfaceTexture这边具体是如何响应这个服务请求的，如下所示：

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

status\_t BnSurfaceTexture::onTransact(uint32\_t code, constParcel& data, Parcel\* reply, uint32\_t flags)

switch(code) \{

case REQUEST\_BUFFER: \{

CHECK\_INTERFACE(ISurfaceTexture, data, reply);

int bufferIdx   =data.readInt32();//首先读取要处理的Slot序号

sp<GraphicBuffer> buffer; //生成一个GraphicBuffer智能指针

int result =requestBuffer(bufferIdx, &buffer);//调用本地端的实现

reply->writeInt32(buffer != 0);//注意，第一个写入的值是判断buffer不为空，

//也就是一个bool值

if (buffer != 0) \{

reply->write(\*buffer); //好，真正的内容在这里，后面我们详细解释

reply->writeInt32(result);//写入结果值

return NO\_ERROR;

\} break;

针对BnSurfaceTexture的写入顺序，显然BpSurfaceTexture必须要按照同样的顺序来读取。

(1)因而它首先获取一个int32值，赋予nonNull变量，这个值对应的是buffer != 0逻辑判断。假如确实不为空的话，那说明我们可以接着读取GraphicBuffer了

(2)两边对GraphicBuffer变量的写和读分别是：

reply->write(\*buffer);//写入

reply.read(\*\*buf);//读取

(3)读取result结果值

在第二步中，Server端写入的GraphicBuffer对象需要在Client中完整地复现出来。根据我们在binder章节的学习，具备这种能力的binder对象应该是继承了Flattenable。实际上呢？

class GraphicBuffer: publicANativeObjectBase<ANativeWindowBuffer, GraphicBuffer,

LightRefBase<GraphicBuffer> >,public Flattenable

从GraphicBuffer声明来看，确实是证明了我们的猜测。

接下来我们只需要看下它是如何实现flatten和unflatten的，相信谜底就能揭晓了。

/\*frameworks/native/libs/ui/GraphicBuffer.cpp\*/

status\_t GraphicBuffer::flatten(void\* buffer, size\_t size, intfds\[\], size\_t count) const

\{ …

int\* buf =static\_cast<int\*>(buffer);

…

if (handle) \{

buf\[6\] = handle\->numFds;

buf\[7\] = handle\->numInts;

native\_handle\_t const\*const h = handle;

memcpy(fds,     h->data,             h->numFds\*sizeof(int));

memcpy(&buf\[8\], h->data + h->numFds, h->numInts\*sizeof(int));

return NO\_ERROR;

这个函数中，我们最关心的是handle这个变量的flatten，它实际上是GraphicBuffer中打开的一个ashmem句柄，因而也就是两边进程共享缓冲区的关键。与handle相关的分别是buf\[6\]-buf\[8\]以及fds，再来看下Client端是如何还原出一个GraphicBuffer的。

status\_t GraphicBuffer::unflatten(void const\* buffer, size\_t size,int fds\[\], size\_t count)

\{…

int const\* buf =static\_cast<int const\*>(buffer);

…

const size\_t numFds  = buf\[6\];

const size\_t numInts =buf\[7\];

…

if (numFds || numInts) \{…

native\_handle\* h = native\_handle\_create(numFds, numInts);

memcpy(h->data,          fds,    numFds\*sizeof(int));

memcpy(h->data +numFds, &buf\[8\], numInts\*sizeof(int));

handle = h;

\} else \{ …

\} …

if (handle != 0) \{

mBufferMapper.registerBuffer(handle);

return NO\_ERROR;

同样，unflatten中的操作依据的也是flatten时写入的格式。其中最重要的两个函数是native\_handle\_create()和registerBuffer()。前一个函数生成native\_handle实例，并将相关数据拷贝到其内部。另一个registerBuffer则属于GraphicBufferMapper类中的实现，成员变量mBufferMapper是在GraphicBuffer在构造函数中生成的，它所承担的任务是和Gralloc打交道，代码如下：

GraphicBufferMapper::GraphicBufferMapper()

hw\_module\_t const\* module;

int err = hw\_get\_module(GRALLOC\_HARDWARE\_MODULE\_ID, &module);

这里出现了我们熟悉的Gralloc的moduleid，不清楚的可以回头看下Gralloc这小节的介绍。GraphicBufferMapper::registerBuffer()只是一个中介作用，它会直接调用gralloc\_module\_t::registerBuffer()，那么后者究竟完成了什么功能？因为这个函数的实现与具体平台有关，我们以msm7k为例大概看下：

/\*hardware/msm7k/libgralloc/Mapper.cpp\*/

int gralloc\_register\_buffer(gralloc\_module\_t const\* module,buffer\_handle\_t handle)

\{…

private\_handle\_t\* hnd =(private\_handle\_t\*)handle;

…

err =gralloc\_map(module, handle, &vaddr);

return err;

可以看到，通过handle句柄，Client端可以将指定的内存区域映射到自己的进程空间中，而这块区域与BufferQueue中所指向的物理空间是一致的，从而成功地实现了缓冲区的共享。

这样子在SurfaceTextureClient::dequeueBuffer()中，当遇到结果中包含有BUFFER\_NEEDS\_REALLOCATION的情况时，我们再通过requestBuffer()得到的结果来“刷新”Client这端mSlots\[\]所管辖的缓冲区信息，以保证SurfaceTextureClient与BufferQueue能在任何情况下都对32个BufferSlot保持数据上的高度一致。这也是后面它们能正确实施“生产者-消费者”模型的基础。