# Androird GDI之共享緩沖區機制 ### 1? native_handle_t對private_handle_t 的包裹 private_handle_t是gralloc.so使用的本地緩沖區私有的數據結構，而Native_handle_t是上層抽象的可以在進程間傳遞的數據結構。在客戶端是如何還原所傳遞的數據結構呢？首先看看native_handle_t對private_handle_t的抽象包裝。 [](http://hi.csdn.net/attachment/201006/14/0_12765041031rsn.gif)[](http://hi.csdn.net/attachment/201006/14/0_1276504107ekdp.gif) 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] ?? } ?? 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是個數值，從服務進程傳遞到客戶端直接就可以使用。 [](http://hi.csdn.net/attachment/201006/14/0_1276504116JHZ8.gif)[](http://hi.csdn.net/attachment/201006/14/0_1276504121th7n.gif) ### 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來獲取指向共同物理內存的映射地址。