在Android中所涉及的概念和代码最多，最繁杂的就是GDI相关的代码了。但是本质从抽象上来讲，这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。

    GDI主要管理图形图像的输出,从整体方向上来看,GDI可以被认为是一个物理屏幕使用的管理器。因为在实际的产品中，我们需要在物理屏幕上输出不同的窗口，而每个窗口认为自己独占屏幕的使用，对所有窗口输出，应用程序不会关心物理屏幕是否被别的窗口占用，而只是关心自己在本窗口的输出，至于输出是否能在屏幕上看见，则需要GDI来管理。

从最上层到最底层的数据流的分析可以看到实际上GDI在上层为GUI提供一个抽象的概念,就好像操作系统中的文件系统所提供文件，目录等抽象概念一样，GDI输出抽象成了文本,画笔,位图操作等设备无关的操作,让应用程序员只需要面对逻辑的设备上下文进行输出操作,而不要涉及到具体输出设备,以及输出边界的管理。GDI负责将文本、线条、位图等概念对象映射到具体的物理设备，所以GDI的在大体方向上可以分为以下几大要素：

     Android的GDI系统所涉及到概念太多，加之使用了OpenGL使得Android的层次和代码很繁杂。但是我们对于Android的GDI系统需要了解的方面不是他的静态的代码关系，而是动态的对象关系，在逻辑运行的架构上理解GDI。我们首先还是需要从代码结构开始我们的理解。

其中External/Skia是一个C++的2D图形引擎库，Android的2D绘制系统都是建立在该基础之上.Skia完成了：文本输出，位图，点，线，图像解码等功能。

我在这里给出AndroidGDI的基本框架示意图。

    对于上面的GDI架构图我们只是一个大概的了解，我们有太多的问题需要解决，有太多的疑问需要得到答案，我就一直在想，为什么设计者有提出如此众多的概念，这个概念的背景是什么？他要管理什么，他要抽象什么？从前面知道，Android的整个设计理念就是无边界化，他是如何穿透Linux进程这个鸿沟来达到无边界的？Surface，Canvas， Layer，LayerBase,NativeBuffer，SurfaceFlinger，SurfaceFlingerClient这些到底是一个什么东西？如何管理，传递的是什么？创建的是什么？这些都是抽象的概念，绘画的终极的缓冲区到底是如何管理的？缓冲区到底在哪里？

     我们还是看看做终极的，最本质的设计概念，在从这些概念出发，来探讨这些概念的形成过程，是否有必要去生成写概念。SurfaceFlinger本质上干什么的？SurfaceFlinger的确就是这个意义：应用程序通过SurfaceFlinger将自己的“Surface”投掷到屏幕缓冲区。至于如何投掷的，我们将会在后面详细描述。

       万丈高楼从地起，从最根源的硬件帧缓冲区开始。我们知道显示FrameBuffer在系统中就是一段内存,GDI的工作就是把需要输出的内容放入到该段内存的某个位置。我们从基本的点（像素点）和基本的缓冲区操作开始。

32位表示一个点（Alpha通道）

例如对于我们常见的16位表示一个点

1.2．格式之间的转换

所以屏幕输出实际上是一个值映射的关系。我们可以有如下的点格式转换，

源格式可能来自单色位图和彩色位图，对于具体的目标机来讲，我们的目标格式可能就是一种，例如16位（5/6/5）格式。其实就只存在一种格式的转换，即从目标格式都是16位格式。

但是，在设计GDI时，基本要求有一个可移植性好，所以我们还是必须考虑对于不同点格式LCD之间的转换操作。所以在GDI的驱动程序中涉及到如下几类主要操作:

区域操作(Blit)：我们在显示缓冲区上做的最多的操作就是区块搬运。由此，很多的应用处理器使用了硬件图形加速器来完成区域搬运:blit.从我们的主要操作的对象来看,可以分为两个方向:

1)内存区域到屏幕区域

2)屏幕区域到屏幕区域

3)屏幕区域到内存区域

4)内存区域到内存区域

在这里我们需要特别提出的是，由于在Linux不同进程之间的内存不能自由的访问，使得我们的每个Android应用对于内存区域和屏幕缓冲区的使用变得很复杂。在Android的设计中，在屏幕缓冲区和显示内存缓冲区的管理分类很多的层次，最上层的对象是可以在进程间自由传递，但是对于缓冲区内容则使用共享内存的机制。

基于以上的基础知识，我们可以知道：

（1）代码中Config及其Format的意义所在了。也就理解了兼容性的意义：采用同硬件相同的点的描述对象

（2）所有屏幕上图形的移动都是显示缓冲区搬运的结果。

    应用处理器都可能带有图形加速器，对于不同的应用处理器对其图形加速器可能有不同的处理方式，对于2D加速来讲，都可归结为Blit。多为数据的搬运，放大缩小，旋转等。

    不同的硬件有不同的硬件图形加速设备和缓冲内存实现方法。Android Gralloc动态库抽象的任务就是消除不同的设备之间的差别，在上层看来都是同样的方法和对象。在Moudle层隐藏缓冲区操作细节。Android使用了动态链接库gralloc.xxx.so，来完成底层细节的封装。

每个动态链接库都是用相同名称的调用接口：

从展露在外部的数据结构，看到到了这样的布局：

我们建立了什么对象来支撑缓冲区的操作？

下面是外部接口和内部对象的结构关系，该类型的结构充分利用CStruct的数据排列特性：基本结构体放置在最前面，本地私有放置在后面，满足了抽象的需要。

看不清楚上面图，可以偏一下头横着看：

对于帧缓冲区实际地址并不需要向上层报告，所有的操作都是通过fb_post了完成。

fp_post的任务就是将一个Buffer的内容传递到硬件缓冲区。其实现方式有两种：

（方式1）无需拷贝动作，是把Framebuffer的后buffer切为前buffer，然后通过IOCTRL机制告诉FB驱动切换DMA源地地址。这个实现方式的前提是Linux内核必须分配至少两个缓冲区大小的物理内存和实现切换的ioctrol，这个实现快速切换。

（方式2）利用Copy的方式。不修改内核，则在适配层利用从拷贝的方式进行，但是这个是费时了。

    这个句柄是共享的基本依据，其基本原理在后面的章节有详细描述。

      总结一下，/system/lib/hw/gralloc.xxx.so是跟硬件体系相关的一个动态链接库，也可以叫做Android的硬件抽象层。他实现了Android的硬件抽象接口标准，提供显示内存的分配机制和CopyBit等的加速实现。而如何具体实现这些功能，则跟硬件平台的配备有关系，所以我们看到了对于与不同的硬件架构，有不同的配置关系。

这个是Parcel中描述句柄的抽象模式。实际上是指的Native_handle所指向句柄对象的具体内容：

    服务端（SurfaceFlinger）分配了一段内存作为Surface的作图缓冲，客户端怎样在这个作图缓冲区上工作呢？这个就是Mapper(GraphicBufferMapper)y要干的事情。两个进程间如何共享内存，如何获取到共享内存？Mapper就是干这个得。需要利用到两个信息：共享缓冲区设备句柄，分配时的偏移量。Mapper利用这样的原理：

    客户端只有lock,unlock,实质上就是mmap和ummap的操作。对于同样一个共享缓冲区，偏移量才是总要的，起始地址不重要。实际上他们操作了同一物理地址的内存块。我们在上面讨论了native_handle_t对private_handle_t 的包裹过程，从中知道服务端给客户端传递了什么东西。

        进程1在共享内存设备上预分配了8M的内存。以后所有的分配都是在这个8M的空间进行。对以该文件设备来讲，8M物理内存提交后，就实实在在的占用了8M内存。每个每个进程都可以同个该内存设备共享该8M的内存，他们使用的工具就会mmap。由于在mmap都是用0开始获取映射地址，所以所有的客户端进程都是有了同一个物理其实地址，所以此时偏移量和size就可以标识一段内存。而这个偏移量和size是个数值，从服务进程传递到客户端直接就可以使用。

   Android在该节使用了共享内存的方式来管理与显示相关的缓冲区，他设计成了两层，上层是缓冲区管理的代理机构GraphicBuffer,及其相关的native_buffer_t,下层是具体的缓冲区的分配管理及其缓冲区本身。上层的对象是可以在经常间通过Binder传递的，而在进程间并不是传递缓冲区本身，而是使用mmap来获取指向共同物理内存的映射地址。

2） 维持Layer的Zorder序列，并对Layer最终输出做出裁剪计算。

4） 接收Client要求，修改Layer属性（输出大小，Alpha等设定）

但是作为投递者的实际意义，我们首先需要知道的是如何投递，投掷物，投递路线，投递目的地。

mClientsMap：管理客户端与服务端的连接。

OpenGL ES：图形计算，图像合成等图形库。

gralloc.xxx.so这是个跟平台相关的图形缓冲区管理器。

   以Surface的Z-order序列排列的LayerBase数组，该数组是层显示遮挡的依据。在每个层计算自己的可见区域时，从Z-order 顶层开始计算，是考虑到遮挡区域的裁减，自己之前层的可见区域就是自己的不可见区域。而绘制Layer时，则从Z-order底层开始绘制，这个考虑到透明层的叠加。

2）之后所有的SurfaceFlinger进程中使用EGL的所有的操作目的地都是。

这样，在OpenGL绘制图形时，主Surface被记录在进程的上下文中，所以看不到显示的主Surfce相关参数的传递。下面是Layer-Draw，Hardware.flip的动作示意图：

在生成裁剪区域的时候，根据Z_order依次，每个Layer在计算自己在屏幕的可显示区域时，需要经历如下步骤：

  1）以自己的W,H给出自己初始的可见区域

  2）减去自己上面窗口所覆盖的区域

在绘制时，Layer将根据自己的可将区域做相应的区域数据Copy。

根据每个Layer的可见区域与需要刷新区域的交集区域从Z-Order序列从底部开始绘制到主Surface上。

现在SurfaceFlinger干的事情利用下面的示意图表示出来：

SurfaceSession的建立过程大部分是在C++ Native空间中完成的，表现在SurfaceSession的初始化函数：init()本地函数上。从下面的初始化函数可以看到：

     对于本节，我们不去研究Skia图形引擎本身，我们需要了解的我们的所做的图形到底放置到了那个地方，并且这个Canvas如何与Surface连接在一起的。

（1） 建立与SkCanvas连接的位图设备，而该位图使用上面取得的图形缓冲区地址做自己的位图内存。

（2） 设置SkCanvas的作图目标设备为该位图。

不是使用OpenGL绘制时，

导读：对于Android开发者来说，成系列的技术文章对他们的技术成长帮助最大。如下是我们向您强烈推荐的主题为Android开发的第一个系列文章。

《Android核心分析》整理如下：

在阅读SDK文档和研究Activity这个概念时，我感觉到了在Android中若隐若现的Android自由无边界这个设计意图。Android的应用只是一个虚的概念，并没有实际的入口，这个不像Window平台上的应用程序的概念，Android更多的是提供组件（Components）的概念。为什么要虚化应用的概念？我想这个虚化就是自由无边界设计意图的直接体现。突出请求和服务，突出组件个体，弱化边界，系统的各个组件可以自由的无边界的交流，服务请求者直接发出请求，不论这个对象在何处和属于谁的，组件是自由独立的个体，一个应用程序可以直接请求使用其他的应用的的组件，这个是Android应用框架设计的核心理念，其他的一切都是在为这个核心理念服务。

让程序员忽略应用的概念，甚至彻底的抛弃进程这样的概念，程序员看到的就是一个一个的组件，应用程序员利用这些组件来架构成一个所谓的应用，那么设计者首先要考虑的是什么呢？我想应该是一个抽象的应用模型，在这个模型下产生概念和接口。

Application）概念，MicroSoft的应用模型中用户交互则完全交给了Window，各种界面的呈现都是属于这个应用的是孤立的，应用程序之间的各个构成对象不能相互访问，最多提供一个进程间通讯机制，那个也是应用程序层面的。虽然Microsoft后来也提出了组件，分布式组件等概念，但是这些不是根植在Windows系统中，而Android则是彻底的组件化思想构建，一开始的应用程序概念就是Activity，Service,Broadcast

Activity是Android应用的核心概念，简而言之Activity为用户交互管理者，有一个可视界面呈现，而Service跟Activity的区别是他在后台运行，没有界面呈现。而Intent的意义是意图，他在Android的概念空间中，代表消息，这个消息代表了请求的意图。

Activity可以到处存在，提供服务，消除空间差别，Activity是一个独立的个体，更能表现面向对象的实质。这个个体需要接受另外的个体的消息，可以随时发起对另外一个个体的请求。个体是自由的，Android中你可以开始一个Activity，但是没有权利消灭一个Activity，这是个体权利的体现，个体的消灭是由系统决定的，这个就是Android中Activity蕴含的人文意义。

Android提供给开发程序员的概念空间中Application只是一个松散的表征概念，没有多少实质上的表征。在Android实际空间中看不到实际意义上的应用程序的概念,即使有一个叫Application的类，这个也就是个应用程序上下文状态，是一个极度弱化的概念。Application只是一个空间范畴的概念，Application就是Activity，Service之类的组件上下文描述。Application并不是Android的核心概念，而Activity才是Android的核心概念。

Provider）。我们可以使用下面的图来表示一下Android的概念空间。这些组件依附于应用程序中，应用程序并不会一开始就建立起来，而是在这些组件建立起来后，需要运行时，才开始建立应用程序对象。

为什么要从应用进程名称开始？作为内核研究，我们还是回到问题的最本质处：不管Activity，Service等组件如何设计和运行，它要提供服务，就必须要依附在Linux的进程上，建立消息循环，组件才能够真正的运作。Activity实例是如何Hosting在Linux进程上的？这个是我们首先想要弄明白的。

在SDK用已经描述的很清楚到了。

为什么要提出这么一个定义？android:process名称。

Service在应用程序的第一个组件需要运行时将会为应用程序建立一个进程，而这个进程的名字就是android:process=”string”所指定，缺省的是应用程序包的名字。该进程一旦建立，后面的该应用的组件都将运行在该进程中，他们绑定的根据就是这个Android：Process指定的名称，因为在他们都在同一个应用程序包里，也就具有了同样的进程名字，于是他们都托管在了同一进程中。组件将通过ClassLoader从Package中获取到应用程序的信息。

在分析中，我们可以看到真正对应应用进程的不是Application而是ActivityThread。我们从实际的应用堆栈可以看到：

每个应用程序都以ActivityThread.main()为入口进入到消息循环处理。对于一个进程来讲，我们需要这个闭合的处理框架。

AMS与应用进程的绑定分为两个部分，第一部分就是AM建立应用进程，第二部分就是应用进程Attach到AM，与AM建立通讯通道。

应用程序通过ActivityThread提供的框架，建立消息循环Looper和Handler。从前面的相关章节我们知道有Looper和Handler,整个系统就可以运作了。

为了更为系统的了解应用程序的建立时序及其涉及到数据操作，我给出了应用进程的建立过程示意图：

我们先来看看，Android应用开发人员接触的外特性空间中的Activity，对于AMS来讲，这个Activity就是客服端的Activity。应用程序员在建立Android应用时，构建Activity的子类就是Andoid外特性空间展现的接口。我们可以从下面的简单的例子描述看看Activity，到底如何建立的。

在Android的外特性空间(SDK)中，Android应用程序员根本不知道进程是什么时候起来的，系统消息是如何传递过来的。这个DemoActivity是如何实例化的呢？并且该Activity是托管在哪个进程的呢？本节的分析将给出答案。

在整个系统中，Activity实际上有两个实体。一个在应用进程中跟应用程序员打交道的Activity，一个是在AMS的中具有管理功能的History

通过该过程的研究我们会进一步的了解到AMS与应用进程的交互过程。

1）窗口切换：隐藏前一个Activity的窗口，

2）更新LRUList，（LRUList是淘汰应用程序的依据之一）

整个Resume的过程如下：

在Android中所涉及的概念和代码最多，最繁杂的就是GDI相关的代码了。但是本质从抽象上来讲，这么多的代码和框架就干了一件事情：对显示缓冲区的操作和管理。

GDI主要管理图形图像的输出,从整体方向上来看,GDI可以被认为是一个物理屏幕使用的管理器。因为在实际的产品中，我们需要在物理屏幕上输出不同的窗口，而每个窗口认为自己独占屏幕的使用，对所有窗口输出，应用程序不会关心物理屏幕是否被别的窗口占用，而只是关心自己在本窗口的输出，至于输出是否能在屏幕上看见，则需要GDI来管理。

从最上层到最底层的数据流的分析可以看到实际上GDI在上层为GUI提供一个抽象的概念,就好像操作系统中的文件系统所提供文件，目录等抽象概念一样，GDI输出抽象成了文本,画笔,位图操作等设备无关的操作,让应用程序员只需要面对逻辑的设备上下文进行输出操作,而不要涉及到具体输出设备,以及输出边界的管理。GDI负责将文本、线条、位图等概念对象映射到具体的物理设备，所以GDI的在大体方向上可以分为以下几大要素：

Android的GDI系统所涉及到概念太多，加之使用了OpenGL使得Android的层次和代码很繁杂。但是我们对于Android的GDI系统需要了解的方面不是他的静态的代码关系，而是动态的对象关系，在逻辑运行的架构上理解GDI。我们首先还是需要从代码结构开始我们的理解。

其中External/Skia是一个C++的2D图形引擎库，Android的2D绘制系统都是建立在该基础之上.Skia完成了：文本输出，位图，点，线，图像解码等功能。

我在这里给出Android GDI的基本框架示意图。

对于上面的GDI架构图我们只是一个大概的了解，我们有太多的问题需要解决，有太多的疑问需要得到答案，我就一直在想，为什么设计者有提出如此众多的概念，这个概念的背景是什么？他要管理什么，他要抽象什么？从前面知道，Android的整个设计理念就是无边界化，他是如何穿透Linux进程这个鸿沟来达到无边界的？Surface，Canvas， Layer，LayerBase, NativeBuffer，SurfaceFlinger，SurfaceFlingerClient这些到底是一个什么东西？如何管理，传递的是什么？创建的是什么？这些都是抽象的概念，绘画的终极的缓冲区到底是如何管理的？缓冲区到底在哪里？

我们还是看看做终极的，最本质的设计概念，在从这些概念出发，来探讨这些概念的形成过程，是否有必要去生成写概念。SurfaceFlinger本质上干什么的？SurfaceFlinger的确就是这个意义：应用程序通过SurfaceFlinger将自己的“Surface”投掷到屏幕缓冲区。至于如何投掷的，我们将会在后面详细描述。

万丈高楼从地起，从最根源的硬件帧缓冲区开始。我们知道显示FrameBuffer在系统中就是一段内存,GDI的工作就是把需要输出的内容放入到该段内存的某个位置。我们从基本的点（像素点）和基本的缓冲区操作开始。

对于不同的LCD来讲，FrameBuffer的二进制格式不一样，并且可以分为两部分：

1)点的格式：通常将Depth,即表示多少位表示一个点。

32位表示一个点（Alpha通道）

2) 点内格式：RGB分量分布表示。

例如对于我们常见的16位表示一个点

1.2．格式之间的转换

所以屏幕输出实际上是一个值映射的关系。我们可以有如下的点格式转换，

源格式可能来自单色位图和彩色位图，对于具体的目标机来讲，我们的目标格式可能就是一种，例如16位（5/6/5）格式。其实就只存在一种格式的转换，即从目标格式都是16位格式。

但是，在设计GDI时，基本要求有一个可移植性好，所以我们还是必须考虑对于不同点格式LCD之间的转换操作。所以在GDI的驱动程序中涉及到如下几类主要操作:

区域操作(Blit)：我们在显示缓冲区上做的最多的操作就是区块搬运。由此，很多的应用处理器使用了硬件图形加速器来完成区域搬运:blit.从我们的主要操作的对象来看,可以分为两个方向:

1)内存区域到屏幕区域

2)屏幕区域到屏幕区域

3)屏幕区域到内存区域

4)内存区域到内存区域

在这里我们需要特别提出的是，由于在Linux不同进程之间的内存不能自由的访问，使得我们的每个Android应用对于内存区域和屏幕缓冲区的使用变得很复杂。在Android的设计中，在屏幕缓冲区和显示内存缓冲区的管理分类很多的层次，最上层的对象是可以在进程间自由传递，但是对于缓冲区内容则使用共享内存的机制。

基于以上的基础知识，我们可以知道：

（1）代码中Config及其Format的意义所在了。也就理解了兼容性的意义：采用同硬件相同的点的描述对象

（2）所有屏幕上图形的移动都是显示缓冲区搬运的结果。

应用处理器都可能带有图形加速器，对于不同的应用处理器对其图形加速器可能有不同的处理方式，对于2D加速来讲，都可归结为Blit。多为数据的搬运，放大缩小，旋转等。

不同的硬件有不同的硬件图形加速设备和缓冲内存实现方法。Android Gralloc动态库抽象的任务就是消除不同的设备之间的差别，在上层看来都是同样的方法和对象。在Moudle层隐藏缓冲区操作细节。Android使用了动态链接库gralloc.xxx.so，来完成底层细节的封装。

每个动态链接库都是用相同名称的调用接口：

从展露在外部的数据结构，我们在@Gralloc.cpp看到到了这样的布局：

我们建立了什么对象来支撑缓冲区的操作？

下面是外部接口和内部对象的结构关系，该类型的结构充分利用C Struct的数据排列特性：基本结构体放置在最前面，本地私有放置在后面，满足了抽象的需要。

看不清楚上面图，可以偏一下头横着看：

对于帧缓冲区实际地址并不需要向上层报告，所有的操作都是通过fb_post了完成。

fp_post的任务就是将一个Buffer的内容传递到硬件缓冲区。其实现方式有两种：

（方式1）无需拷贝动作，是把Framebuffer的后buffer切为前buffer，然后通过IOCTRL机制告诉FB驱动切换DMA源地地址。这个实现方式的前提是Linux内核必须分配至少两个缓冲区大小的物理内存和实现切换的ioctrol，这个实现快速切换。

（方式2）利用Copy的方式。不修改内核，则在适配层利用从拷贝的方式进行，但是这个是费时了。

1）打开屏幕设备 "/dev/fb0",，并映射硬件显示缓冲区。

2）提供分配共享显示缓存的接口

3）提供BiltEngine接口（完成硬件加速器的包装）

这个句柄是共享的基本依据，其基本原理在后面的章节有详细描述。

总结一下，/system/lib/hw/gralloc.xxx.so是跟硬件体系相关的一个动态链接库，也可以叫做Android的硬件抽象层。他实现了Android的硬件抽象接口标准，提供显示内存的分配机制和CopyBit等的加速实现。而如何具体实现这些功能，则跟硬件平台的配备有关系，所以我们看到了对于与不同的硬件架构，有不同的配置关系。

这个是Parcel中描述句柄的抽象模式。实际上是指的Native_handle所指向句柄对象的具体内容：

这里需要提到的是为在构造客户端的native_handle时，对于对方传递过来的文件句柄的处理。由于不是在同一个进程中，所以需要dup(…)一下为客户端使用。这样就将Native_handle句柄中的，客户端感兴趣的从服务端复制过来。这样就将Private_native_t的数据：magic,flags,size,offset,base,lockState,writeOwner,pid;复制到了客户端。

客户端利用这个新的Native_buffer被Mapper传回到gralloc.xxx.so中，获取到native_handle关联的共享缓冲区映射地址，从而获取到了该缓冲区的控制权，达到了客服端和Server间的内存共享。从SurfaceFlinger来看就是作图区域的共享。

服务端（SurfaceFlinger）分配了一段内存作为Surface的作图缓冲，客户端怎样在这个作图缓冲区上工作呢？这个就是Mapper(GraphicBufferMapper)y要干的事情。两个进程间如何共享内存，如何获取到共享内存？Mapper就是干这个得。需要利用到两个信息：共享缓冲区设备句柄，分配时的偏移量。Mapper利用这样的原理：

客户端只有lock,unlock,实质上就是mmap和ummap的操作。对于同样一个共享缓冲区，偏移量才是总要的，起始地址不重要。实际上他们操作了同一物理地址的内存块。我们在上面讨论了native_handle_t对private_handle_t 的包裹过程，从中知道服务端给客户端传递了什么东西。

进程1在共享内存设备上预分配了8M的内存。以后所有的分配都是在这个8M的空间进行。对以该文件设备来讲，8M物理内存提交后，就实实在在的占用了8M内存。每个每个进程都可以同个该内存设备共享该8M的内存，他们使用的工具就会mmap。由于在mmap都是用0开始获取映射地址，所以所有的客户端进程都是有了同一个物理其实地址，所以此时偏移量和size就可以标识一段内存。而这个偏移量和size是个数值，从服务进程传递到客户端直接就可以使用。

Android在该节使用了共享内存的方式来管理与显示相关的缓冲区，他设计成了两层，上层是缓冲区管理的代理机构GraphicBuffer,及其相关的native_buffer_t,下层是具体的缓冲区的分配管理及其缓冲区本身。上层的对象是可以在经常间通过Binder传递的，而在进程间并不是传递缓冲区本身，而是使用mmap来获取指向共同物理内存的映射地址。

2） 维持Layer的Zorder序列，并对Layer最终输出做出裁剪计算。

4） 接收Client要求，修改Layer属性（输出大小，Alpha等设定）

但是作为投递者的实际意义，我们首先需要知道的是如何投递，投掷物，投递路线，投递目的地。

mClientsMap：管理客户端与服务端的连接。

OpenGL ES：图形计算，图像合成等图形库。

gralloc.xxx.so这是个跟平台相关的图形缓冲区管理器。

以Surface的Z-order序列排列的LayerBase数组，该数组是层显示遮挡的依据。在每个层计算自己的可见区域时，从Z-order 顶层开始计算，是考虑到遮挡区域的裁减，自己之前层的可见区域就是自己的不可见区域。而绘制Layer时，则从Z-order底层开始绘制，这个考虑到透明层的叠加。

这样，在OpenGL绘制图形时，主Surface被记录在进程的上下文中，所以看不到显示的主Surfce相关参数的传递。下面是Layer-Draw，Hardware.flip的动作示意图：

在生成裁剪区域的时候，根据Z_order依次，每个Layer在计算自己在屏幕的可显示区域时，需要经历如下步骤：

1）以自己的W,H给出自己初始的可见区域

2）减去自己上面窗口所覆盖的区域

在绘制时，Layer将根据自己的可将区域做相应的区域数据Copy。

根据每个Layer的可见区域与需要刷新区域的交集区域从Z-Order序列从底部开始绘制到主Surface上。

现在SurfaceFlinger干的事情利用下面的示意图表示出来：

SurfaceSession的建立过程大部分是在C++ Native空间中完成的，表现在SurfaceSession的初始化函数：init()本地函数上。从下面的初始化函数可以看到：

对于本节，我们不去研究Skia图形引擎本身，我们需要了解的我们的所做的图形到底放置到了那个地方，并且这个Canvas如何与Surface连接在一起的。

（1） 建立与SkCanvas连接的位图设备，而该位图使用上面取得的图形缓冲区地址做自己的位图内存。

（2） 设置SkCanvas的作图目标设备为该位图。

不是使用OpenGL绘制时，Android在View属性发生变化，新建View时，或者Z-order发生变化时，需要对系统屏幕上的View重新绘制，此时我们的View会执行OnDraw(canvas），这个根源在哪里呢？