[Android] GraphicBuffer之Framework层
一 前言
GraphicBuffer 是 SurfaceFlinger 中一块重要的内容, 它涉及到了我们应用程序的数据是如何和SurfaceFlinger进行传递的。
在介绍 GraphicBuffer 之前,我们先提出这样一个问题:我们应用程序的界面数据,是如何传递给 SurfaceFlinger 进行合成和显示的。是 Binder 吗?显然不是,Binder 传递不了这么大的数据。那么是共享内存吗,早期的界面数据的确是通过这种方式传递的,但是那已经是很早之前了。
前面我们介绍了SurfaceFlinger中的生产者和消费者模型, 在生产者申请 buffer 的时候, 如果拿到的 Slot 没有和 GraphicBuffer 进行绑定, 那么就会先创建一个 GraphicBuffer , 然后进行绑定
从这一篇开始,我们就来探究 GraphicBuffer 的工作原理。
1.1 GraphicBuffer 的创建
在前面介绍 dequeueBuffer 申请缓冲区的时候, 我们还说了一种逻辑, 那就是从 BufferQueue 中拿到的 slot 没有关联的 GraphicBuffer , 那么这种情况下还需要单独创建 GraphicBuffer ,这里我们就来看看 GraphicBuffer 的创建逻辑
[frameworks/native/libs/gui/BufferQueueProducer.cpp]
if (returnFlags & BUFFER_NEEDS_REALLOCATION) {
// 如果拿到的缓冲区的 flag 为 BUFFER_NEEDS_REALLOCATION ,就创建一个 GraphicBuffer
sp<GraphicBuffer> graphicBuffer = new GraphicBuffer(
width, height, format, BQ_LAYER_COUNT, usage,
{mConsumerName.string(), mConsumerName.size()});
}
在之前解读 BufferQueue的时候介绍了 BufferQueue 中的生产者和消费者,以及最重要的四个函数,其中的生产者在生成内容的时候,就会有这么一个过程;
- 生产者向 BufferQueue 中申请 slot(缓冲槽)
- 生产者拿到 slot,但是 slot 并没有关联对应的 GraphicBuffer(缓冲区)
- 生产者创建一个缓冲区,并将它与缓冲槽相关联。
如上代码,就是步骤2中的一个片段。接下来,我们看 GraphicBuffer 创建时的具体流程。
1.2 GraphicBuffer的构造函数
[frameworks/native/libs/ui/GraphicBuffer.cpp]
GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight,
PixelFormat inFormat, uint32_t inUsage, std::string requestorName)
: GraphicBuffer(inWidth, inHeight, inFormat, 1, static_cast<uint64_t>(inUsage), requestorName)
{
}
GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight, PixelFormat inFormat,
uint32_t inLayerCount, uint64_t inUsage, std::string requestorName)
: GraphicBuffer() {
mInitCheck = initWithSize(inWidth, inHeight, inFormat, inLayerCount, inUsage,
std::move(requestorName));
}
GraphicBuffer 的构造函数非常简单, 它只是调用了一个初始化函数 initWithSize。
1.3 GraphicBuffer::initWithSize
status_t GraphicBuffer::initWithSize(uint32_t inWidth, uint32_t inHeight,
PixelFormat inFormat, uint32_t inLayerCount, uint64_t inUsage,