Androird GDI之共享緩沖區(qū)機(jī)制
1 native_handle_t對(duì)private_handle_t 的包裹
private_handle_t是gralloc.so使用的本地緩沖區(qū)私有的數(shù)據(jù)結(jié)構(gòu)，而Native_handle_t是上層抽象的可以在進(jìn)程間傳遞的數(shù)據(jù)結(jié)構(gòu)。在客戶(hù)端是如何還原所傳遞的數(shù)據(jù)結(jié)構(gòu)呢？首先看看native_handle_t對(duì)private_handle_t的抽象包裝。
numFds= sNumFds=1;
numInts= sNumInts=8;
這個(gè)是Parcel中描述句柄的抽象模式。實(shí)際上是指的Native_handle所指向句柄對(duì)象的具體內(nèi)容：
numFds=1表示有一個(gè)文件句柄：fd/
numInts= 8表示后面跟了8個(gè)INT型的數(shù)據(jù)：magic,flags,size,offset,base,lockState,writeOwner,pid;
由于在上層系統(tǒng)不要關(guān)心buffer_handle_t中data的具體內(nèi)容。在進(jìn)程間傳遞buffer_handle_t(native_handle_t)句柄是其實(shí)是將這個(gè)句柄內(nèi)容傳遞到Client端。在客戶(hù)端通過(guò)Binder讀取readNativeHandle @Parcel.cpp新生成一個(gè)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;
}
這里需要提到的是為在構(gòu)造客戶(hù)端的native_handle時(shí)，對(duì)于對(duì)方傳遞過(guò)來(lái)的文件句柄的處理。由于不是在同一個(gè)進(jìn)程中，所以需要dup(…)一下為客戶(hù)端使用。這樣就將Native_handle句柄中的，客戶(hù)端感興趣的從服務(wù)端復(fù)制過(guò)來(lái)。這樣就將Private_native_t的數(shù)據(jù)：magic,flags,size,offset,base,lockState,writeOwner,pid;復(fù)制到了客戶(hù)端。
客戶(hù)端利用這個(gè)新的Native_buffer被Mapper傳回到gralloc.xxx.so中，獲取到native_handle關(guān)聯(lián)的共享緩沖區(qū)映射地址，從而獲取到了該緩沖區(qū)的控制權(quán)，達(dá)到了客服端和Server間的內(nèi)存共享。從SurfaceFlinger來(lái)看就是作圖區(qū)域的共享。
2 Graphic Mapper是干什么的？
服務(wù)端（SurfaceFlinger）分配了一段內(nèi)存作為Surface的作圖緩沖，客戶(hù)端怎樣在這個(gè)作圖緩沖區(qū)上工作呢？這個(gè)就是Mapper(GraphicBufferMapper)y要干的事情。兩個(gè)進(jìn)程間如何共享內(nèi)存，如何獲取到共享內(nèi)存？Mapper就是干這個(gè)得。需要利用到兩個(gè)信息：共享緩沖區(qū)設(shè)備句柄，分配時(shí)的偏移量。Mapper利用這樣的原理：
客戶(hù)端只有l(wèi)ock,unlock,實(shí)質(zhì)上就是mmap和ummap的操作。對(duì)于同樣一個(gè)共享緩沖區(qū)，偏移量才是總要的，起始地址不重要。實(shí)際上他們操作了同一物理地址的內(nèi)存塊。我們?cè)谏厦嬗懻摿薾ative_handle_t對(duì)private_handle_t 的包裹過(guò)程，從中知道服務(wù)端給客戶(hù)端傳遞了什么東西。
進(jìn)程1在共享內(nèi)存設(shè)備上預(yù)分配了8M的內(nèi)存。以后所有的分配都是在這個(gè)8M的空間進(jìn)行。對(duì)以該文件設(shè)備來(lái)講，8M物理內(nèi)存提交后，就實(shí)實(shí)在在的占用了8M內(nèi)存。每個(gè)每個(gè)進(jìn)程都可以同個(gè)該內(nèi)存設(shè)備共享該8M的內(nèi)存，他們使用的工具就會(huì)mmap。由于在mmap都是用0開(kāi)始獲取映射地址，所以所有的客戶(hù)端進(jìn)程都是有了同一個(gè)物理其實(shí)地址，所以此時(shí)偏移量和size就可以標(biāo)識(shí)一段內(nèi)存。而這個(gè)偏移量和size是個(gè)數(shù)值，從服務(wù)進(jìn)程傳遞到客戶(hù)端直接就可以使用。
3 GraphicBuffer（緩沖區(qū)代理對(duì)象）
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;
關(guān)系圖表：
GraphicBuffer :EGLNativeBase :android_native_buffer_t
GraphicBuffer(parcel &)建立本地的GraphicBuffer的數(shù)據(jù)native_buffer_t。在通過(guò)接收對(duì)方的傳遞的native_buffer_t 構(gòu)建GraphicBuffer。我們來(lái)看看在客戶(hù)端Surface：：lock獲取操作緩沖區(qū)的函數(shù)調(diào)用：
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建立一個(gè)在Client端建立了一個(gè)新的GraphicBuffer 對(duì)象，該對(duì)象通過(guò)（1）描述的原理將SurfaceFlinger的buffer_handle_t相關(guān)數(shù)據(jù)構(gòu)成新的客戶(hù)端buffer_handle_t數(shù)據(jù)。在客戶(hù)端的Surface對(duì)象就可以使用GraphicMapper對(duì)客戶(hù)端buffer_handle_t進(jìn)行mmap從而獲取到共享緩沖區(qū)的開(kāi)始地址了。
4 總結(jié)
Android在該節(jié)使用了共享內(nèi)存的方式來(lái)管理與顯示相關(guān)的緩沖區(qū)，他設(shè)計(jì)成了兩層，上層是緩沖區(qū)管理的代理機(jī)構(gòu)GraphicBuffer,及其相關(guān)的native_buffer_t,下層是具體的緩沖區(qū)的分配管理及其緩沖區(qū)本身。上層的對(duì)象是可以在經(jīng)常間通過(guò)Binder傳遞的，而在進(jìn)程間并不是傳遞緩沖區(qū)本身，而是使用mmap來(lái)獲取指向共同物理內(nèi)存的映射地址。
