Android 图形系统分析-surfaceFlinger流程

第一章AndroidGDI之基本原理及其总体框架AndroidGDI基本框架在Android中所涉及的概念和代码最多，最繁杂的就是GDI相关的代码了。但是本质从抽象上来讲，这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。GDI主要管理图形图像的输出,从整体方向上来看,GDI可以被认为是一个物理屏幕使用的管理器。因为在实际的产品中，我们需要在物理屏幕上输出不同的窗口，而每个窗口认为自己独占屏幕的使用，对所有窗口输出，应用程序不会关心物理屏幕是否被别的窗口占用，而只是关心自己在本窗口的输出，至于输出是否能在屏幕上看见，则需要GDI来管理。从最上层到最底层的数据流的分析可以看到实际上GDI在上层为GUI提供一个抽象的概念,就好像操作系统中的文件系统所提供文件，目录等抽象概念一样，GDI输出抽象成了文本,画笔,位图操作等设备无关的操作,让应用程序员只需要面对逻辑的设备上下文进行输出操作,而不要涉及到具体输出设备,以及输出边界的管理。GDI负责将文本、线条、位图等概念对象映射到具体的物理设备，所以GDI的在大体方向上可以分为以下几大要素：画布字体文本输出绘画对象位图输出Android的GDI系统Android的GDI系统所涉及到概念太多，加之使用了OpenGL使得Android的层次和代码很繁杂。但是我们对于Android的GDI系统需要了解的方面不是他的静态的代码关系，而是动态的对象关系，在逻辑运行的架构上理解GDI。我们首先还是需要从代码结构开始我们的理解。Frameworks/Libs/SurfaceflingerFrameworks/base/core/jni/android_view_Surface.cppFrameworks/base/core/java/android/view/surface.javaFrameworks/base/Graphics：绘图接口Frameworks/Libs/UiExternal/Skia其中External/Skia是一个C++的2D图形引擎库，Android的2D绘制系统都是建立在该基础之上.Skia完成了：文本输出，位图，点，线，图像解码等功能。在这里给出AndroidGDI的基本框架示意图。对于上面的GDI架构图我们只是一个大概的了解，我们有太多的问题需要解决，有太多的疑问需要得到答案，我就一直在想，为什么设计者有提出如此众多的概念，这个概念的背景是什么？他要管理什么，他要抽象什么？从前面知道，Android的整个设计理念就是无边界化，他是如何穿透Linux进程这个鸿沟来达到无边界的？Surface，Canvas，Layer，LayerBase,NativeBuffer，SurfaceFlinger，SurfaceFlingerClient这些到底是一个什么东西？如何管理，传递的是什么？创建的是什么？这些都是抽象的概念，绘画的终极的缓冲区到底是如何管理的？缓冲区到底在哪里？我们还是看看做终极的，最本质的设计概念，在从这些概念出发，来探讨这些概念的形成过程，是否有必要去生成写概念。SurfaceFlinger本质上干什么的？SurfaceFlinger的确就是这个意义：应用程序通过SurfaceFlinger将自己的“Surface”投掷到屏幕缓冲区。至于如何投掷的，我们将会在后面详细描述。第二章AndroidGDI之显示缓冲管理AndroidGDI之屏幕设备管理-动态链接库万丈高楼从地起，从最根源的硬件帧缓冲区开始。我们知道显示FrameBuffer在系统中就是一段内存,GDI的工作就是把需要输出的内容放入到该段内存的某个位置。我们从基本的点（像素点）和基本的缓冲区操作开始。1基本知识1.1点的格式对于不同的LCD来讲，FrameBuffer的二进制格式不一样，并且可以分为两部分：1)点的格式：通常将Depth,即表示多少位表示一个点。1位表示一个点2位表示一个点16位表示一个点32位表示一个点（Alpha通道）2)点内格式：RGB分量分布表示。例如对于我们常见的16位表示一个点1.2格式之间的转换所以屏幕输出实际上是一个值映射的关系。我们可以有如下的点格式转换，源格式可能来自单色位图和彩色位图，对于具体的目标机来讲，我们的目标格式可能就是一种，例如16位（5/6/5）格式。其实就只存在一种格式的转换，即从目标格式都是16位格式。但是，在设计GDI时，基本要求有一个可移植性好，所以我们还是必须考虑对于不同点格式LCD之间的转换操作。所以在GDI的驱动程序中涉及到区域操作(Blit)：我们在显示缓冲区上做的最多的操作就是区块搬运。由此，很多的应用处理器使用了硬件图形加速器来完成区域搬运:blit.从我们的主要操作的对象来看,可以分为两个方向:内存区域到屏幕区域屏幕区域到屏幕区域屏幕区域到内存区域内存区域到内存区域在这里我们需要特别提出的是，由于在Linux不同进程之间的内存不能自由的访问，使得我们的每个Android应用对于内存区域和屏幕缓冲区的使用变得很复杂。在Android的设计中，在屏幕缓冲区和显示内存缓冲区的管理分类很多的层次，最上层的对象是可以在进程间自由传递，但是对于缓冲区内容则使用共享内存的机制。基于以上的基础知识，我们可以知道：（1）代码中Config及其Format的意义所在了。也就理解了兼容性的意义：采用同硬件相同的点的描述对象（2）所有屏幕上图形的移动都是显示缓冲区搬运的结果。1.3图形加速器应用处理器都可能带有图形加速器，对于不同的应用处理器对其图形加速器可能有不同的处理方式，对于2D加速来讲，都可归结为blit。多为数据的搬运，放大缩小，旋转等。2Android的缓冲区抽象定义不同的硬件有不同的硬件图形加速设备和缓冲内存实现方法。AndroidGralloc动态库抽象的任务就是消除不同的设备之间的差别，在上层看来都是同样的方法和对象。在Moudle层隐藏缓冲区操作细节。Android使用了动态链接库gralloc.xxx.so，来完成底层细节的封装。2.1本地定义@hardware\libhandware\modules\gralloc每个动态链接库都是用相同名称的调用接口：硬件图形加速器的抽象：BlitEngine，CopyBit的加速操作。硬件FrameBuffer内存管理共享缓存管理从数据关系上我们来考察动态链接库的抽象行为：在层次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变量）从展露在外部的数据结构，我们在@Gralloc.cpp看到到了这样的布局：staticstructhw_module_methods_tgralloc_module_methods={open:gralloc_device_open};structprivate_module_tHAL_MODULE_INFO_SYM={base:{common:{tag:HARDWARE_MODULE_TAG,…id:GRALLOC_HARDWARE_MODULE_ID,name:GraphicsMemoryAllocatorModule,author:TheAndroidOpenSourceProject,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下面是外部接口和内部对象的结构关系，该类型的结构充分利CStruct的数据排列特性：基本结构体放置在最前面，本地私有放置在后面，满足了抽象的需要。typedefconstnative_handle*buffer_handle_t;private_module_tHAL_MODULE_INFO_SYM向往暴露的动态链接库接口，通过该接口，我们直接可以使用该对象。几个接口函数的解释：(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等的加速实现。而如何具体实现这些功能，则跟硬件平台的配备有关系，所以我们看到了对于与不同的硬件架构，有不同的配置关系。AndroirdGDI之共享缓冲区机制1Native_handle_t对private_handle_t的包裹private_handle_t是gralloc.so使用的本地缓冲区私有的数据结构，而Native_handle_t是上层抽象的可以在进程间传递的数据结构。在客户端是如何还原所传递的数据结构呢？首先看看native_handle_t对private_handle_t的抽象包装。numFds=sNumFds=1;numInts=sNumInts=8;这个是Parcel中描述句柄的抽象模式。实际上是指的Native_handle所指向句柄对象的具体内容：numFds=1表示有一个文件句柄：fd/numInts=8表示后面跟了8个INT型的数据：magic,flags,size,offset,base,lockState,writeOwner,pid;由于在上层系统不要关心buffer_handle_t中data的具体内容。在进程间传递buffer_handle_t(native_handle_t)句柄是其实是将这个句柄内容传递到Client端。在客户端通过Binder读取[e-mail]新生成一个native_handle。native_handle*Parcel::readNativeHandle()const{…native_handle*h=native_handle_create(numFds,numInts);for(inti=0;err==NO_ERROR&&ih-data[i]=dup(readFileDescriptor());if(h-data[i]0)err=BAD_VALUE;}