### Android GDI之屏幕設備管理-動態鏈接庫 萬丈高樓從地起，從最根源的硬件幀緩沖區開始。我們知道顯示FrameBuffer在系統中就是一段內存,GDI的工作就是把需要輸出的內容放入到該段內存的某個位置。我們從基本的點（像素點）和基本的緩沖區操作開始。 ### 1 基本知識 ### 1.1點的格式 對于不同的LCD來講，FrameBuffer的二進制格式不一樣，并且可以分為兩部分： ####1)點的格式：通常將Depth,即表示多少位表示一個點。 1位表示一個點 2位表示一個點 16位表示一個點 32位表示一個點（Alpha通道） ####2) 點內格式：RGB分量分布表示。 例如對于我們常見的16位表示一個點 [ ](http://hi.csdn.net/attachment/201006/14/0_127649370468hY.gif) ### 1.2．格式之間的轉換 所以屏幕輸出實際上是一個值映射的關系。我們可以有如下的點格式轉換， [ ](http://hi.csdn.net/attachment/201006/14/0_1276493706k5xC.gif) 源格式可能來自單色位圖和彩色位圖，對于具體的目標機來講，我們的目標格式可能就是一種，例如16位（5/6/5）格式。其實就只存在一種格式的轉換，即從目標格式都是16位格式。 [ ](http://hi.csdn.net/attachment/201006/14/0_1276493707JNOB.gif) 但是，在設計GDI時，基本要求有一個可移植性好，所以我們還是必須考慮對于不同點格式LCD之間的轉換操作。所以在GDI的驅動程序中涉及到如下幾類主要操作: 區域操作(Blit)：我們在顯示緩沖區上做的最多的操作就是區塊搬運。由此，很多的應用處理器使用了硬件圖形加速器來完成區域搬運:blit.從我們的主要操作的對象來看,可以分為兩個方向: 1)內存區域到屏幕區域 2)屏幕區域到屏幕區域 3)屏幕區域到內存區域 4)內存區域到內存區域 在這里我們需要特別提出的是，由于在Linux不同進程之間的內存不能自由的訪問，使得我們的每個Android應用對于內存區域和屏幕緩沖區的使用變得很復雜。在Android的設計中，在屏幕緩沖區和顯示內存緩沖區的管理分類很多的層次，最上層的對象是可以在進程間自由傳遞，但是對于緩沖區內容則使用共享內存的機制。 基于以上的基礎知識，我們可以知道： （1）代碼中Config及其Format的意義所在了。也就理解了兼容性的意義：采用同硬件相同的點的描述對象 （2）所有屏幕上圖形的移動都是顯示緩沖區搬運的結果。 ### 1.2圖形加速器 應用處理器都可能帶有圖形加速器，對于不同的應用處理器對其圖形加速器可能有不同的處理方式，對于2D加速來講，都可歸結為Blit。多為數據的搬運，放大縮小，旋轉等。 ### 2 Android的緩沖區抽象定義 不同的硬件有不同的硬件圖形加速設備和緩沖內存實現方法。Android Gralloc動態庫抽象的任務就是消除不同的設備之間的差別，在上層看來都是同樣的方法和對象。在Moudle層隱藏緩沖區操作細節。Android使用了動態鏈接庫gralloc.xxx.so，來完成底層細節的封裝。 2.1 本地定義@hardware/libhandware/modules/gralloc 每個動態鏈接庫都是用相同名稱的調用接口： 1)硬件圖形加速器的抽象：BlitEngine，CopyBit的加速操作。 2)硬件FrameBuffer內存管理 3)共享緩存管理 從數據關系上我們來考察..動態鏈接庫的抽象行為：在層次：[Hardware.c@hardware/libhardware](#) 中對動態鏈接庫中的內容作了全新的包裝。/system/lib/hw/gralloc.xxx.so動態庫文件。從文件Gralloc.h(handware/libhardware/include/hardware)是抽象的結果：hw_get_module從gralloc.xxx.so提取了HAL_MODULE_INFO_SYM（SYM變量） [ ](http://hi.csdn.net/attachment/201006/14/0_1276493710BnSi.gif) 從展露在外部的數據結構，[我們在@Gralloc.cpp](#)看到到了這樣的布局： ~~~ static struct hw_module_methods_t gralloc_module_methods = { open: gralloc_device_open }; > struct private_module_t HAL_MODULE_INFO_SYM = { ??? base: { ??????? common: { ??????????? tag: HARDWARE_MODULE_TAG, ???????????? … ??????????? id: GRALLOC_HARDWARE_MODULE_ID, ??????????? name: "Graphics Memory Allocator Module", ??????????? author: "The Android Open Source Project", ??????????? methods: &gralloc_module_methods ??????? }, registerBuffer: gralloc_register_buffer, unregisterBuffer: gralloc_unregister_buffer, lock:? gralloc_lock, unlock:? gralloc_unlock, ??? }, ??? framebuffer: 0, ??? flags: 0, ??? numBuffers: 0, ??? bufferMask: 0, … }; ~~~ 我們建立了什么對象來支撐緩沖區的操作？ buffer_handle_t：外部接口。 methods.open，registerBuffer，unregisterBuffer，lock，unlock 下面是外部接口和內部對象的結構關系，該類型的結構充分利用C Struct的數據排列特性：基本結構體放置在最前面，本地私有放置在后面，滿足了抽象的需要。 typedef const native_handle* buffer_handle_t; private_module_t? HAL_MODULE_INFO_SYM 向往暴露的動態鏈接庫接口，通過該接口，我們直接可以使用該對象。 [ ](http://hi.csdn.net/attachment/201006/14/0_1276493716565n.gif) 看不清楚上面圖，可以偏一下頭橫著看： [ ](http://hi.csdn.net/attachment/201006/14/0_1276493727LN9N.gif) 幾個接口函數的解釋： (1)fb_post 對于幀緩沖區實際地址并不需要向上層報告，所有的操作都是通過fb_post了完成。 fp_post的任務就是將一個Buffer的內容傳遞到硬件緩沖區。其實現方式有兩種：  （方式1）無需拷貝動作，是把Framebuffer的后buffer切為前buffer，然后通過IOCTRL機制告訴FB驅動切換DMA源地地址。這個實現方式的前提是Linux內核必須分配至少兩個緩沖區大小的物理內存和實現切換的ioctrol，這個實現快速切換。 （方式2）利用Copy的方式。不修改內核，則在適配層利用從拷貝的方式進行，但是這個是費時了。 (2)gralloc的主要功能是要完成： ??? 1）打開屏幕設備 "/dev/fb0",，并映射硬件顯示緩沖區。 ??? 2）提供分配共享顯示緩存的接口 ??? 3）提供BiltEngine接口（完成硬件加速器的包裝） （3）gralloc_alloc輸出buffer_handle_t句柄。 這個句柄是共享的基本依據，其基本原理在后面的章節有詳細描述。 ### 3 總結 總結一下，/system/lib/hw/gralloc.xxx.so是跟硬件體系相關的一個動態鏈接庫，也可以叫做Android的硬件抽象層。他實現了Android的硬件抽象接口標準，提供顯示內存的分配機制和CopyBit等的加速實現。而如何具體實現這些功能，則跟硬件平臺的配備有關系，所以我們看到了對于與不同的硬件架構，有不同的配置關系。