Android GUI系統之SurfaceFlinger(2) Gralloc與Framebuffer

1.1 Gralloc與Framebuffer

相信做過Linux開發的人對framebuffer不會太陌生，它是內核系統提供的一個與硬件無關的顯示抽象層。之所以稱之為buffer，是由於它也是系統存儲空間的一部分，是一塊包含屏幕顯示信息的緩沖區。由此可見，在“一切都是文件”的Linux系統中，Framebuffer被看成了終端monitor的“化身”。它借助於文件系統向上層提供統一而方便的操作接口，從而讓用戶空間程序可以不用修改就能適應多種屏幕——無論這些屏幕是哪家廠商、什麼型號，都由framebuffer內部來兼容。

在Android系統中，framebuffer提供的設備文件節點是/dev/graphics/fb*。因為理論上支持多個屏幕顯示，所以fb按數字序號進行排列，即fb0、fb1等等。其中第一個fb0是主顯示屏幕，必須存在。如下是某設備的fb設備截圖：

圖 11?2 fb節點

根據前面章節學習過的知識，Android中各子系統通常不會直接基於Linux驅動來實現，而是由HAL層間接引用底層架構，在顯示系統中也同樣如此——它借助於HAL層來操作幀緩沖區，而完成這一中介任務的就是Gralloc，下面我們分幾個方面來介紹。

<1>  Gralloc的加載

Gralloc對應的模塊是由FramebufferNativeWindow(OpenGLES的本地窗口之一，後面小節有詳細介紹)在構造時加載的，即：

hw_get_module(HWC_HARDWARE_MODULE_ID, &mModule);

這個hw_get_module函數我們在前面已經見過很多次了，它是上層加載HAL庫的入口，這裡傳入的模塊ID名為：

#define GRALLOC_HARDWARE_MODULE_ID  "gralloc"

按照hw_get_module的作法，它會在如下路徑中查找與ID值匹配的庫：

#define HAL_LIBRARY_PATH1 "/system/lib/hw"

#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

lib庫名有如下幾種形式：

   gralloc.[ro.hardware].so

   gralloc.[ro.product.board].so

   gralloc.[ro.board.platform].so

   gralloc.[ro.arch].so

或者當上述的系統屬性組成的文件名都不存在時，就使用默認的：

   gralloc.default.so

最後這個庫是Android原生態的實現，位置在hardware/libhardware/modules/gralloc/中，它由gralloc.cpp、framebuffer.cpp和mapper.cpp三個主要源文件編譯生成。