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三個主要源檔案編譯產生。