Androird GDI之共享緩沖區機制

1  native_handle_t對private_handle_t 的包裹

     private_handle_t是gralloc.so使用的本地緩沖區私有的數據結構，而Native_handle_t是上層抽象的可以在進程間傳遞的數據結構。在客戶端是如何還原所傳遞的數據結構呢？首先看看native_handle_t對private_handle_t的抽象包裝。

numFds= sNumFds=1;

numInts= sNumInts=8;

這個是Parcel中描述句柄的抽象模式。實際上是指的Native_handle所指向句柄對象的具體內容：

numFds=1表示有一個文件句柄：fd/

numInts= 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

{

…

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

    ….

return h;

}

     這裡需要提到的是為在構造客戶端的native_handle時，對於對方傳遞過來的文件句柄的處理。由於不是在同一個進程中，所以需要dup(…)一下為客戶端使用。這樣就將Native_handle句柄中的，客戶端感興趣的從服務端復制過來。這樣就將Private_native_t的數據：magic,flags,size,offset,base,lockState,writeOwner,pid;復制到了客戶端。

     客戶端利用這個新的Native_buffer被Mapper傳回到gralloc.xxx.so中，獲取到native_handle關聯的共享緩沖區映射地址，從而獲取到了該緩沖區的控制權，達到了客服端和Server間的內存共享。從SurfaceFlinger來看就是作圖區域的共享。

2 Graphic Mapper是干什麼的？

    服務端（SurfaceFlinger）分配了一段內存作為Surface的作圖緩沖，客戶端怎樣在這個作圖緩沖區上工作呢？這個就是Mapper(GraphicBufferMapper)y要干的事情。兩個進程間如何共享內存，如何獲取到共享內存？Mapper就是干這個得。需要利用到兩個信息：共享緩沖區設備句柄，分配時的偏移量。Mapper利用這樣的原理：

    客戶端只有lock,unlock,實質上就是mmap和ummap的操作。對於同樣一個共享緩沖區，偏移量才是總要的，起始地址不重要。實際上他們操作了同一物理地址的內存塊。我們在上面討論了native_handle_t對private_handle_t 的包裹過程，從中知道服務端給客戶端傳遞了什麼東西。

        進程1在共享內存設備上預分配了8M的內存。以後所有的分配都是在這個8M的空間進行。對以該文件設備來講，8M物理內存提交後，就實實在在的占用了8M內存。每個每個進程都可以同個該內存設備共享該8M的內存，他們使用的工具就會mmap。由於在mmap都是用0開始獲取映射地址，所以所有的客戶端進程都是有了同一個物理其實地址，所以此時偏移量和size就可以標識一段內存。而這個偏移量和size是個數值，從服務進程傳遞到客戶端直接就可以使用。

3 GraphicBuffer（緩沖區代理對象）

typedef struct android_native_buffer_t

{

    struct android_native_base_t common;

    int width;

    int height;

    int stride;

    int format;

    int usage;

     …

    buffer_handle_t handle;

     …

} android_native_buffer_t;

關系圖表：

GraphicBuffer :EGLNativeBase :android_native_buffer_t

GraphicBuffer(parcel &)建立本地的GraphicBuffer的數據native_buffer_t。在通過接收對方的傳遞的native_buffer_t 構建GraphicBuffer。我們來看看在客戶端Surface：：lock獲取操作緩沖區的函數調用：

Surface::lock(SurfaceInfo* other, Region* dirtyIn, bool blocking)

     {int Surface::dequeueBuffer(android_native_buffer_t** buffer)（Surface）

        {status_t Surface::getBufferLocked(int index, int usage)

          {

               sp buffer = s->requestBuffer(index, usage);

           {

virtual sp requestBuffer(int bufferIdx, int usage)

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

   sp buffer = new GraphicBuffer(reply);

Surface：：Lock建立一個在Client端建立了一個新的GraphicBuffer 對象，該對象通過（1）描述的原理將SurfaceFlinger的buffer_handle_t相關數據構成新的客戶端buffer_handle_t數據。在客戶端的Surface對象就可以使用GraphicMapper對客戶端buffer_handle_t進行mmap從而獲取到共享緩沖區的開始地址了。

4 總結

   Android在該節使用了共享內存的方式來管理與顯示相關的緩沖區，他設計成了兩層，上層是緩沖區管理的代理機構GraphicBuffer,及其相關的native_buffer_t,下層是具體的緩沖區的分配管理及其緩沖區本身。上層的對象是可以在經常間通過Binder傳遞的，而在進程間並不是傳遞緩沖區本身，而是使用mmap來獲取指向共同物理內存的映射地址