50298人阅读
Android（177）
&& & & &前面我们从Android应用程序与SurfaceFlinger服务的关系出发，从侧面简单学习了SurfaceFlinger服务。有了这些预备知识之后，我们就可以从正面来分析SurfaceFlinger服务的实现原理了。SurfaceFlinger服务负责管理系统的帧缓冲区设备，并且负责渲染系统的UI，即各个应用程序的UI。在本文中，我们就简要介绍SurfaceFlinger服务，并且制定学习计划。《Android系统源代码情景分析》一书正在进击的程序员网（）中连载，点击进入！&& & & &在前面一系列的文章中提到，SurfaceFlinger服务运行在System进程中，用来统一管理系统的帧缓冲区设备。由于SurfaceFlinger服务运行在System进程中，因此，Android应用程序就需要通过Binder进程间通信机制来请求它来渲染自己的UI。Android应用程序请求SurfaceFlinger服务渲染自己的UI可以分为三步曲：首先是创建一个到SurfaceFlinger服务的连接，接着再通过这个连接来创建一个Surface，最后请求SurfaceFlinger服务渲染该Surface。&& & & 由于SurfaceFlinger服务需要与Android应用程序执行Binder进程间通信，因此，它本身就是一个Binder本地对象，如图1所示：图1 SurfaceFlinger服务的类关系图&& & & &理解这个图需要学习Binder进程间通信机制，具体可以参考这一系列的文章。&& & & &SurfaceFlinger服务实现的接口为ISurfaceComposer，后者定义在文件frameworks/base/include/surfaceflinger/ISurfaceComposer.h中，如下所示：class ISurfaceComposer : public IInterface
DECLARE_META_INTERFACE(SurfaceComposer);
/* create connection with surface flinger, requires
* ACCESS_SURFACE_FLINGER permission
virtual sp&ISurfaceComposerClient& createConnection() = 0;
/* create a client connection with surface flinger
virtual sp&ISurfaceComposerClient& createClientConnection() = 0;
/* retrieve the control block */
virtual sp&IMemoryHeap& getCblk() const = 0;
/* open/close transactions. requires ACCESS_SURFACE_FLINGER permission */
virtual void openGlobalTransaction() = 0;
virtual void closeGlobalTransaction() = 0;
/* [un]freeze display. requires ACCESS_SURFACE_FLINGER permission */
virtual status_t freezeDisplay(DisplayID dpy, uint32_t flags) = 0;
virtual status_t unfreezeDisplay(DisplayID dpy, uint32_t flags) = 0;
/* Set display orientation. requires ACCESS_SURFACE_FLINGER permission */
virtual int setOrientation(DisplayID dpy, int orientation, uint32_t flags) = 0;
/* signal that we're done booting.
* Requires ACCESS_SURFACE_FLINGER permission
virtual void bootFinished() = 0;
/* Capture the specified screen. requires READ_FRAME_BUFFER permission
* This function will fail if there is a secure window on screen.
virtual status_t captureScreen(DisplayID dpy,
sp&IMemoryHeap&* heap,
uint32_t* width, uint32_t* height, PixelFormat* format,
uint32_t reqWidth, uint32_t reqHeight) = 0;
virtual status_t turnElectronBeamOff(int32_t mode) = 0;
virtual status_t turnElectronBeamOn(int32_t mode) = 0;
/* Signal surfaceflinger that there might be some work to do
* This is an ASYNCHRONOUS call.
virtual void signal() const = 0;
};&& & & &ISurfaceComposer接口有13个成员函数，下面我们就简单介绍一下：&& & & &--createConnection：Android应用程序通过它来请求SurfaceFlinger服务建立一个连接，具体可以参考一文。&& & & &--createClientConnection：Android应用程序通过它来请求SurfaceFlinger服务创建一块共享UI元数据缓冲区，具体可以参考一文。&& & & &--getCblk：Android应用程序通过它来请求SurfaceFlinger服务返回一块匿名共享内存，返回的匿名共享内存包含了设备显示屏的信息，例如，宽度和高度信息。&& & & &--openGlobalTransaction：Android应用程序通过它请求SurfaceFlinger服务来增加一个全局Transaction计数，用来批量修改UI属性信息。注意，这些被修改的UI属性信息会被缓存起来，不会马上生效。要使得这些被修改的UI属性信息生效，需要调用另外一个成员函数closeGlobalTransaction，如下所述。&& & & &--closeGlobalTransaction：Android应用程序通过它请求SurfaceFlinger服务来减少一个全局Transaction计数。当这个全局Transaction计数减少至0的时候，前面通过openGlobalTransaction来请求修改的UI属性信息就会马上生效。&& & & &--freezeDisplay：Android应用程序通过它来请求SurfaceFlinger服务来冻结屏幕。屏幕在被冻结期间，所有UI渲染操作都会被缓存起来，等待被执行。&& & & &--unfreezeDisplay：Android应用程序通过它来请求SurfaceFlinger服务来解冻屏幕。屏幕被解冻之后，SurfaceFlinger服务就可以执行UI渲染操作了。&& & & &--setOrientation：Android应用程序通过它来请求SurfaceFlinger服务设备屏幕的旋转方向。&& & & &--bootFinished：WindowManagerService通过它来告诉SurfaceFlinger服务，系统启动完成了，这时候SurfaceFlinger服务就会停止执行开机动画，具体可以参考一文。&& & & &--captureScreen：Android应用程序通过它来请求SurfaceFlinger服务截取屏幕图像。&& & & &--turnElectronBeamOff：Android应用程序通过它来请求SurfaceFlinger服务关闭屏幕。&& & & &--turnElectronBeamOn：Android应用程序通过它来请求SurfaceFlinger服务点亮屏幕。&& & & &--signal：Android应用程序通过它来请求SurfaceFlinger服务渲染UI，具体可以参考一文。&& & & &理解了ISurfaceComposer接口的定义之后，我们再来看SurfaceFlinger服务的Binder代理对象BpSurfaceComposer的实现，如图2所示：图2 SurfaceFlinger服务的Binder代理对象的类关系图&& & & &理解这个图同样需要学习Binder进程间通信机制，具体可以参考这一系列的文章。&& & & &Android应用程序获得了SurfaceFlinger服务的一个Binder代理对象，即一个BpSurfaceComposer对象之后，就可以请求SurfaceFlinger服务来创建以及渲染自己的UI了。&& & & &接下来，我们再简单介绍一下SurfaceFlinger类的定义，如图3所示：图3 SurfaceFlinger类的定义&& & & &SurfaceFlinger类有两个类型为State的成员变量mCurrentState和mDrawingState。其中，成员变量mCurrentState用来描述系统下一次要渲染的UI的状态；而mDrawingState用来描述当前正要渲染的UI的状态。&& & & &State类用来描述一个UI状态，它有四个重要的成员变量layersSortedByZ、orientation、orientationType和freezeDisplay。其中，成员变量layersSortedByZ是一个类型为LayerVector的向量，里面保存的系统所包含的Surface，每一个Surface使用一个LayerBase对象来描述，并且它们按照 Z轴顺序来排列；成员变量orientation和orientationType的类型均为uint8_t，它们用来描述屏幕的方向； 成员变量freezeDisplay的类型也是uint8_t，用来描述屏幕是否处于被冻结状态。&& & & &SurfaceFlinger类的成员变量mVisibleLayerSortedByZ是一个类型为sp&LayerBase&的Vector，它是用来保存SurfaceFlinger服务下一次要渲染的、处于可见状态的Surface的，它们是来自SurfaceFlinger类的成员变量mDrawingState所描述的一个State对象的成员变量layersSortedByZ的。&& & & &SurfaceFlinger类的成员变量mGraphicPlanes是一个类型为GraphicPlane的数组，它是用来描述系统所有的显示设备的。从这个数组的大小等于1可以知道，当前Android系统只支持一个显示设备。&& & & &GraphicPlane类有四个重要的成员变量mHw、mOrientation、mWidth和mHeight。其中，成员变量mHw指向一个DisplayHardware对象，用来描述一个硬件显示设备；成员变量mOrientation、mWidth和mHeight的类型均为int，分别用来描述一个硬件显示设备的旋转方向、宽度和高度。我们可以通过调用GraphicPlane类的成员函数setDisplayHardware和displayHardware来设备和获取一个GraphicPlane对象内部所包含的一个硬件显示设备。&& & & &DisplayHardware类有一个重要的成员变量mNativeWindow，它是一个类型为FramebufferNativeWindow的强指针。FramebufferNativeWindow类是用来描述一个Android系统本地窗口，而这个窗口代表的是系统的硬件帧缓冲区。DisplayHardware类的成员函数flip是用来渲染系统UI的，即将后端的图形缓冲区翻转为前端的图形缓冲区，并且渲染在硬件帧缓冲区去。&& & &&FramebufferNativeWindow类与在前面一文中所介绍的Surface类的作用是一样的，即它是OpenGL库和Android的UI系统之间的一个桥梁。OpenGL库正是通过它的成员函数dequeueBuffer来获得一个用来填充UI数据的图形缓冲区，而通过它的成员函数queueBuffer来将一个已经填充好UI数据的图形缓冲区渲染到系统的帧缓冲区中去。&& & &&FramebufferNativeWindow类有三个重要的成员变量fbDev、grDev和buffers。其中，成员变量fbDev和grDev分别指向一个framebuffer_device_t设备和一个alloc_device_t设备。从前面一文可以知道，framebuffer_device_t设备和一个alloc_device_t设备是由HAL模块Gralloc来提供的，它们分别用来分配图形缓冲区和渲染图形缓冲区；成员变量buffers是一个类型为NativeBuffer的数组，这个数组用来描述一个图形缓冲区堆栈，堆栈的大小为NUM_FRAME_BUFFERS，这些图形缓冲区是直接在硬件帧缓冲区中分配的，有别于Surface类所使用的图形缓冲区，因为后者所使用的图形缓冲区是在匿名共享内存分配的。&& & &了解了SurfaceFlinger类的重要成员变量之后，我们再来了解它的几个重要成员函数threadLoop、waitForEvent、signalEvent、handleConsoleEvents、handleTransaction、handlePageFlip、handleRepaint和postFramebuffer。&& & &&SurfaceFlinger服务虽然是在System进程中启动的，但是它在启动的时候创建一个线程来专门负责渲染UI。为了方便描述，我们将这个线程称为UI渲染线程。UI渲染线程的执行函数就为SurfaceFlinger类的成员函数threadLoop，同时它有一个消息队列。当UI渲染线程不需要渲染UI时，它就会在SurfaceFlinger类的成员函数waitForEvent中睡眠等待，直到SurfaceFlinger服务需要执行新的UI渲染操作为止。&& & &&SurfaceFlinger服务什么时候会需要执行新的UI渲染操作呢？当系统显示屏属性发生变化，或者应用程序窗口发生变化时，它就需要重新渲染系统的UI。这时候SurfaceFlinger服务就会从SurfaceFlinger类的成员函数waitEvent中唤醒，并且依次执行SurfaceFlinger类的成员函数handleConsoleEvents、handleTransaction、handlePageFlip、handleRepaint和postFramebuffer来具体执行渲染UI的操作。其中，成员函数handleConsoleEvents用来处理控制台事件；成员函数handleTransaction用来处理系统显示屏属性变化以及应用程序窗口属性变化；成员函数handlePageFlip用来获得应用程序窗口下一次要渲染的图形缓冲区，即设置应用程序窗口的活动图形缓冲区；成员函数handleRepaint用来重绘应用程序窗口；成员函数postFramebuffer用来将系统UI渲染到硬件帧缓冲区中去。&& & & 我们知道，应用程序是运行在与SurfaceFlinger服务不同的进程中的，而从前面一文又可以知道，每当应用程序需要更新自己的UI时，它们就会通过Binder进程间通信机制来通知SurfaceFlinger服务。SurfaceFlinger服务接到这个通知之后，就会调用SurfaceFlinger类的成员函数signalEvent来唤醒UI渲染线程，以便它可以执行渲染UI的操作。注意，SurfaceFlinger服务是通过Binder线程来获得应用程序的请求的，因此，这时候SurfaceFlinger服务的UI渲染线程实际上是被Binder线程唤醒的。SurfaceFlinger类的成员函数signalEvent实际上是通过向UI渲染线程的消息队列发送一个类型为INVALIDATE的消息来唤醒UI渲染线程的。&& & & 前面提到，&SurfaceFlinger服务在在执行UI渲染操作时，需要调用SurfaceFlinger类的成员函数handleConsoleEvents来处理控制台事件。这怎么理解呢？原来，SurfaceFlinger服务在启动的时候，还会创建另外一个线程来监控由内核发出的帧缓冲区硬件事件。为了方便描述，我们将这个线程称为控制台事件监控线程。每当帧缓冲区要进入睡眠状态时，内核就会发出一个睡眠事件，这时候SurfaceFlinger服务就会执行一个释放屏幕的操作；而当帧缓冲区从睡眠状态唤醒时，内核就会发出一个唤醒事件，这时候SurfaceFlinger服务就会执行一个获取屏幕的操作。&& & & 这样，我们就简要介绍完了SurfaceFlinger类的定义。从这些介绍可以知道：&& & & 1. SurfaceFlinger服务通过一个GraphicPlane对象来管理系统的显示设备；&& & & 2.&SurfaceFlinger服务有三种类型的线程，它们分别是Binder线程、控制台事件监控线程和UI渲染线程；&& & & 3.&SurfaceFlinger服务是在UI渲染线程中执行渲染系统UI的操作的。&& & & 围绕上述三个内容，再结合SurfaceFlinger服务的启动过程，接下来我们再通过以下四篇文章来系统地学习SurfaceFlinger服务的实现原理：&& & & 1. &&& & & 2. &？&& & &&3. &？&& & & 4. &？&& & & 结合前面的一系列文章，以及上述四篇文章，相信我们就可以对SurfaceFlinger服务有一个清晰的认识了，敬请关注！老罗的新浪微博：，欢迎关注！
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：9456530次
积分：42104
积分：42104
排名：第70名
原创：193篇
评论：7902条
《Android系统源代码情景分析》一书正在进击的程序员网()中连载，点击进入
本博客所有文章均为原创，欢迎交流，欢迎转载；转载请勿篡改内容，并且注明出处，禁止用于商业目的，谢谢！
《Android系统源代码情景分析》
电子工业出版社
本书繁体版已经成功输出到台湾
新浪微博：
QQ交流群：
文章：188篇
阅读：9423284&在前面一篇文章中，我们分析了Android应用程序与SurfaceFlinger服务的连接过程。Android应用程序成功连接上SurfaceFlinger服务之后，还需要一块匿名共享内存来和SurfaceFlinger服务共享它的UI元数据，
以便使得SurfaceFlinger服务可以正确地为它创建以及渲染Surface。在本文中，我们将详细地分析这块用来保存UI元数据的匿名共享内存的创建过程。
&& & & &在一文中提到，用来保存Android应用程序的UI元数据的匿名共享内存最终是被结构化为一个SharedClient对象来访问的。
每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象，而且这些SharedClient对象是由Android应用程序请求SurfaceFlinger服务创建的：
Android应用程序首先获得SurfaceFlinger服务的一个Binder代理接口，
然后再通过这个代理接口得到另外一个类型为UserClient的Binder代理接口，
最后就可以通过后一个Binder代理接口来获得一个SharedClient对象。
&& & & &由于每一个与UI有关的Android应用程序进程有且仅有一个SharedClient对象，因此，Android系统就通过一个单例模式的类来专负责创建和管理这个SharedClient对象。这个类的名称为SurfaceClient，定义在frameworks/base/libs/surfaceflinger_client/Surface.cpp文件中，如下所示：
class SurfaceClient : public Singleton&SurfaceClient&
// all these attributes are constants
sp&ISurfaceComposer& mComposerS
sp&ISurfaceComposerClient& mC
status_t mS
SharedClient* mC
sp&IMemoryHeap& mControlM
SurfaceClient()
: Singleton&SurfaceClient&(), mStatus(NO_INIT)
sp&ISurfaceComposer& sf(ComposerService::getComposerService());
mComposerService =
mClient = sf-&createClientConnection();
if (mClient != NULL) {
mControlMemory = mClient-&getControlBlock();
if (mControlMemory != NULL) {
mControl = static_cast&SharedClient *&(
mControlMemory-&getBase());
if (mControl) {
mStatus = NO_ERROR;
friend class Singleton&SurfaceClient&;
status_t initCheck() const {
SharedClient* getSharedClient() const {
ssize_t getTokenForSurface(const sp&ISurface&& sur) const {
// TODO: we could cache a few tokens here to avoid an IPC
return mClient-&getTokenForSurface(sur);
void signalServer() const {
mComposerService-&signal();
&当SurfaceClient类的静态成员函数getInstance第一次被调用的时候，系统就会在对应的应用程序进程中创建一个SurfaceClient对象，即会调用SurfaceClient类的构造函数。
SurfaceClient类的构造函数首先会调用ComposerService类的静态成员函数getComposerService来获得一个SurfaceFlinger服务的代理接口，并且保存在SurfaceClient类的成员变量mComposerService中，以便以后可以使用。
ComposerService类的静态成员函数getComposerService在前面一文中已经分析过了，这里不再详述。有了SurfaceFlinger服务的代理接口sf之后，
SurfaceClient类的构造函数接着就可以调用它的成员函数createClientConnection来获得一个类型为UserClient的Binder代理接口，这个Binder代理接口实现了ISurfaceComposerClient接口，
因此，我们可以将它保存在SurfaceClient类的成员变量mClient中。最后，SurfaceClient类的构造函数就调用前面获得的类型为ISurfaceComposerClient的Binder代理接口mClient的成员函数getControlBlock来获得一块用来描述应用程序UI元数据的匿名共享内存mControlMemory&，并且将这些匿名共享内存强制转化为一个SharedClient对象mControl，以便后面可以方便地访问UI元数据。
&& & & &以上就是Android应用程序与SurfaceFlinger服务之间的共享UI元数据（SharedClient）的创建过程的总体描述，接下来我们再详细分析每一步的实现。现在，我们继续分析一下SurfaceClient类的其余成员函数的实现：
&& & & &1. 成员函数initCheck用来检查一个Android应用程序进程是否已经成功地请求SurfaceFlinger服务创建了一块用来描述UI元数据的SharedClient对象了。
&& & & &2. 成员函数getSharedClient用来返回用来描述UI元数据的SharedClient对象mControl。
&& & & &3. 成员函数getTokenForSurface用来返回由参数sur所描述的一个Surface的Token值。这个Token值由SurfaceFlinger服务来创建和管理，并且可以通过前面所获得的类型为UserClient的Binder代理接口mClient的成员函数getTokenSurface来获得。
&& & & &4. 成员函数signalServer用来通知SurfaceFlinger服务更新Android应用程序UI，这是通过调用SurfaceFlinger服务的代理接口mComposerService的成员函数signal来实现的，实际上就是向SurfaceFlinger服务发送一个信号，
以便可以将它唤醒起来更新UI。
&& & & &介绍完成SurfaceClient类的实现之后，我们还需要了解一下两个类的实现，即UserClient类和SharedClient类的实现，以便可以帮助我们了解用来保存Android应用程序的UI元数据的匿名共享内存的创建过程，
以及帮助后面两篇文章对Surface的创建和渲染过程的分析。
&& & & &接下来，我们就首先分析UserClient类的实现，接着再分析SharedClient类的实现。
&& & & &在一文的图2中，我们介绍了用来连接Android应用程序和SurfaceFlinger服务的Client类，而UserClient类和Client类是类似的，它们都实现了相同的接口，只不过是侧重点有所不同。
一文的图2中的Client类替换成UserClient类，就可以得到UserClient类的实现结构图，如图1所示：
图1 UserClient类的实现结构图
&& & & UserClient类与Client类最重要的区别是，前者实现了ISurfaceComposerClient接口的成员函数getControlBlock，而后者实现了ISurfaceComposerClient接口的成员函数createSurface。后面我们就会分析UserClient类是如何实现ISurfaceComposerClient接口的成员函数getControlBlock的。
&& & &&UserClient类的实现暂时就介绍到这里，接下来我们来看SharedClient类的实现。为了方便描述，我们把一文的图4和图5贴出来，如以下图2和图3所示：
图2 用来描述Android应用程序的UI元数据的SharedClient
图3 SharedBufferStack的结构示意图
&& & & &每一个SharedClient对象包含了至多31个SharedBufferStack，而每一个SharedBufferStack都对应一个Android应用程序进程中的一个Surface。
&& & & &SharedClient类定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h&文件中，如下所示：
class SharedClient
SharedClient();
~SharedClient();
SharedBufferStack surfaces[ SharedBufferStack::NUM_LAYERS_MAX ];
&&它有一个大小为SharedBufferStack::NUM_LAYERS_MAX的SharedBufferStack数组。SharedBufferStack::NUM_LAYERS_MAX的值等于31，定义在SharedBufferStack类中。
&& & & &SharedBufferStack类同样是定义在文件frameworks/base/include/private/surfaceflinger/SharedBufferStack.h&文件中，如下所示：
class SharedBufferStack
// When changing these values, the COMPILE_TIME_ASSERT at the end of this
// file need to be updated.
static const unsigned int NUM_LAYERS_MAX
static const unsigned int NUM_BUFFER_MAX
static const unsigned int NUM_BUFFER_MIN
static const unsigned int NUM_DISPLAY_MAX = 4;
struct SmallRect {
uint16_t l, t, r,
struct FlatRegion {
static const unsigned int NUM_RECT_MAX = 5;
rects[NUM_RECT_MAX];
struct BufferData {
FlatRegion dirtyR
uint8_t reserved[3];
SharedBufferStack();
status_t setDirtyRegion(int buffer, const Region& reg);
status_t setCrop(int buffer, const Rect& reg);
status_t setTransform(int buffer, uint8_t transform);
Region getDirtyRegion(int buffer) const;
Rect getCrop(int buffer) const;
uint32_t getTransform(int buffer) const;
// these attributes are part of the conditions/updates
volatile int32_
// server's current front buffer
volatile int32_ // number of dequeue-able buffers
volatile int32_
// number of buffers waiting for post
// not part of the conditions
volatile int8_t index[NUM_BUFFER_MAX];
// last retired buffer
BufferData
buffers[NUM_BUFFER_MAX];
&下面我们简要地对SharedBufferStack类进行分析。
&& & & &首先，SharedBufferStack类在内部定义了四个常量：
&& & & &NUM_LAYERS_MAX -- 表示一个Android应用程序最多可以有NUM_LAYERS_MAX个Layer，可以将一个Layer理解为一个Surface。
&& & & &NUM_BUFFER_MAX -- 表示一个SharedBufferStack至多可以有NUM_BUFFER_MAX个UI元数据缓冲区。
&& & & &NUM_BUFFER_MIN -- 表示一个SharedBufferStack至少要有UM_BUFFER_MIN个UI元数据缓冲区。
&& & & &NUM_DISPLAY_MAX -- 表示Android系统至多可以支持NUM_DISPLAY_MAX个显示屏。
&& & & &从这些常量就可以看出：
&&&&&&&&1. Android系统至多支持4个显示屏。
&& & & &2. 一个Android应用程序至多可以同时创建31个Surface。
&& & & &3. 一个Surface可以有2~16个UI元数据缓冲区，即可以使用2~16缓冲区技术来渲染Surface。
&& & & &其次，SharedBufferStack类在内部定义了三个结构体：
&& & & &SmallRect -- 用来描述一个矩形区域，其中，成员变量l、t,、r和b分别表示左上和右下两个角的位置。
&& & & &FlatRegion -- 用来描述一个SmallRect数组rects ，数组的大小为NUM_RECT_MAX，但是实际个数为count。
&& & & &BufferData -- 用来描述一个UI元数据缓冲区，它有四个成员变量dirtyRegion、crop、transform和reserved，其中，dirtyRegion用来描述一个Surface需要更新的区域，即裁剪区域，crop用来描述一个Surface的纹理坐标，transform用来描述一个Surface的旋转方向，例如，旋转90度或者上下翻转等等，而reserved是保留给以后使用的。通过这个UI元数据缓冲区，SurfaceFlinger服务就可以正确地把一个Surface的图形缓冲区所描述的图形渲染到屏幕来。
&& & & &SharedBufferStack类有一个BufferData数组buffers，它的大小为NUM_BUFFER_MAX，即16，就是用来一组UI元数据缓冲区的，这些UI元数据缓冲区的内容可以分别通过setDirtyRegion、setCrop、setTransform、getDirtyRegion、getCrop和getTransform这六个成员函数来访问。这六个成员函数的第一个参数均为一个int值，用来描述要访问的是哪一个BufferData的数据。
&& & & &SharedBufferStack类还有另外一个类型为int8_t的数组index，它的大小也为NUM_BUFFER_MAX。这个index数组才是一个真正的Stack，它按照一定的规则来访问。index数组的每一个元素的值均是一个索引值，用来映射到数组buffers中去的。例如，假设index[0]的值等于2，那么它就对应数组buffers中的第2个元素，即buffers[2]。
&& & & &SharedBufferStack类的其余重要成员变量的含义如下所示：
&& & & &head -- 用来描述一个SharedBufferStack的头部，它是一个索引值，是映射到数组index中去的。
&& & & &available -- 用来描述一个SharedBufferStack中的空闲UI元数据缓冲区的个数。
&& & & &queued -- 用来描述一个SharedBufferStack中的已经补使用了的UI元数据缓冲区的个数，即那些在排队等待SurfaceFlinger服务使用的UI元数据缓冲区。
&& & & &headBuf -- 用来描述一个SharedBufferStack的头部所对应的UI元数据缓冲区的编号，这个编号是映射到数组buffers中去。
&& & & &关于SharedBufferStack类的实现，我们就暂时介绍到这里，在下一篇文章分析Android应用程序的Surface创建过程时，我们再通过SharedBufferServer类和SharedBufferClient类的实现来进一步理解SharedBufferStack类的实现。
&& & & &现在，我们就开始详细分析Android应用程序与SurfaceFlinger服务之间的共享UI元数据的创建过程，如图4所示：
图 4 Android应用程序的共享UI元数据的创建过程
&& & & &接下来我们就详细分析每一个步骤。
&&&&&&&&Step 1. SurfaceFlinger::createClientConnection
sp&ISurfaceComposerClient& SurfaceFlinger::createClientConnection()
sp&ISurfaceComposerClient&
sp&UserClient& client(new UserClient(this));
status_t err = client-&initCheck();
if (err == NO_ERROR) {
&&SurfaceFlinger类的成员函数createClientConnection实现在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中，它的实现很简单，只是创建了一个类型为UserClient的Binder对象client，
并且获得它的一个ISurfaceComposerClient接口，最后将这个ISurfaceComposerClient接口，即一个UserClient代理对象，返回给Android应用程序进程。
&& & & &接下来，我们再继续分析UserClient对象的创建过程,，即UserClient类的构造函数的实现。
&&&&&&&& Step 2. new UserClient
UserClient::UserClient(const sp&SurfaceFlinger&& flinger)
: ctrlblk(0), mBitmap(0), mFlinger(flinger)
const int pgsize = getpagesize();
const int cblksize = ((sizeof(SharedClient)+(pgsize-1))&~(pgsize-1));
mCblkHeap = new MemoryHeapBase(cblksize, 0,
"SurfaceFlinger Client control-block");
ctrlblk = static_cast&SharedClient *&(mCblkHeap-&getBase());
if (ctrlblk) { // construct the shared structure in-place.
new(ctrlblk) SharedC
&&&UserClient类的成员变量mFlinger是一个类型为SurfaceFlinger的强指针，它指向了SurfaceFlinger服务，&UserClient类的另外一个成员变量mBitmap是一个int32_t值，它是用来为Android应用程序的Surface分配Token值的，
即如果它的第n位等于1，那么就表示值等于n的Token已经被分配出去使用了。
&& & & &UserClient类的构造函数首先得到一个SharedClient对象的大小，接着再将这个大小对齐到页面边界，于是就得到了接下来要创建的匿名共享块的大小cblksize。这块匿名共享内存是一个MemoryHeapBase对象描述的，
并且保存在UserClient类的成员变量mCblkHeap。MemoryHeapBase类是用来创建匿名共享内存的一个C++接口，它的实现原理可以参考分析一文。
&& & & &UserClient类的构造函数得到了一块匿名共享内存之后，紧接着就在这块匿名共享内存上创建了一个SharedClient对象，并且保存在UserClient类的成员变量ctrlblk中，以便后面可以通过它来访问Android应用程序的UI元数据。
&& & & &回到SurfaceFlinger类的成员函数createClientConnection中，它将一个指向了一个UserClient对象的ISurfaceComposerClient接口返回到Android应用程序进程之后，Android应用程序进程就可以将它封装成一个类型为BpSurfaceComposerClient的Binder代理对象。
&&&&&&&&Step 3. return&BpSurfaceComposerClient
&& & & &将一个Binder代理对象封装成一个BpSurfaceComposerClient的过程可以参考前面一文中的Step 4。
&& & & &Step 4.&UserClient::getControlBlock
sp&IMemoryHeap& UserClient::getControlBlock() const {
return mCblkH
&&&&&&从前面的Step 2可以知道，UserClient类的成员变量mCblkHeap指向了一块匿名共享内存，UserClient类将这块匿名共享内存返回给Android应用程序之后，Android应用程序就会将它结构化成一个SharedClient对象来访问，
并且保存在SurfaceClient类的成员变量mControl中，这个结构化过程就可以参考前面所描述的SurfaceClient类的构造函数了。
&& & & &至此，用来描述Android应用程序的UI元数据的一个SharedClient对象的创建过程就分析完了。以后当Android应用程序请求SurfaceFlinger服务创建一个Surface的时候，SurfaceFlinger服务就会从这个SharedClient对象中取出一个SharedBufferStack出来，以便可以用作这个Surface的UI元数据缓冲区。在接下来的一篇文章中，我们将详细描述Android应用程序请求SurfaceFlinger服务创建Surface的过程，敬请期待！
阅读(...) 评论()}