出处：http://blog.csdn.net/myarrow/article/details/7180561

1. 简介      

        网上已经有很多兄弟对Android的显示系统做了深入解剖，很是佩服。可最近小弟在研究Android4.0时发现出入比较大，也许是Android4.0的修改比较多吧！因为小弟没有看Android4.0以前的代码。

       面对这么复杂一个Android显示系统，如何入手呢? 根据以前的经验，不管它有多么复杂，其功能不就是以下三步曲吗？

　　1）显示系统的创建及初始化

       2）画图

       3）销毁

       哪我的分析就从显示系统的创建及初始化开始吧！由于小弟对Java没有什么研究兴趣，所有重点就分析Native部分。当然Native的入口就在android_view_Surface.cpp中，此文件主要包含以下两部分给Java层调用：

       1）gSurfaceSessionMethods： 操作SurfaceSession的方法

       2）gSurfaceMethods：操作Surface的方法

2. android_view_Surface.cpp

 

2.1 SurfaceSession操作方法

 

 2.1.1 SurfaceSession_init

        其功能如下：

        1）创建SurfaceComposerClient对象

        2）调用SurfaceComposerClient::onFirstRef方法

        现在已经进入到SurfaceComposerClient的地盘，根据其名字含义，它应该是一个进行Surface合成的客户端，通过它发命令给SurfaceFlinger来进行需要的操作。其初始化流程如下图所示：

2.1.2 SurfaceComposerClient.cpp中的宝贝

        为了方便后面的理解，先看看SurfaceComposerClient中有些什么宝贝来完成这个任务。在其中定义了如下几个类：

2.1.2.1 ComposerService(获取SurfaceFlinger服务)

        一看到名字为Service，应该是用于从SurfaceFlinger中获取Service以建立连接关系<它是一个单实例，一个进程有且只有一个实例对象>，然后供后面进行相关的操作。其构造函数代码如下：      

 

      由此可见，ComposerService主要是获取SurfaceFlinger服务、获取在SurfaceFlinger::readyToRun中创建的共享内存块及其基地址。在Client中，谁要想与SurfaceFlinger通信，需要通过接口getComposerService来获取此BpSurfaceComposer。

     此ComposerService是在调用ComposerService::getInstance时进行有且只有一个的实例化，因为前面讲过，它是一个单实例。

 

2.1.2.2 Composer

      它也是一个单实例，管理并发送每个layer的ComposerState。其定义如下：

 

      把上面的comments看完就明白了，Composer管理每个SurfaceComposerClient中的每一个Surface的状态，并记录在ComposerState的layer_state_t中，然后调用者可以调用其closeGlobalTransaction方法把这些mStates发送给SurfaceFlinger处理（处理函数为：SurfaceFlinger::setTransactionState）。

      谁来调用它的方法设置层的属性及发送mStates呢? -----答案是由SurfaceComposerClient来调用。

  2.1.2.3  SurfaceComposerClient

       前面介绍的两个类一个用于获取SurfaceFlinger服务；一个 用于记录每个Layer的状态，且可按要求把这些CoposerState发送给SurfaceFlinger。这个类是不是来使用前面两个类提供的服务 呢? --答案是肯定的。其定义及详细注释如下：

 

    其功能列表如下：

     1）获取BpSurfaceComposerClient（即mClient），在onFirstRef中实现

     2）通过BpSurfaceComposerClient（即mClient）创建和销毁Surface

     3）通过Composer来记录Surface和显示屏状态变化，及在Composer中通过BpSurfaceComposer把状态变化发给SurfaceFlinger处理

     至此，SurfaceComposerClient功能已经分析清楚。可是从这三个类中，我们已经看到三个 Bp（BpSurfaceComposer，BpSurfaceComposerClient和BpSurface）及三个对应的接口。下面总结一下，每 个接口的功能，在客户端由谁使用，在服务器端谁来实现。

 2.1.2.4 Surface相关接口总结

     

 

 2.2 Surface操作

其相关接口如下：

2.2.1 Surface_init调用流程

     在SurfaceFlinger端创建BSurface,在客户端返回SurfaceControl,同时在SurfaceControl中拥有了BpSurface用于与BSurface交互。

 

2.2.1.1 调用流程分析

     BpSurfaceComposerClient->createSurface返回BpSurface。且通过参数返回ISurfaceComposerClient::surface_data_t，其定义如下：

     其中token在SurfaceComposerClient的函数参数中，对应于SurfaceID。即在客户端，它就是SurfaceID。

     token: 加入到Client::mLayers中的序号，在Client中单调递增,初始值为:1，一个Layer创建一个BSurface

     identity: LayerBaseClient中的mIdentity,在所有的Layer中单调递增,初始值为:1

2.2.1.2 创建真正的Surface

      在Layer::createSurface中创建真正的BSurface,在SurfaceFlinger::createSurface中调用layer->getSurface时创建的。此BSurface定义如下：

         在此BSurface中实现了ISurface的接口getSurfaceTexture，在此接口中返回 Layer::mSurfaceTexture(类型为:SurfaceTextureLayer,它才是真正操作内存的东东),此成员在 Layer::onFirstRef中创建，SurfaceTextureLayer是SurfaceTexture的派生类，代码如下：

2.2.1.3 不得不说的SurfaceControl

       本来Surface_init调用SurfaceComposerClient::createSurface创建一个Surface,可却返回了一个SurfaceControl,下面看看SurfaceCotrol到底做了些什么，以及如何做的？

        相关数据结构如下图所示：

 

 SurfaceControl定义如下：

 

       从其定义中可以看出，在getSurface中将有新花样，其它操作函数都是直接以mToken作为SurfaceID,直接调用 SurfaceComposerClient中对应方法。 经过这样一分析，SurfaceControl也没什么神秘的了。但它的getSurface 到有点神秘。

 

 2.2.2 getSurface流程

      getSurface在客户端返回Surface(派生于SurfaceTextureClient)，并在Surface的mSurfaceTexture域中保存了BpSurfaceTexture。

      前面Surface初始化之后，就可以getSurface了。getSurface流程如下图所示：

           有了Surface，且在Surface中又有了BpSurfaceTexture，下一步就操作GraphicBuffer了。

 

 3. 画图流程

对于画图流程，可以从ViewRootImpl（ViewRootImpl.java）的draw函数看起，在画图之间，它要调用java层的surface.lockCanvas，画完图之后调用surface.unlockCanvasAndPost来提交显示。

surface.lockCanvas->

lockCanvasNative(Java)->

(C++)Surface_lockCanvas<android_view_Surface.cpp>

surface.unlockCanvasAndPost(Java)->

(C++)Surface_unlockCanvasAndPost<android_view_Surface.cpp>

本章主要分析这两个函数到底做了些什么>

 3.1 Surface_lockCanvas

       Android图形系统中一个重要的概念是surface。View及其子类（如TextView, Button）要画在surface上。每个surface创建一个Canvas对象（但属性时常改变），用来管理view在surface上的绘图操 作，如画点画线。每个canvas对象对应一个bitmap，存储画在surface上的内容。

3.1.1 相关数据结构定义

 3.1.1.1 ANativeWindow_Buffer

3.1.1.2 SurfaceInfo

3.1.1.3 二者对应关系

 3.1.1.4 GraphicBuffer

     在分析下面的流程时， 不得不对GraphicBuffer进行深入了解，特别是其Flattenable interface，这是实现画图buffer的关键。其相关定义如下：

3.1.1.5 Flattenable interface

下面看看每个Flattenable interface是如何实现的：

3.1.1.5.1 getFlattenedSize

3.1.1.5.2 getFdCount

3.1.1.5.3 flatten

     把handle中的numFds拷贝到fds中，把handle中的numInts拷贝到buffer中。

 3.1.1.5.4 unflatten 

       把width,height,stride,format和usage保存到成员变量中，并创建一个native_handle，然后把numFds和 numInts拷贝到handle的data中。同时把此handle注册到mBufferMapper中，mBufferMapper的注册函数实现代码如下：

 

 3.1.1.5.4  GRALLOC_HARDWARE_MODULE_ID实例

      对于GRALLOC_HARDWARE_MODULE_ID，以hardware/msm7k/libgralloc/gralloc.cpp为例进行分 析。其registerBuffer实现函数：gralloc_register_buffer（hardware/msm7k/libgralloc /mapper.cpp)，其相关代码如下：

    从gralloc_map可以看出，这个registerBuffer主要做了一件事：

    1）根据handle中传过来的fd和size进行mmap映射（把kernel中的内存映射到用户空间），映射之后的地址再加上hnd->offset便获得hnd->base供后面使用。

      从这里可以初步看出，这个图形buffer数据并不是真正的从client传递到server，而是在lock是从server把fd传递给client，由客户端进行mmap，然后进行使用。关于这个是怎么实现的，后面将详细分析其实现过程。

    对于如何从native_handle转换为private_handle_t，且在private_handle_t中可以获取fd和offset? 看一下其数据结构和flatten的实现方式就可以得知：
native_handle：

     这个data[0]是关键，虽然分配了哪么多buffer,但实质上native_handle只占了3个int.其它的数据由包含它的数据结构来解析。

private_handle_t：

3.1.2 Surface_lockCanvas执行流程

查看高清大图

3.1.3 Surface_lockCanvas总结 

功能：Surface_lockCanvas获取显示buffer在本进程用户空间的地址，并据此创建一个SkBitmap给Java使用。
关键技术：BINDER_TYPE_FD类型的Binder、mmap、gralloc硬件抽象层

 

3.1.4 SurfaceTexture::dequeueBuffer如何创建GraphicBuffer

       相关代码如下：

     mGraphicBufferAlloc也是通过调用BpSurfaceComposer->createGraphicBufferAlloc而获取，它对应的服务器为SufaceFlinger中的GraphicBufferAlloc。

     mGraphicBufferAlloc实质为一个BpGraphicBufferAlloc,它真正创建GraphicBuffer的代码位于GraphicBufferAlloc::createGraphicBuffer中。代码关键调用流程如下：

     new GraphicBuffer(w, h, format, usage)->

       initSize(w, h, reqFormat, reqUsage)->

         GraphicBufferAllocator::get()->

            allocator.alloc(w, h, format, reqUsage, &handle, &stride)->

            返回handle,此handle为ANativeWindowBuffer成员，类型为native_handle。

              GraphicBufferAllocator::alloc->

                mAllocDev->alloc->

                 mAllocDev类型为alloc_device_t，它通过gralloc_open向

                 GRALLOC_HARDWARE_MODULE_ID获取，根据上面的实例msm7k，

                 它最终执行gralloc_device_open而获取gralloc_context_t.device.common，

                  alloc的实现函数为gralloc_alloc.

                   gralloc_alloc->

                    gralloc_alloc_buffer->

                     1）获取GPU内存(调用SimpleBestFitAllocator::allocate进行分配)

                     2）fd = open("/dev/null", O_RDONLY)获取fd

                     3）根据fd、size和flags创建private_handle_t，其相关代码如下：

 

3.2 Surface_unlockCanvasAndPost