（一） 概述   

    android的binder机制提供一种进程间通信的方法，使一个进程可以以类似远程过程调用的形式调用另一个进程所提供的功能。binder机制在Java环境和C/C++环境都有提供。

    android的代码中，与C/C++的binder包括一些类型和接口的定义和实现，相关的代码在下面这几个文件中：

   frameworks\base\include\media
   frameworks\base\media

   使用startUML的反向工程功能分析上面这些代码，并进行了一定的整理之后，得到下面这幅类图（点击可查看原尺寸图片）。

   android的媒体播放功能分成两部分，一部分是媒体播放应用，一部分是媒体播放服务（MediaServer，在系统启动时由init所启动，具可参 考init.rc文件）。这两部分分别跑在不同的进程中。媒体播放应用包括Java程序和部分C++代码，媒体播放服务是C++代码，并且需要调用外部模 块opencore来实现真正的媒体播放。媒体播放应用和媒体播放服务之间需要通过binder机制来进行相互调用，这些调用包括：

   （1）媒体播放应用向媒体播放服务发控制指令
   （2）媒体播放服务向媒体播放应用发事件通知（notify）

   媒体播放服务对外提供多个接口，在上面得图中包括其中的2个接口：IMediaService和IMediaPlayer，IMediaplayer用于 创建和管理播放实例，而IMediaplayer接口则是播放接口，用于实现指定媒体文件的播放以及播放过程的控制。

   上面的图中还有媒体播放应用向媒体播放服务提供的1个接口：IMediaPlayerClient，用于接收notify。

   这些接口因为需要跨进程调用，因此需要用到binder机制。每个接口包括两部分实现，一部分是接口功能的真正实现（BnInterface），这部分运 行在接口提供进程中；另一部分是接口的proxy（BpInterface），这部分运行在调用接口的进程中。binder的作用就是让这两部分之间建立 联系。下图是整个播放器的一个概要说明。

     媒体播放器比较复杂一些，总共实现了3个接口，不过要了解binder的机制，只需要研究其中一个接口就足够了。在这里选择IMediaPlayerService接口来看一下。

     IMediaPlayerService接口包括六个功能函数：create(url)、create(fd)、decode(url)、 decode(fd）、createMediaRecord()、createMetadataRetriever()。在这里不介绍这些函数是做什么 的，我们只关注如何通过binder还提供这些函数接口。

（二） 接口定义

（1） 定义接口类

     首先定义IMediaPlayerService类，这是一个接口类（C++的术语应该叫纯虚类）。该接口类定义在文件frameworks\base\include\media\IMediaPlayerService.h。代码如下：

    重点关注在这些函数前面的一个宏定义： DECLARE_META_INTERFACE(MediaPlayerService)。这个宏定义必须要有，其中封装了实现binder所需要的一些 类成员变量和成员函数通过这些成员函数可以为一个binder实现创建proxy。这个宏定义在问价frameworks\base\include \utils\IInterface.h里，在后面还会讲到。这个宏定义的参数必须是接口类的名称去除字母I后剩下的部分。

    另外说明一下，可以看到接口类中所定义的函数的返回值都是sp<xxxx>的形式，看起来有点怪异。sp是android中定义的一个模板 类，用于实现智能指针功能。sp<IMediaPlayer>就是IMediaPlayer的智能指针，可以简单地把它看成是标准C++中的 指针定义即 IMediaPlayer* 即可。

（2） 定义和实现binder类

    binder类包括两个，一个是接口实现类，一个接口代理类。接口代理类继承自BpInterface，接口实现类继承自BnInterface。这两个基类都是模板类，封装了binder的进程间通信机制，这样使用者无需关注底层通信实现细节。

    对于IMediaPlayerService接口，其binder接口实现类为BnMediaPlayerService，接口代理类为 BpMediaPlayerService。需注意这两个类的名称有严格要求，必须以Bn和Bp开头，并且后面的部分必须是前面所定义的接口类的名称去除 字母'I’。比如前面所定义的接口类为IMediaPlayerService，去除字母I后是MediaPlayerService，所以两个 binder类的名称分别是BnMediaPlayerService和BpMediaPlayerService。为什么有这样的要求？原因就在前面提 到的宏定义DECLARE_META_INTERFACE()和另一个宏定义IMPLEMENT_META_INTERFACE()里面。有兴趣的话可以 去看一下，这两个宏定义都在文件frameworks\base\include\utils\IInterface.h里。

    BpMediaPlayerService是一个最终实现类。定义并且实现在在文件frameworks\base\media\libmidia \IMediaPlayerService.cpp中。在看BpMediaPlayerService的代码之前，先看一下在 IMediaPlayerService.cpp文件的开始部分的一个枚举定义：

    这些6个枚举定义对应于IMediaPlayerService接口所提供的6个功能函数，可以称为这些功能函数的功能代码，用于在进程之间进行RPC是 标识需要调用哪个函数。如果不想定义这些枚举值，在后面需要用到这些值的地方直接写上1，2，3，4，5，6也是可以的，不过……一个合适的程序员会这么 干吗？

    下面看一下BpMediaPlayerService的代码。

（3） BpMediaPlayerService代码分析

    首先可以看到，这个类继承自模板类BpInterface，指定类型为接口类IMediaPlayerService。BpInterface模板类定义 在文件IInterface.h。看一下BpInterface的定义就可以发现，BpMediaPlayerService这样定义了以后，事实上间接 继承了IMediaPlayerService，从而可以提供IMediaPlayerService接口所定义的接口函数。 BpMediaPlayerService需要实现这些接口函数。在一个简单的构造函数之后，就是这些接口函数的实现。可以看到，所有的接口函数的实现方 法都是一致的，都是通过binder所提供的机制将参数仍给binder的实现类，并获取返回值。这也就是这个类之所以成为代理类的原因。下面具体看一下 一个接口函数。这里选的是函数create(url）。

Surface的创建过程

我们先看看Android如何创建一个Surface，下面的序列图展示了整个创建过程。

                                                              图一   Surface的创建过程

创建Surface的过程基本上分为两步：

1. 建立SurfaceSession

第一步通常只执行一次，目的是创建一个SurfaceComposerClient的实例，JAVA层通过JNI调用本地代码，本地代码创建一个 SurfaceComposerClient的实例，SurfaceComposerClient通过ISurfaceComposer接口调用 SurfaceFlinger的createConnection，SurfaceFlinger返回一个ISurfaceFlingerClient接 口给SurfaceComposerClient，在createConnection的过程中，SurfaceFlinger创建了用于管理缓冲区切换 的SharedClient，关于SharedClient我们下面再介绍，最后，本地层把SurfaceComposerClient的实例返回给 JAVA层，完成SurfaceSession的建立。

2. 利用SurfaceSession创建Surface

JAVA层通过JNI调用本地代码Surface_Init()，本地代码首先取得第一步创建的SurfaceComposerClient实例， 通过SurfaceComposerClient，调用ISurfaceFlingerClient接口的createSurface方法，进入 SurfaceFlinger，SurfaceFlinger根据参数，创建不同类型的Layer，然后调用Layer的setBuffers()方法， 为该Layer创建了两个缓冲区，然后返回该Layer的ISurface接口，SurfaceComposerClient使用这个ISurface接 口创建一个SurfaceControl实例，并把这个SurfaceControl返回给JAVA层。

由此得到以下结果：

• JAVA层的Surface实际上对应于本地层的SurfaceControl对象，以后本地代码可以使用JAVA传入的SurfaceControl对象，通过SurfaceControl的getSurface方法，获得本地Surface对象；
• Android为每个Surface分配了两个图形缓冲区，以便实现Page-Flip的动作；
• 建立SurfaceSession时，SurfaceFlinger创建了用于管理两个图形缓冲区切换的SharedClient对 象，SurfaceComposerClient可以通过ISurfaceFlingerClient接口的getControlBlock()方法获得 这个SharedClient对象，查看SurfaceComposerClient的成员函数_init:

获得Surface对应的显示缓冲区

虽然在SurfaceFlinger在创建Layer时已经为每个Layer申请了两个缓冲区，但是此时在JAVA层并看不到这两个缓冲 区，JAVA层要想在Surface上进行画图操作，必须要先把其中的一个缓冲区绑定到Canvas中，然后所有对该Canvas的画图操作最后都会画到 该缓冲区内。下图展现了绑定缓冲区的过程：

                                                                            图二  绑定缓冲区的过程

    开始在Surface画图前，Surface.java会先调用lockCanvas()来得到要进行画图操作的Canvas，lockCanvas会进 一步调用本地层的Surface_lockCanvas，本地代码利用JAVA层传入的SurfaceControl对象，通过getSurface() 取得本地层的Surface对象，接着调用该Surface对象的lock()方法，lock()返回了改Surface的信息，其中包括了可用缓冲区的 首地址vaddr，该vaddr在Android的2D图形库Skia中，创建了一个bitmap，然后通过Skia库中Canvas的 API：Canvas.setBitmapDevice(bitmap)，把该bitmap绑定到Canvas中，最后把这个Canvas返回给JAVA 层，这样JAVA层就可以在该Canvas上进行画图操作，而这些画图操作最终都会画在以vaddr为首地址的缓冲区中。

    再看看在Surface的lock()方法中做了什么：

• dequeueBuffer(&backBuffer)获取backBuffer
  • SharedBufferClient->dequeue()获得当前空闲缓冲区的编号
  • 通过缓冲区编号获得真正的GraphicBuffer:backBuffer
  • 如果还没有对Layer中的buffer进行映射（Mapper），getBufferLocked通过ISurface接口重新重新映射
• 获取frontBuffer
• 根据两个Buffer的更新区域，把frontBuffer的内容拷贝到backBuffer中，这样保证了两个Buffer中显示内容的同步
• backBuffer->lock() 获得backBuffer缓冲区的首地址vaddr
• 通过info参数返回vaddr

释放Surface对应的显示缓冲区

画图完成后，要想把Surface的内容显示到屏幕上，需要把Canvas中绑定的缓冲区释放，并且把该缓冲区从变成可投递（因为默认只有两个 buffer，所以实际上就是变成了frontBuffer），SurfaceFlinger的工作线程会在适当的刷新时刻，把系统中所有的 frontBuffer混合在一起，然后通过OpenGL刷新到屏幕上。下图展现了解除绑定缓冲区的过程：

                                                                 图三  解除绑定缓冲区的过程

• JAVA层调用unlockCanvasAndPost
• 进入本地代码：Surface_unlockCanvasAndPost
• 本地代码利用JAVA层传入的SurfaceControl对象，通过getSurface()取得本地层的Surface对象
• 绑定一个空的bitmap到Canvas中
• 调用Surface的unlockAndPost方法
  • 调用GraphicBuffer的unlock()，解锁缓冲区
  • 在queueBuffer()调用了SharedBufferClient的queue()，把该缓冲区更新为可投递状态

SharedClient 和 SharedBufferStack

从前面的讨论可以看到，Canvas绑定缓冲区时，要通过SharedBufferClient的dequeue方法取得空闲的缓冲区，而解除绑定 并提交缓冲区投递时，最后也要调用SharedBufferClient的queue方法通知SurfaceFlinger的工作线程。实际上，在 SurfaceFlinger里，每个Layer也会关联一个SharedBufferServer，SurfaceFlinger的工作线程通过 SharedBufferServer管理着Layer的缓冲区，在SurfaceComposerClient建立连接的阶 段，SurfaceFlinger就已经为该连接创建了一个SharedClient 对象，SharedClient 对象中包含了一个SharedBufferStack数组，数组的大小是31，每当创建一个Surface，就会占用数组中的一个 SharedBufferStack，然后SurfaceComposerClient端的Surface会创建一个 SharedBufferClient和该SharedBufferStack关联，而SurfaceFlinger端的Layer也会创建 SharedBufferServer和SharedBufferStack关联，实际上每对 SharedBufferClient/SharedBufferServer是控制着同一个SharedBufferStack对象，通过 SharedBufferStack，保证了负责对Surface的画图操作的应用端和负责刷新屏幕的服务端（SurfaceFlinger）可以使用不 同的缓冲区，并且让他们之间知道对方何时锁定/释放缓冲区。

SharedClient和SharedBufferStack的代码和头文件分别位于：

/frameworks/base/libs/surfaceflinger_client/SharedBufferStack.cpp

/frameworks/base/include/private/surfaceflinger/SharedBufferStack.h

                                                                       图四    客户端和服务端缓冲区管理

     继续研究SharedClient、SharedBufferStack、SharedBufferClient、SharedBufferServer的诞生过程。

    1. SharedClient

•     在createConnection阶段，SurfaceFlinger创建Client对象：

• 再进入Client的构造函数中，它分配了4K大小的共享内存，并在这块内存上构建了SharedClient对象：

• 回到createConnection中，通过Client的getControlBlockMemory()方法获得共享内存块的 IMemoryHeap接口，接着创建ISurfaceFlingerClient的子类BClient，BClient的成员变量mCblk保存了 IMemoryHeap接口指针；
• 把BClient返回给SurfaceComposerClient，SurfaceComposerClient通过 ISurfaceFlingerClient接口的getControlBlock()方法获得IMemoryHeap接口指针，同时保存在 SurfaceComposerClient的成员变量mControlMemory中；
• 继续通过IMemoryHeap接口的getBase ()方法获取共享内存的首地址，转换为SharedClient指针后保存在SurfaceComposerClient的成员变量mControl中；
• 至此，SurfaceComposerClient的成员变量mControl和SurfaceFlinger::Client.ctrlblk指向了同一个内存块，该内存块上就是SharedClient对象。 

    2. SharedBufferStack、SharedBufferServer、SharedBufferClient

    SharedClient对象中有一个SharedBufferStack数组：

    SharedBufferStack surfaces[ NUM_LAYERS_MAX ];

    NUM_LAYERS_MAX 被定义为31，这样保证了SharedClient对象的大小正好满足4KB的要求。创建一个新的Surface时，进入SurfaceFlinger的 createSurface函数后，先取在createConnection阶段创建的Client对象，通过Client在 0--NUM_LAYERS_MAX 之间取得一个尚未被使用的编号，这个编号实际上就是SharedBufferStack数组的索引：

 然后以Client对象和索引值以及其他参数，创建不同类型的Layer对象，一普通的Layer对象为例：

在createNormalSurfaceLocked中创建Layer对象：

构造Layer时会先构造的父类LayerBaseClient，LayerBaseClient中创建了SharedBufferServer对 象，SharedBufferStack 数组的索引值和SharedClient被传入SharedBufferServer对象中。

    自此，Layer通过lcblk成员变量(SharedBufferServer)和SharedClient共享内存区建立了关联，并且每个Layer对应于SharedBufferStack 数组中的一项。

    回到SurfaceFlinger的客户端Surface.cpp中，Surface的构造函数如下：

SharedBufferClient构造参数mClient->mControl就是共享内存块中的SharedClient对象，mToken就是SharedBufferStack 数组索引值。

到这里我们终于知道，Surface中的mSharedBufferClient成 员和Layer中的lcblk成员(SharedBufferServer)，通过SharedClient中的同一个 SharedBufferStack，共同管理着Surface（Layer）中的两个缓冲区。

一、           surfaceflinger server如何启动：

1、 【System_init.cpp】

extern "C" status_t system_init()

{

       ……..

    char propBuf[PROPERTY_VALUE_MAX];

    property_get("system_init.startsurfaceflinger", propBuf, "1");

    if (strcmp(propBuf, "1") == 0) {

        // Start the SurfaceFlinger

        SurfaceFlinger::instantiate();         //实例化

}    

……..

}

2、 【SurfaceFlinger.cpp】

void SurfaceFlinger::instantiate() {

    defaultServiceManager()->addService(

            String16("SurfaceFlinger"), new SurfaceFlinger());     //添加SurfaceFlinger服务

}

3、【Threads.cpp】

int Thread::_threadLoop(void* user)

{

       ……..

       self->mStatus = self->readyToRun();

       ……..

       result = self->threadLoop();

       ……..

4、【SurfaceFlinger.cpp】

status_t SurfaceFlinger::readyToRun()

{

       ……..

}

5、【SurfaceFlinger.cpp】

bool SurfaceFlinger::threadLoop()

{

       ……..

}

二、上层如何与底层SurfaceFlinger建立联系

1、为应用程序创建一个 Client (用于管理和通信)

注：

   经过Binder，最终调用SurfaceFlinger的createConnection实现，这里不作详细介绍，有兴趣请看参考：

【SurfaceFlinger.cpp】

sp<ISurfaceFlingerClient> SurfaceFlinger::createConnection()

{

    Mutex::Autolock _l(mStateLock);

    uint32_t token = mTokens.acquire();

    sp<Client> client = new Client(token, this);

    if (client->ctrlblk == 0) {

        mTokens.release(token);

        return 0;

    }

    status_t err = mClientsMap.add(token, client);

    if (err < 0) {

        mTokens.release(token);

        return 0;

    }

    sp<BClient> bclient =

        new BClient(this, token, client->getControlBlockMemory());

    return bclient;

}

2、为这个 Client 分配 Surface（用于存放数据）

sp<ISurface> SurfaceFlinger::createSurface(ClientID clientId, int pid,

        const String8& name, ISurfaceFlingerClient::surface_data_t* params,

        DisplayID d, uint32_t w, uint32_t h, PixelFormat format,

        uint32_t flags)

{

    sp<LayerBaseClient> layer;

    sp<LayerBaseClient::Surface> surfaceHandle;

    if (int32_t(w|h) < 0) {

        LOGE("createSurface() failed, w or h is negative (w=%d, h=%d)",

                int(w), int(h));

        return surfaceHandle;

    }

    Mutex::Autolock _l(mStateLock);

    sp<Client> client = mClientsMap.valueFor(clientId);

    if (UNLIKELY(client == 0)) {

        LOGE("createSurface() failed, client not found (id=%d)", clientId);

        return surfaceHandle;

    }

    //LOGD("createSurface for pid %d (%d x %d)", pid, w, h);

    int32_t id = client->generateId(pid);

    if (uint32_t(id) >= NUM_LAYERS_MAX) {                      //最大支持32个layer

        LOGE("createSurface() failed, generateId = %d", id);

        return surfaceHandle;

    }

    switch (flags & eFXSurfaceMask) {

        case eFXSurfaceNormal:

            if (UNLIKELY(flags & ePushBuffers)) {

                layer = createPushBuffersSurfaceLocked(client, d, id,

                        w, h, flags);

            } else {

                layer = createNormalSurfaceLocked(client, d, id,

                        w, h, flags, format);

            }

            break;

        case eFXSurfaceBlur:

            layer = createBlurSurfaceLocked(client, d, id, w, h, flags);

            break;

        case eFXSurfaceDim:

            layer = createDimSurfaceLocked(client, d, id, w, h, flags);

            break;

    }

    if (layer != 0) {

        layer->setName(name);

        setTransactionFlags(eTransactionNeeded);

        surfaceHandle = layer->getSurface();                        //获取Isurface结构

        if (surfaceHandle != 0) {                                         //保存好layer信息

            params->token = surfaceHandle->getToken();

            params->identity = surfaceHandle->getIdentity();

            params->width = w;

            params->height = h;

            params->format = format;

        }

    }

    return surfaceHandle;

}

sp<LayerBaseClient> SurfaceFlinger::createNormalSurfaceLocked(

        const sp<Client>& client, DisplayID display,

        int32_t id, uint32_t w, uint32_t h, uint32_t flags,

        PixelFormat& format)

{

    // initialize the surfaces

    switch (format) { // TODO: take h/w into account

    case PIXEL_FORMAT_TRANSPARENT:

    case PIXEL_FORMAT_TRANSLUCENT:

        format = PIXEL_FORMAT_RGBA_8888;

        break;

    case PIXEL_FORMAT_OPAQUE:

        format = PIXEL_FORMAT_RGB_565;

        break;

    }

    sp<Layer> layer = new Layer(this, display, client, id);

    status_t err = layer->setBuffers(w, h, format, flags);

    if (LIKELY(err == NO_ERROR)) {

        layer->initStates(w, h, flags);

        addLayer_l(layer);

    } else {

        LOGE("createNormalSurfaceLocked() failed (%s)", strerror(-err));

        layer.clear();

    }

    return layer;

}

Android GDI之SurfaceFlinger

SurfaceFinger按英文翻译过来就是Surface投递者。SufaceFlinger的构成并不是太复杂，复杂的是他的客户端建构。SufaceFlinger主要功能是：

1） 将Layers （Surfaces） 内容的刷新到屏幕上

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

3） 响应Client要求，创建Layer与客户端的Surface建立连接

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

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

1  SurfaceFlinger的基本组成框架

SurfaceFlinger管理对象为：

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

ISurface，IsurfaceComposer：AIDL调用接口实例

mLayerMap：服务端的Surface的管理对象。

mCurrentState.layersSortedByZ ：以Surface的Z-order序列排列的Layer数组。

graphicPlane 缓冲区输出管理

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

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

pmem Device：提供共享内存，在这里只是在gralloc.xxx.so可见，在上层被gralloc.xxx.so抽象了。

2 SurfaceFinger Client和服务端对象关系图

Client端与SurfaceFlinger连接图：

Client对象：一般的在客户端都是通过SurfaceComposerClient来跟SurfaceFlinger打交道。

3 主要对象说明

3.1 DisplayHardware &FrameBuffer

    首先SurfaceFlinger需要操作到屏幕，需要建立一个屏幕硬件缓冲区管理框架。Android在设计支持时，考虑多个屏幕的情况，引入了 graphicPlane的概念。在SurfaceFlinger上有一个graphicPlane数组，每一个graphicPlane对象都对应一个 DisplayHardware.在当前的Android（2.1）版本的设计中，系统支持一个graphicPlane，所以也就支持一个 DisplayHardware。

SurfaceFlinger，Hardware硬件缓冲区的数据结构关系图。

3.2 Layer

method:setBuffer  在SurfaceFlinger端建立显示缓冲区。这里的缓冲区是指的HW性质的，PMEM设备文件映射的内存。

1) layer的绘制

void Layer::onDraw(const Region& clip) const

{

    int index = mFrontBufferIndex;

    GLuint textureName = mTextures[index].name;

…

  drawWithOpenGL(clip, mTextures[index]);

}

3.2 mCurrentState.layersSortedByZ

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

4 SurfaceFlinger的运行框架

    我们从前面的章节<Android Service>的基本原理可以知道，SurfaceFlinger的运行框架存在于：threadLoop,他是SurfaceFlinger的主循环体。SurfaceFlinger在进入主体循环之前会首先运行：SurfaceFlinger::readyToRun()。

4.1 SurfaceFlinger::readyToRun()

（1）建立GraphicPanle

（2）建立FrameBufferHardware(确定输出目标)

      初始化：OpenGL ES

           建立兼容的mainSurface.利用eglCreateWindowSurface。

           建立OpenGL ES进程上下文。

   建立主Surface（OpenGL ES）。 DisplayHardware的Init()@DisplayHardware.cpp函数对OpenGL做了初始化，并创建立主Surface。为什 么叫主Surface，因为所有的Layer在绘制时，都需要先绘制在这个主Surface上，最后系统才将主Surface的内容”投掷”到真正的屏幕 上。

（3） 主Surface的绑定

1）在DisplayHandware初始完毕后，hw.makeCurrent()将主Surface，OpenGL ES进程上下文绑定到SurfaceFlinger的上下文中，

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

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

4.2 ThreadLoop

(1)handleTransaction(…):主要计算每个Layer有无属性修改，如果有修改着内用需要重画。

(2)handlePageFlip()

    computeVisibleRegions：根据Z-Order序列计算每个Layer的可见区域和被覆盖区域。裁剪输出范围计算-

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

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

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

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

（3）handleRepaint()

composeSurfaces（需要刷新区域）：

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

（4）postFramebuffer()

（DisplayHardware）hw.flip(mInvalidRegion);

eglSwapBuffers(display,mSurface) :将mSruface投递到屏幕。

5 总结

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

本文档对Android RIL部分的内容进行了介绍，其重点放在了Android RIL的原生代码部分。包括四个主题：

1.Android RIL框架介绍

2.Android RIL与 WindowsMobile RIL

3.Android RIL porting

4.Android RIL的java框架

在本文档中将Android代码中的重要模块列出进行分析，并给出了相关的程序执行流程介绍，以加深对模块间交互方式的理解。

对于java代码部分，这里仅进行简单的介绍。如果需要深入了解，可以查看相关参考资料。

本文档中还对Android RIL的Porting部分内容进行了描述和分析。

针对对unix操作系统环境并不熟悉的读者，本文档中所涉及到的相关知识包括：

  Unix file system

  Unix socket

  Unix thread

  Unix 下I/O多路转接

以上信息可以在任意一份描述Unix系统调用的文档中找到。

fd                       unix文件描述符

pipe                      unix管道

cond                      一般是condition variable的缩写

tty                       通常使用tty来简称各种类型的终端设备

unsolicited response         被动请求命令来自baseband

event loop                 android的消息队列机制，由unix的系统调用select()实现

init.rc                     init守护进程启动后被执行的启动脚本。

HAL                     硬件抽象层（Hardware Abstraction Layer，HAL）

Android RIL提供了无线硬件设备与电话服务之间的抽象层。

下图展示了RIL在Android体系中的位置。

android的ril位于应用程序框架与内核之间，分成了两个部分，一个部分是rild,它负责socket与应用程序框架进行通信。另外一个部分是Vendor RIL，这个部分负责向下是通过两种方式与radio进行通信，它们是直接与radio通信的AT指令通道和用于传输包数据的通道，数据通道用于手机的上网功能。

对于RIL的java框架部分，也被分成了两个部分，一个是RIL模块，这个模块主要用于与下层的rild进行通信，另外一个是Phone模块，这个模块直接暴露电话功能接口给应用开发用户，供他们调用以进行电话功能的实现。

Android的RIL模块位于Android/hardware/ril文件夹，有三个子模块：rild , libril , reference-ril

●include文件夹：

包含RIL头文件,最主要的是ril.h

●rild文件夹:

RIL守护进程，开机时被init守护进程调用启动，里面仅有main函数作为入口点，负责完成RIL初始化工作。

在rild.c文件中，将完成ril的加载过程，它会执行如下操作：

  动态加载Vendor RIL的.so文件

  执行RIL_startEventLoop()开启消息队列以进行事件监听

  通过执行Vendor RIL的rilInit()方法来进行Vendor RIL与libril的关系建立。

在rild文件夹中还包括一个radiooptions.c文件,它的作用是通过串口将一些radio相关的参数直接传给rild来对radio进行配置。

●libril文件夹：

在编译时libril被链入rild,它为rild提供了event处理功能，还提供了在rild与Vendor RIL之间传递请求和响应消息的能力。

Libril提供的主要功能分布在两个主要方法内，一个是RIL_startEventLoop()方法，另一个是RIL_register()方法

RIL_startEventLoop()方法所提供的功能就是启用eventLoop线程，开始执行RIL消息队列。

RIL_register()方法的主要功能是启动名为 rild 的监听端口，等待java 端通过socket进行连接。

●reference-ril文件夹：

Android自带的Vendor RIL的参考实现。被编译成.so文件，由于本部分是厂商定制的重点所在。所以被设计为松散耦合，且可灵活配置的。在rild中通过opendl()的方式加载。

librefrence.so负责直接与radio通信，这包括将来自libril的指令转换为AT指令，并且将AT指令写入radio中。

reference-ril会接收调用者传来的参数，参数内容为与radio的通信方式。如通过串口连接radio,那么参数为这种形式：-d /dev/ttySx

在Android RIL中，为了达到等待多路输入并且不出现阻塞的目的，使用了IO多路复用机制。

如果使用阻塞I/O进行网络的读取写入,这意味着假如需要同时从两个网络文件描述符中读内容，那么如果读取操作在等待网络数据到来，这将可能很长时间阻塞在一个描述符上，另一个网络文件描述符不管有没有数据到来都无法被读取。

    一种解决方案是：

如果使用非阻塞I/O进行网络的读取写入，在读取其中一个网络文件描述符如果阻塞将直接返回，再读取另外一个，这种方式的循环被称之为轮询。轮询方式确实能解决进行多路io操作时的阻塞问题，但是这种方法的不足之处是反复的执行读写调用将浪费cpu时钟。

I/O多路转接技术在这里提供了另一种比较好的解决方案：

它会先构造一张有关I/O描述符的列表，然后调用select函数，当IO描述符列表中的一个描述符准备好进行I/O时，该函数返回，并告知可以读或写哪个描述符。

Android RIL中消息队列的核心实现思想就是这种I/O多路转接技术。

消息队列机制的实现在ril_event.cpp中，其中被定义的ril_event结构是消息的主体。

每个ril_event结构，与一个fd句柄绑定(可以是文件，socket，管道等)，并且带一个func指针,这个func指针所指的函数是个回调函数，它指定了当所绑定的fd准备好进行读取时所要进行的操作。

消息队列的开始点为RIL_startEventLoop函数。RIL_startEventLoop在ril.cpp中实现，它的主要目的是通过pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL)建立一个dispatch线程，线程入口点在eventLoop. 而在eventLoop中，会调ril_event.cpp中的ril_event_loop()函数，建立起消息队列机制。

ril_event是一个带有链表行为的struct，它最主要的成员一个是fd,一个是func：

struct ril_event {

struct ril_event *next;

struct ril_event *prev;

int fd;

int index;

bool persist;

struct timeval timeout;

ril_event_cb func;

void *param;

};

初始化一个新ril_event的操作是通过ril_event_set（）来完成的，并通过ril_event_add（）加入到消息队列之中，add会把队列里所有ril_event的fd，放入一个fd集合readFds中。这样 ril_event_loop能通过一个多路复用I/O的机制(select)来等待这些fd。

在进入ril_event_loop（）之前，在eventLoop中已经创建和挂入了s_wakeupfd_event，它是通过pipe的机制实现的，这个管道fd的回调函数并没有实现什么功能，它的目的只是为了让select方法能返回一次，这样select()方法就能重新跟踪新加入事件队列的fd和timeout设置。

所以在添加新fd到eventLoop时,往往不是直接调用ril_event_add，实际通常用rilEventAddWakeup来添加，这个方法除了会间接调用ril_event_add外，还会调用triggerEvLoop()函数来向s_fdWakeupWrite中写入一个空字符，这样select()函数会返回并重新执行，新加入的文件描述符便得以被select()加载并跟踪。

如果在ril_event队列中任何一个fd已经准备好，则进入分析流程：

processTimeouts()，processReadReadies(&rfds, n)，firePending()

   其中firePending()方法执行这个event的func，也就是回调函数。

在Android RIL初始化完成后，将有几个event被挂入到eventLoop中：

1.      s_listen_event: 名为rild的socket,主要requeset & response通道

2.      s_debug_event: 名为rild-debug的socket,调试用requeset & response通道

3.      s_wakeupfd_event: 无名管道,用于队列主动唤醒

这其中最为重要的event就是s_listen_event，它作为request与response的通道实现。

在ril_event.cpp中还持有一个watch_table数组，一个timer_list链表和一个pending_list链表。

watch_table数组的目的很单纯，存放当前被eventLoop等待的ril_event（非timer event），供eventLoop唤醒时使用。

timer_list是存放timer event的链表，在eventLoop唤醒时要对这些timer event单独进行处理

pending_list：待处理(对其回调函数进行调用)的所有ril_event的链表。

●     Rild的初始化流程

初始化流程从rild.c中的main函数开始，它被init守护进行调用执行：

首先在main()函数内会首先通过dlopen()函数加载Vendor RIL（在自带的参考实现中为librefrence_ril.so）。接着调用RIL_startEventLoop（）函数来启动消息队列机制。

调用librefrence_ril.so的RIL_Init()函数来进行Vendor RIL的初始化。RIL_Init()函数执行后会返回一个RIL_RadioFunction结构体，这个结构体内最重要的成员就是onRequest()方法。onRequest()方法会被dispatchFunction调用，也就是说dispatchFunction调用是程序流从rild转入Vendor RIL的分界点。

RIL_register()函数将实现两个目地，一个是将RIL_INIT中获得的RIL_RadioFunction进行注册，rild通过此种方式保证自己持有一个RIL_RadioFunction实例，第二个是将s_fdListen加入到消息队列机制中，开启s_fdListen的事件监听。

●     Vendor RIL的初始化流程：

RIL_Init被调用后首先通过参数获取硬件接口的设备文件或模拟硬件接口的socket。（参见上文中对reference-ril文件夹的介绍）

接下来是创建mainLoop线程，并跳入到线程内执行。mainLoop会建立起与硬件的通信，然后通过read方法阻塞等待硬件的主动上报或响应。mainLoop还会调用initlizeCallBack()函数来向radio发送一系列的AT命令来进行radio的初始化设置工作。

上层应用开始向rild通过socket传输数据时，通过RIL消息队列机制，s_listen_event的回调函数listenCallBack将会被调用，开始进行数据流的分析与处理。

接下来,s_fdCommand = accept(s_fdListen, (sockaddr *) &peeraddr, &socklen),获取传入的socket描述符,也就是上层的java RIL传入的连接。

然后,通过record_stream_new()建立起一个RecordStream, 将这个record_stream与s_fdCommand绑定, RecordStream实际上是一个用于存放数据的结构体，这个结构体提供了一些操作类来保证这个RecordStream所绑定的文件描述符被读取时里面的数据会被完整读取。

一旦s_fdCommand中有数据，它的回调函数processCommandsCallback()将会被调用，processCommandsCallback()通过record_stream_get_next阻塞读取s_fdCommand上发来的 数据, 直到收到一完整的request。然后将其传递进processCommandBuffer()函数，processCommandBuffer()正式进入了命令的解析部分。

每个接收到的命令将以RequestInfo的形式存在。从socket过来的数据流,是Parcel处理过的序列化字节流, 在这里会通过反序列化的方法提取出来。最前面的是request号, 以及token域(request的递增序列号)。request号是一个CommandInfo,它在ril_command.h中定义。

接下来, 这个RequestInfo会被挂入pending的request队列, 执行具体的dispatchFunction(), 进行详细解析。

dispatchFunction方法有着多种实现，如dispatchVoid, dispatchString, 它们的调用取决于Parcel的参数传入形式。比如说在dispatchDial方法中，Parcel对象将被解析为RIL_Dial结构。这是disptachFunction的任务之一，它的另一个任务就是调用onRequest()方法，并将解析的内容传入onRequest()方法。

从onRequest方法开始，程序控制流脱离了RILD,进入到了Vendor RIL中。

onRequest方法会通过传入的请求类型来调用指定的request×××()方法，request×××()方法则负责组装AT指令并下发给at_send_command()方法集合中的一个，这个方法集合提供了针对不同类型AT指令的实现，如单行AT指令at_send_command_singleline(),短信息指令at_send_command_sms()等。

最后，执行at_send_command_full(),再通过一个互斥的at_send_command_full_nolock()调用,完成最终的写出操作,在writeline()中,写出到初始化时打开的设备中。

需要注意的是：at_send_command_full_nolock()在将指令写入radio后并不会直接返回，而是通过条件变量等待响应信息，得到响应信息后会携带这些信息返回。具体流程可以参考下面的response流程分析。

AT的response有两种，一种是unsolicited。另一种是普通response，也就是命令的响应。

response信息的获取在readerLoop()中。由readline()函数读取上来。

    读取到的line将被传入processLine()函数进行解析，processLine()函数首先会判断当前的响应是主动响应还是普通响应，如果是主动响应，将调用handleUnsolicited()函数，如果为普通响应，那么将调用handleFinalResponse()函数进行处理

对响应串的主要的解析过程，由at_tok.c中的各种解析函数完成，提供字符串分析解析功能。

●     对主动上报的解析

handleUnsolicited ()方法处理主动上报，它会调用onUnsolicited()来进行进一步的解析，这个函数在Vendor-RIL初始化时被传入at_open（）函数，onUnsolicited只解析出头部(一般是+XXXX的形式)，然后按类型决定下一步操作，操作为 RIL_onUnsolicitedResponse和RIL_requestTimedCallback两种。

在RIL_onUnsolicitedResponse()函数中，通过Parcel传递，将 RESPONSE_UNSOLICITED，unsolResponse(request号)写入Parcel，然后调用对应的responseFunction完成进一步的的解析，将解析的数据写入Parcel中，最后通过sendResponse()→sendResponseRaw()→blockingWrite()→writeLine()将数据写回给与应用层通信的socket。

在RIL_requestTimedCallback()函数中。通过event机制实现的timer机制，回调对应的内部处理函数。通过internalRequestTimedCallback将回调添加到event循环，最终完成callback上挂的函数的回调。比如 pollSIMState，onPDPContextListChanged等回调， 不用返回上层，内部处理就可以。

●     对普通上报的解析

IsFinalResponse()和isFinalResponseError()所处理的是一条AT指令的响应上报，它们将转入handleFinalResponse方法。

handleFinalResponse()函数会将所有响应信息装入sp_response,这是一个ATResponse结构，它的成员包括成功与否（success）以及一个中间结果（p_intermediates）。

handleFinalResponse()在将响应结果保存至sp_response后， 设置s_commandcond这一条件变量，此条件变量由at_send_command_full_nolock等待。

at_send_command_full_nolock获得到了完整的响应信息（在sp_response中），便开始进行响应信息的处理，最后由RIL_onRequestComplete将响应数据序列化并通过sendResponse传递至与应用层通信的socket，这一部分与RIL_onUnsolicitedResponse()函数的功能非常相似，请参考对主动上报的解析部分。

Android RIL与WindowsMobile RIL 在设计思路上都是作为一个radio的抽象，为上层提供电话服务，但在实现方式上两者有着一定的差异，这种差异的产生主要是源自操作系统机制的不同。

Android RIL被实现为HAL,相对于windows mobile中被实现为驱动的方式，Android RIL模块的内聚性更为理想，可维护性也将更强，你也可以把Android Ril 看做一个中间件。Android RIL部分的开发工作，只需要拿到相应的radio文件描述符，就可以进行操作，无需关注radio的I/O驱动实现。

2.1两者在与应用通信上的实现对比

WindowsMobile RIL在实现与应用的通信时提供了RIL Proxy,在这个层面中它定义了大量的RIL_***()函数来作为电话服务请求。这一点与Android RIL的实现比较相似，Android RIL中在ril.h内提供了一系列的宏来定义电话服务请求。

在Android中的rild功能类似于windows mobile RIL的RIL proxy。它同样也是起到一个中介的作用，为上层接口向下传递请求，并上传回响应。在windows mobile RIL中要为每一个应用程序客户提供一份Ril Proxy实例。

对于这两种操作系统平台，RIL所定义的所有请求是不可更改的。

2.2两者在线程结构与回调机制上的对比

在windows mobile的设计中，request与response被设计为异步执行的，他们分别使用两个队列来对它们的异步行为进行管理，执行命令下发和上报命令处理的过程也互不影响，下发命令与命令的相应响应之间的依赖关系由应用程序来捏合。

在android ril中的request与response设计与windows mobile不同，它的命令与响应之间是同步的过程。也就是说一条命令被下发后，将等待执行结果，并进行处理，再上向上层发。而不是直接异步的进行处理和向上发送。

要实现某个无线模块的RIL，需要创建一个实现了所有请求方法的共享库，保证Android能够响应无线通信请求。所有的请求被定义ril.h中。

不同的Modem使用不同的端口，这个在init.rc中设置。

　　Android提供了一个参考Vendor RIL，RIL参考源码在reference-ril。

　　将你自己的Vendor RIL实现编译为共享库形式：
　　  libril-<companyname>-<RIL version>.so

　　比如：
　　libril-techfaith-124.so
　　其中：
　　 libril：所有vendor RIL的开头
　　 <companyname>：公司缩写
　　 <RIL version>：RIL版本number
　　 so：文件扩展

在init.rc文件中，将通过这种方式来进行Android RIL的加载。

service ril-daemon /system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyS0

也可以手动加载：

/system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyS0

这两种方式，都将启动rild守护进程，然后通过-l参数将libreference-ril.so共享库链入，libreference-ril.so的参数-d是指加载一个串口设备，/dev/ttyS0则是这个串口设备的具体设备文件，除了参数-d外，还有-s代表加载类型为socket的设备，-p代表回环接口。

rild:

被编译成可执行文件，rild以守进程的形式执行。

libril:

将被编译为共享库，并被链入rild。

Vendor RIL:

可以以两种方式来运行，如果定义了RIL_SHLIB宏,那么它将被编译成共享库，如果没定义RIL_SHLIB宏，它将以守护进程程序的方式被调用执行。

Android RIL的Java部分也被分为了两个模块，RIL模块与Phone模块。其中RIL模块负责进行请求以及相应的处理，它将直接与RIL的原声代码进行通信。而Phone模块则向应用程序开发者提供了一系列的电话功能接口。

4.1.RIL模块结构

在RIL.java中实现了几个类来进行与下层rild的通信。

它实现了如下几个类来完成操作：

RILRequest：代表一个命令请求

RIL.RILSender：负责AT指令的发送

RIL.RILReceiver：用于处理主动和普通上报信息

RIL.RILSender与RIL.RILReceiver是两个线程。

RILRequest提供了obtain()方法，用于得到具体的request操作，这些操作被定义在RILConstants.java中（RILConstants.java中定义的request命令与RIL原生代码中ril.h中定义的request命令是相同的）,然后通过send()函数发送EVENT_SEND,在RIL_Sender线程中处理这个EVENT_SEND将命令写入到stream(socket)中去。Socket是来自常量SOCKET_NAME_RIL,它与RIL 原生代码部分的s_fdListen所指的socket是同一个。

当有上报信息来到时，系统将通过RILReciver来得到信息，并进行处理。在RILReciver的生命周期里，它一直监视着SOCKET_NAME_RIL这个socket，当有数据到来时，它将通过readRilMessage()方法读取到一个完整的响应，然后通过processResponse来进行处理。

4.2.Phone模块结构

Android通过暴露Phone模块来供上层应用程序用户使用电话功能相关的接口。它为用户提供了诸如电话呼叫，短信息，SIM卡管理之类的接口调用。它的核心部分是类GSMPhone，这个是Gsm的电话实现，需要通过PhoneFactory获取这个GSMPhone。

GSMPhone并不是直接提供接口给上层用户使用，而是通过另外一个管理类TelephonyManager来供应用程序用户使用。

类TelephonyManager实现了android的电话相关操作。它主要使用两个服务来访问telephony功能：

1.ITelephony，提供给上层应用程序用户与telephony进行操作，交互的接口，在packages/apps/Phone中由PhoneInterfaceManager.java实现。

2.ItelephonyRegistry提供了一个通知机制，将底层来的上报通知给框架中需要得到通知的部分，由TelephonyRegistry.java实现。

GSMPhone通过PhoneNotifier的实现者DefaultPhoneNotifier将具体的事件转化为函数调用，通知到TelephonyRegistry。TelephonyRegistry再通过两种方式通知给用户，其一是广播事件，另外一种是通过服务用户在TelephonyRegistry中注册的IphoneStateListener接口，实现回调（回调方式参见android的aidl机制）。

相关网站：

http://code.google.com/android/

http://android-dls.com

http://www.ibm.com/developerworks/cn/opensource/theme/android/

http://en.wikipedia.org/wiki/Android_%28operating_system%29

相关书籍：

《UNIX环境高级编程》

《UNIX编程艺术》

《Android系统原理及开发要点详解》