前面在介绍Android系统的开机画面时提到，Android设备的显示屏被抽象为一个帧缓冲区，而Android系统中的SurfaceFlinger服务就是通过向这个帧缓冲区写入内容来绘制应用程序的用户界面的。Android系统在硬件抽象层中提供了一个Gralloc模块，封装了对帧缓冲区的所有访问操作。本文将详细分析Gralloc模块的实现，为后续分析SurfaceFlinger服务的实现打下基础。
《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！
在前面Android系统的开机画面显示过程分析一文中提到，Linux内核在启动的过程中会创建一个类别和名称分别为“graphics”和“fb0”的设备，用来描述系统中的第一个帧缓冲区，即第一个显示屏，其中，数字0表示从设备号。注意，系统中至少要存在一个显示屏，因此，名称为“fb0”的设备是肯定会存在的，否则的话，就是出错了。Android系统和Linux内核本身的设计都是支持多个显示屏的，不过，在Android目前的实现中，只支持一个显示屏。
在前面Android系统的开机画面显示过程分析一文中还提到，init进程在启动的过程中，会启动另外一个进程ueventd来管理系统的设备文件。当ueventd进程启动起来之后，会通过netlink接口来Linux内核通信，以便可以获得内核中的硬件设备变化通知。而当ueventd进程发现内核中创建了一个类型和名称分别为“graphics”和“fb0”的设备的时候，就会这个设备创建一个/dev/graphics/fb0设备文件。这样，用户空间的应用程序就可以通过设备文件/dev/graphics/fb0来访问内核中的帧缓冲区，即在设备的显示屏中绘制指定的画面。注意，用户空间的应用程序一般是通过内存映射的方式来访问设备文件/dev/graphics/fb0的。
Android系统定义了硬件抽象层模块的编写规范，具体可以参考Android硬件抽象层（HAL）概要介绍和学习计划一文。本文假设读者已经熟悉Android系统的硬件抽象层编写规范，因此，我们将按照帧缓冲区的使用情景以及硬件抽象层编写规范来介绍Gralloc模块的实现。
用户空间的应用程序在使用帧缓冲区之间，首先要加载Gralloc模块，并且获得一个gralloc设备和一个fb设备。有了gralloc设备之后，用户空间中的应用程序就可以申请分配一块图形缓冲区，并且将这块图形缓冲区映射到应用程序的地址空间来，以便可以向里面写入要绘制的画面的内容。最后，用户空间中的应用程序就通过fb设备来将前面已经准备好了的图形缓冲区渲染到帧缓冲区中去，即将图形缓冲区的内容绘制到显示屏中去。相应地，当用户空间中的应用程序不再需要使用一块图形缓冲区的时候，就可以通过gralloc设备来释放它，并且将它从地址空间中解除映射。接下来，我们就按照上述使用情景来分析Gralloc模块的实现。
1. Gralloc模块的加载过程。
每一个HAL模块都有一个ID值，以这些ID值为参数来调用硬件抽象层提供的函数hw_get_module就可以将指定的模块加载到内存来，并且获得一个hw_module_t接口来打开相应的设备。
Gralloc模块的ID值定义在hardware/libhardware/include/hardware/gralloc.h文件中，如下所示：
#define GRALLOC_HARDWARE_MODULE_ID "gralloc"/** Base path of the hal modules */#define HAL_LIBRARY_PATH1 "/system/lib/hw"#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"/** * There are a set of variant filename for modules. The form of the filename * is "<MODULE_ID>.variant.so" so for the led module the Dream variants * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be: * * led.trout.so * led.msm7k.so * led.ARMV6.so * led.default.so */static const char *variant_keys[] = { "ro.hardware", /* This goes first so that it can pick up a different file on the emulator. */ "ro.product.board", "ro.board.platform", "ro.arch"};static const int HAL_VARIANT_KEYS_COUNT = (sizeof(variant_keys)/sizeof(variant_keys[0]));......int hw_get_module(const char *id, const struct hw_module_t **module){ int status; int i; const struct hw_module_t *hmi = NULL; char prop[PATH_MAX]; char path[PATH_MAX]; /* * Here we rely on the fact that calling dlopen multiple times on * the same .so will simply increment a refcount (and not load * a new copy of the library). * We also assume that dlopen() is thread-safe. */ /* Loop through the configuration variants looking for a module */ for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) { if (i < HAL_VARIANT_KEYS_COUNT) { if (property_get(variant_keys[i], prop, NULL) == 0) { continue; } snprintf(path, sizeof(path), "%s/%s.%s.so", HAL_LIBRARY_PATH1, id, prop); if (access(path, R_OK) == 0) break; snprintf(path, sizeof(path), "%s/%s.%s.so", HAL_LIBRARY_PATH2, id, prop); if (access(path, R_OK) == 0) break; } else { snprintf(path, sizeof(path), "%s/%s.default.so", HAL_LIBRARY_PATH1, id); if (access(path, R_OK) == 0) break; } } status = -ENOENT; if (i < HAL_VARIANT_KEYS_COUNT+1) { /* load the module, if this fails, we're doomed, and we should not try * to load a different variant. */ status = load(id, path, module); } return status;}gralloc.<ro.hardware>.so
gralloc.<ro.product.board>.so
gralloc.<ro.board.platform>.so
gralloc.<ro.arch>.so
只要其中的一个文件存在， 函数hw_get_module就会停止查找过程，并且调用另外一个函数load来将这个文件加载到内存中来。另一方面，如果在/system/lib/hw和/vendor/lib/hw中均不存这些文件，那么函数hw_get_module就会在目录/system/lib/hw中查找是否存在一个名称为gralloc.default.so的文件。如果存在的话，那么也会调用函数load将它加载到内存中来。
函数load也是实现在文件hardware/libhardware/hardware.c文件中，如下所示：
static int load(const char *id, const char *path, const struct hw_module_t **pHmi){ int status; void *handle; struct hw_module_t *hmi; /* * load the symbols resolving undefined symbols before * dlopen returns. Since RTLD_GLOBAL is not or'd in with * RTLD_NOW the external symbols will not be global */ handle = dlopen(path, RTLD_NOW); if (handle == NULL) { char const *err_str = dlerror(); LOGE("load: module=%s\n%s", path, err_str?err_str:"unknown"); status = -EINVAL; goto done; } /* Get the address of the struct hal_module_info. */ const char *sym = HAL_MODULE_INFO_SYM_AS_STR; hmi = (struct hw_module_t *)dlsym(handle, sym); if (hmi == NULL) { LOGE("load: couldn't find symbol %s", sym); status = -EINVAL; goto done; } /* Check that the id matches */ if (strcmp(id, hmi->id) != 0) { LOGE("load: id=%s != hmi->id=%s", id, hmi->id); status = -EINVAL; goto done; } hmi->dso = handle; /* success */ status = 0; done: if (status != 0) { hmi = NULL; if (handle != NULL) { dlclose(handle); handle = NULL; } } else { LOGV("loaded HAL id=%s path=%s hmi=%p handle=%p", id, path, *pHmi, handle); } *pHmi = hmi; return status;}在Linux系统中，后缀名为"so"的文件为动态链接库文件，可能通过函数dlopen来加载到内存中。硬件抽象层模块编写规范规定每一个硬件抽象层模块都必须导出一个符号名称为HAL_MODULE_INFO_SYM_AS_STR的符号，而且这个符号必须是用来描述一个类型为hw_module_t的结构体的。
HAL_MODULE_INFO_SYM_AS_STR是一个宏，定义在文件hardware/libhardware/include/hardware/hardware.h文件中，如下所示：
#define HAL_MODULE_INFO_SYM_AS_STR "HMI"模块Gralloc实现在目录hardware/libhardware/modules/gralloc中，它导出的符号HMI定义在文件hardware/libhardware/modules/gralloc/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, version_major: 1, version_minor: 0, 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, lock: PTHREAD_MUTEX_INITIALIZER, currentBuffer: 0,};#define HAL_MODULE_INFO_SYM HMI
结构体private_module_t的第一个成员变量base指向一个gralloc_module_t结构体，而gralloc_module_t结构体的第一个成员变量common又指向了一个hw_module_t结构体，这意味着，指向一个private_module_t结构体的指针同时可以用作一个gralloc_module_t或者hw_module_t结构体提针来使用。事实上，这是使用C语言来实现的一种继承关系，等价于结构体private_module_t继承结构体gralloc_module_t，而结构体gralloc_module_t继承hw_module_t结构体。这样，我们就可以把在Gralloc模块中定义的符号HAL_MODULE_INFO_SYM看作是一个hw_module_t结构体。
hw_module_t结构体有一个重要的成员变量methods，它的类型为hw_module_methods_t，它用来描述一个HAL模块的操作方法列表。结构体hw_module_methods_t只定义有一个操作方法open，用来打开一个指定的设备。在Gralloc模块中，用来打开指定设备的函数被指定为gralloc_device_open，通过这个函数就可以打开Gralloc模块中的gralloc或者fb设备，后面我们再详细分析。
结构体gralloc_module_t定义在文件hardware/libhardware/include/hardware/gralloc.h中，它主要是定义了四个用来操作图形缓冲区的成员函数，如下所示：
typedef struct gralloc_module_t {
...... int (*registerBuffer)(struct gralloc_module_t const* module, buffer_handle_t handle); int (*unregisterBuffer)(struct gralloc_module_t const* module, buffer_handle_t handle); int (*lock)(struct gralloc_module_t const* module, buffer_handle_t handle, int usage, int l, int t, int w, int h, void** vaddr); int (*unlock)(struct gralloc_module_t const* module, buffer_handle_t handle); ......}成员函数lock和unlock分别用来锁定和解锁一个指定的图形缓冲区，这个指定的图形缓冲区同样是使用一个buffer_handle_t句柄来描述。在访问一块图形缓冲区的时候，例如，向一块图形缓冲写入内容的时候，需要将该图形缓冲区锁定，用来避免访问冲突。在锁定一块图形缓冲区的时候，可以指定要锁定的图形绘冲区的位置以及大小，这是通过参数l、t、w和h来指定的，其中，参数l和t指定的是要访问的图形缓冲区的左上角位置，而参数w和h指定的是要访问的图形缓冲区的宽度和长度。锁定之后，就可以获得由参数参数l、t、w和h所圈定的一块缓冲区的起始地址，保存在输出参数vaddr中。另一方面，在访问完成一块图形缓冲区之后，需要解除这块图形缓冲区的锁定。
在Gralloc模块中，符号HAL_MODULE_INFO_SYM指向的gralloc结构体的成员函数registerBuffer、unregisterBuffer、lock和unlock分别被指定为函数gralloc_register_buffer、gralloc_unregister_buffer、gralloc_lock和gralloc_unlock，后面我们再详细分析它们的实现。
结构体private_module_t定义在文件hardware/libhardware/modules/gralloc/gralloc_priv.h中，它主要是用来描述帧缓冲区的属性，如下所示：
struct private_module_t {
gralloc_module_t base; private_handle_t* framebuffer; uint32_t flags; uint32_t numBuffers; uint32_t bufferMask; pthread_mutex_t lock; buffer_handle_t currentBuffer; int pmem_master; void* pmem_master_base; struct fb_var_screeninfo info; struct fb_fix_screeninfo finfo; float xdpi; float ydpi; float fps;};成员变量flags用来标志系统帧缓冲区是否支持双缓冲。如果支持的话，那么它的PAGE_FLIP位就等于1，否则的话，就等于0。
成员变量numBuffers表示系统帧缓
最低0.47元/天 解锁文章
865
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
