(转)SurfaceFlinger GraphicBuffer内存共享缓冲区机制

http://blog.csdn.net/andyhuabing/article/details/7489776#comments

GraphicBuffer 是 Surface 系统中用于GDI内存共享缓冲区管理类，封装了与硬件相关的细节，从而简化应用层的处理逻辑

SurfaceFlinger是个服务端，而每个请求服务的应用程序都对应一个Client端，Surface绘图由Client进行，而由SurfaceFlinger对所有Client绘制的图合成进行输出，那么这两者是如何共享这块图形缓冲区的内存呢？简要之就是利用mmap/ummap，那么这些在android系统中是如何构架完成的呢？

frameworks\base\include\ui\GraphicBuffer.h 类定义：

class GraphicBuffer 

   : public EGLNativeBase<

    android_native_buffer_t,

    GraphicBuffer,

    LightRefBase, public Flattenable

EGLNativeBase 是一个模板类：

template

class EGLNativeBase : public NATIVE_TYPE, public REF

类 GraphicBuffer  继承LightRefBase支持轻量级引用计数控制

派生 Flattenable 用于数据序列化给Binder进行传输

我们来看下 android_native_buffer.h 文件，这个 android_native_buffer_t 结构：

typedef struct android_native_buffer_t

{

#ifdef __cplusplus

android_native_buffer_t() {

common.magic = ANDROID_NATIVE_BUFFER_MAGIC;

common.version = sizeof(android_native_buffer_t);

memset(common.reserved, 0, sizeof(common.reserved));

}

#endif

struct android_native_base_t common;

int width;

int height;

int stride;

int format;

int usage;

void* reserved[2];

buffer_handle_t handle;

void* reserved_proc[8];

} android_native_buffer_t;

注意这里有个关键的变量： buffer_handle_t handle; 这个就是显示内存分配与管理的私有数据结构

1、 native_handle_t 对 private_handle_t 的包裹

typedef struct

{

int version;        /* sizeof(native_handle_t) */

int numFds;         /* number of file-descriptors at &data[0] */

int numInts;        /* number of ints at &data[numFds] */

int data[0];        /* numFds + numInts ints */  这里是利用GCC的无定参数传递的写法

} native_handle_t;

/* keep the old definition for backward source-compatibility */

typedef native_handle_t native_handle;

typedef const native_handle* buffer_handle_t;

native_handle_t 是上层抽象的用于进程间传递的数据结构,对于 Gralloc 而言其内容就是：

data[0] 指向具体对象的内容，其中：

static const int sNumInts = 8;

static const int sNumFds = 1;

sNumFds=1表示有一个文件句柄：fd

sNumInts= 8表示后面跟了8个INT型的数据：magic,flags,size,offset,base,lockState,writeOwner,pid;

由于在上层系统不要关心buffer_handle_t中data的具体内容。在进程间传递buffer_handle_t(native_handle_t)

句柄是其实是将这个句柄内容传递到Client端。在客户端通过Binder读取readNativeHandle @Parcel.cpp新生成一个native_handle。

native_handle* Parcel::readNativeHandle() const

{

int numFds, numInts;

err = readInt32(&numFds);

err = readInt32(&numInts);

native_handle* h = native_handle_create(numFds, numInts);

for (int i=0 ; err==NO_ERROR && i

h->data[i] = dup(readFileDescriptor());

if (h->data[i] < 0) err = BAD_VALUE;

}

err = read(h->data + numFds, sizeof(int)*numInts);

...

}

这里构造客户端的native_handle时，对于fd进行dup处理(不同进程)，其它的直接读取复制使用.

利用函数dup，我们可以复制一个描述符。传给该函数一个既有的描述符，它就会返回一

个新的描述符，这个新的描述符是传给它的描述符的拷贝。这意味着，这两个描述符共享同一

个数据结构。

magic,flags,size,offset,base,lockState,writeOwner,pid 等复制到了客户端，从而为缓冲区共享获取到相应的信息

对于fd的写入binder特殊标志 BINDER_TYPE_FD：告诉Binder驱动这是一个fd描述符

status_t Parcel::writeFileDescriptor(int fd)

{

flat_binder_object obj;

obj.type = BINDER_TYPE_FD;

obj.flags = 0x7f | FLAT_BINDER_FLAG_ACCEPTS_FDS;

obj.handle = fd;

obj.cookie = (void*)0;

return writeObject(obj, true);

}

2、GraphicBuffer 内存分配

三种分配方式：

GraphicBuffer();

// creates w * h buffer

GraphicBuffer(uint32_t w, uint32_t h, PixelFormat format, uint32_t usage);

// create a buffer from an existing handle

GraphicBuffer(uint32_t w, uint32_t h, PixelFormat format, uint32_t usage,

uint32_t stride, native_handle_t* handle, bool keepOwnership);

其实最终都是通过函数：initSize()

status_t GraphicBuffer::initSize(uint32_t w, uint32_t h, PixelFormat format,

uint32_t reqUsage)

{

if (format == PIXEL_FORMAT_RGBX_8888)

format = PIXEL_FORMAT_RGBA_8888;

GraphicBufferAllocator& allocator = GraphicBufferAllocator::get();

status_t err = allocator.alloc(w, h, format, reqUsage, &handle, &stride);

if (err == NO_ERROR) {

this->width  = w;

this->height = h;

this->format = format;

this->usage  = reqUsage;

mVStride = 0;

}

return err;

}

利用 GraphicBufferAllocator 类分配内存：

首先加载 libGralloc.hwXX.so 动态库，分配一块用于显示的内存，屏蔽掉不同硬件平台的区别。

GraphicBufferAllocator::GraphicBufferAllocator()

: mAllocDev(0)

{

hw_module_t const* module;

int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);

LOGE_IF(err, "FATAL: can't find the %s module", GRALLOC_HARDWARE_MODULE_ID);

if (err == 0) {

gralloc_open(module, &mAllocDev);

}

}

分配方式有两种：

status_t GraphicBufferAllocator::alloc(uint32_t w, uint32_t h, PixelFormat format,

int usage, buffer_handle_t* handle, int32_t* stride)

{

if (usage & GRALLOC_USAGE_HW_MASK) {

err = mAllocDev->alloc(mAllocDev, w, h, format, usage, handle, stride);

} else {

err = sw_gralloc_handle_t::alloc(w, h, format, usage, handle, stride);

}

...

}

具体的内存分配方式如下：

3、共享句柄的传递

frameworks\base\libs\surfaceflinger_client\ISurface.cpp

客户端请求处理：BpSurface 类：

virtual sp requestBuffer(int bufferIdx, int usage)

{

Parcel data, reply;

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

data.writeInt32(bufferIdx);

data.writeInt32(usage);

remote()->transact(REQUEST_BUFFER, data, &reply);

sp buffer = new GraphicBuffer();

reply.read(*buffer);

return buffer;

}

这里利用 sp buffer = new GraphicBuffer(); 然后reply.read(*buffer)将数据利用 unflatten反序化到这个buffer中并返回这个本地new出来的GraphicBuffer对象，而这个数据是在哪里写入进去的呢？

服务端呼应处理： BnSurface 类：

status_t BnSurface::onTransact(

uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)

{

switch(code) {

case REQUEST_BUFFER: {

CHECK_INTERFACE(ISurface, data, reply);

int bufferIdx = data.readInt32();

int usage = data.readInt32();

sp buffer(requestBuffer(bufferIdx, usage));

if (buffer == NULL)

return BAD_VALUE;

return reply->write(*buffer);

}

requestBuffer函数服务端调用流程：

requestBuffer @ surfaceflinger\Layer.cpp

sp Layer::requestBuffer(int index, int usage)

{

buffer = new GraphicBuffer(w, h, mFormat, effectiveUsage);

...

return buffer;

}

如此的话，客户端利用new 的 GraphicBuffer() 对象从 Parcel中读取 native_handle 对象及其内容，而在服务端由同样由 requestBuffer 请求返回一个真正的GraphicBuffer对象。那么这两个数据如何序列化传递的呢？

flatten @ GraphicBuffer.cpp

status_t GraphicBuffer::flatten(void* buffer, size_t size,

int fds[], size_t count) const

{

...

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));

}

flatten的职能就是将GraphicBuffer的handle变量信息写到Parcel句中，接收端利用unflatten读取

status_t GraphicBuffer::unflatten(void const* buffer, size_t size,

int fds[], size_t count)

{

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;

}

经过以上操作，在客户端构造了一个对等的 GraphicBuffer对象，下面将继续讲两者如何操作相同的内存块

4、共享内存的管理 -- Graphic Mapper 功能

两个进程间如何共享内存，如何获取到共享内存？Mapper就是干这个得。需要利用到两个信息：共享缓冲区设备句柄，分配时的偏移量.客户端需要操作一块共享内存时，首先利用 registerBuffer 注册一个 buffer_handle_t，然后利用lock函数获取缓冲区首地址进行绘图，即利用lock及unlock对内存进行映射使用。

利用lock(mmap)及unlock(ummap)进行一个缓冲区的映射。

重要的代码如下：mapper.cpp

static int gralloc_map(gralloc_module_t const* module,

buffer_handle_t handle,

void** vaddr){

private_handle_t* hnd = (private_handle_t*)handle;

void* mappedAddress = mmap(0, size,

PROT_READ|PROT_WRITE, MAP_SHARED, hnd->fd, 0);

if (mappedAddress == MAP_FAILED) {

LOGE("Could not mmap %s", strerror(errno));

return -errno;

}

hnd->base = intptr_t(mappedAddress) + hnd->offset;

*vaddr = (void*)hnd->base;

return 0;

}

static int gralloc_unmap(gralloc_module_t const* module,

buffer_handle_t handle){

private_handle_t* hnd = (private_handle_t*)handle;

void* base = (void*)hnd->base;

size_t size = hnd->size;

munmap(base, size);

hnd->base = 0;

return 0;

}

利用buffer_handle_t与private_handle_t句柄完成共享进程数据的共享：

总结：

Android在该节使用了共享内存的方式来管理与显示相关的缓冲区，他设计成了两层，上层是缓冲区管理的代理机构GraphicBuffer,

及其相关的native_buffer_t,下层是具体的缓冲区的分配管理及其缓冲区本身。上层的对象是可以在经常间通过Binder传递的，而在进程间并不是传递缓冲区本身，而是使用mmap来获取指向共同物理内存的映射地址。