GUI系统之SurfaceFlinger(4)opengl es本地窗口SurfaceTextureClient

文章都是通过阅读源码分析出来的，还在不断完善与改进中，其中难免有些地方理解得不对，欢迎大家批评指正。
转载请注明：From LXS. http://blog.csdn.net/uiop78uiop78/

1.1.1 SurfaceTextureClient

针对应用程序端的本地窗口是SurfaceTextureClient，和FramebufferNativeWindow一样，它必须继承ANativeWindow：

class SurfaceTextureClient

    : publicANativeObjectBase<ANativeWindow, SurfaceTextureClient,RefBase>

 

这个本地窗口当然也需要实现ANativeWindow所制定的“协议”，我们的重点是关注它与前面的FramebufferNativeWindow有什么不同。SurfaceTextureClient的构造函数只是简单地调用了init函数，后者则对ANativeWindow::dequeueBuffer等函数指针及内部变量赋了初值。由于整个函数的功能很简单，我们只摘录其中的一部分：

/*frameworks/native/libs/gui/SurfaceTextureClient.cpp*/

void SurfaceTextureClient::init() {

    /*给ANativeWindow中的函数指针赋值*/

   ANativeWindow::setSwapInterval  =hook_setSwapInterval;

    ANativeWindow::dequeueBuffer    = hook_dequeueBuffer;

    …

    /*为各内部变量赋值，因为此时用户还没有真正发起申请，所以基本是0*/

    mReqWidth = 0;

    mReqHeight = 0;

    …

    mDefaultWidth = 0;

    mDefaultHeight = 0;

    mUserWidth = 0;

    mUserHeight = 0;…

}

SurfaceTextureClient是面向Android系统中所有UI应用程序的，也就是说它承担着单个应用进程中的UI显示需求。基于这点考虑，可以推测出它的内部实现至少会有以下几点：

Ø  提供给上层(主要是java层)绘制图像的“画板”

前面说过，这个本地窗口分配的内存应该不是来自于帧缓冲区，那么具体是由谁分配的，又是如何管理的呢？

Ø  它与SurfaceFlinger间是如何分工的

显然SurfaceFlinger需要收集系统中所有应用程序绘制的图像数据，然后集中显示到物理屏幕上。在这个过程中，SurfaceTextureClient扮演了什么样的角色呢？

 

我们先来解释下这个类中的一些重要的成员变量，如下表所示：

表格 11‑4 SurfaceTextureClient部分成员变量一览

成员变量	说明
sp<ISurfaceTexture> mSurfaceTexture	这个变量是SurfaceTextureClient的核心，很多“协议”就是通过它实现的，后面会有详细讲解
BufferSlot mSlots[NUM_BUFFER_SLOTS]	从名称上可以看出，这是Client内部用于存储buffer的地方，容量NUM_BUFFER_SLOTS最多达32个。BufferSlot类内部又由一个GraphicBuffer和一个dirtyRegion组成，当有用户dequeueBuffer时就会分配真正的空间
uint32_t  mReqWidth	SurfaceTextureClient中有多组相似的宽高变量，它们之间是有区别的。这里的宽和高是指下一次dequeue时将会申请的尺寸，初始值都是1
uint32_t  mReqHeight
uint32_t mReqFormat	和上面的两变量类似，这是指下次dequeue时将会申请的buffer的像素格式，初始值是PIXEL_FORMAT_RGBA_8888
uint32_t mReqUsage	指下次dequeue时将会指定的usage类型
Rect mCrop	Crop表示“修剪”，这个变量将在下次queue时用于修剪缓冲区，可以调用setCrop来设置具体的值
int mScalingMode	同样，这个变量将用于下次queue时对缓冲区进行scale，可以调用setScalingMode来设置具体的值
uint32_t mTransform	用于下次queue时的图形翻转等操作(Transform)
uint32_t mDefaultWidth	默认情况下的缓冲区宽高值
uint32_t mDefaultHeight
uint32_t mUserWidth	如果不为零的话，就是应用层指定的值，将会覆盖前面的mDefaultWidth/ mDefaultHeight
uint32_t mUserHeight
sp<GraphicBuffer>           mLockedBuffer	这三个值需要锁的保护，接下来还会有分析
sp<GraphicBuffer>           mPostedBuffer
Region mDirtyRegion

从这些内部变量的描述中，我们可以大概了解到两点：SurfaceTextureClient中将通过mSurfaceTexture来获得buffer，而且这些缓冲区会被记录在mSlots数组中。接下来就来分析其中的实现细节。

前面SurfaceTextureClient构造函数里我们看到ANativeWindow中的函数指针赋予的是各种以hook开头的函数，这些函数内部又直接调用了SurfaceTextureClient中真正的实现，比如hook_dequeueBuffer对应的是dequeueBuffer。这就好像是“钩子”一样，所以称之为hook。

int SurfaceTextureClient::dequeueBuffer(android_native_buffer_t**buffer) {…

    Mutex::Autolocklock(mMutex);

int buf = -1;

/*Step1. 宽高计算*/

    int reqW = mReqWidth ?mReqWidth : mUserWidth;

int reqH = mReqHeight ? mReqHeight :mUserHeight;

/*Step2. dequeueBuffer得到一个缓冲区*/

    status_t result =mSurfaceTexture->dequeueBuffer(&buf, reqW, reqH,mReqFormat, mReqUsage);

    …

   sp<GraphicBuffer>& gbuf(mSlots[buf].buffer);//注意buf只是一个int值，代表的是mSlots数组序号

…

/*Step3. requestBuffer*/

    if ((result &ISurfaceTexture::BUFFER_NEEDS_REALLOCATION) || gbuf == 0) {

        result =mSurfaceTexture->requestBuffer(buf, &gbuf);

        …

    }

    *buffer = gbuf.get();

    return OK;

}

Step1@ SurfaceTextureClient::dequeueBuffer。用于UI绘制的图形缓冲区一定有宽高属性，具体的值由mReqWidth/mReqHeight或者mUserWidth/mUserHeight决定，其中前者的优先级比后者高

Step2@ SurfaceTextureClient::dequeueBuffer。可以看到，真正执行dequeueBuffer操作的确实是mSurfaceTexture(ISurfaceTexture)。这个变量的赋值有两个来源：作为SurfaceTextureClient的构造函数参数传入，然后间接调用setISurfaceTexture来设置的;或者SurfaceTextureClient的子类通过直接调用setISurfaceTexture来生成。

在应用进程环境中，属于后面一种情况。

具体流程就是：当Java层的Surface进行init时，实际上执行的函数是Surface_init@android_view_Surface.cpp。这个JNI函数将进一步调用SurfaceComposerClient::createSurface生成一个SurfaceControl，后者是用于管理Surface的类。它将在SurfaceControl::getSurface时生成一个Surface实例，在构造时通过SurfaceControl:: getSurfaceTexture来获得一个ISurfaceTexture。而Surface类实际上又继承自SurfaceTextureClient，所以它可以调用setISurfaceTexture。

由于Android源码有多处称为Surface的地方，取名极其混乱，我们下面通过一张完整的流程图来帮助大家把这些关系理顺：

图 11‑10 ISurfaceTexture创建流程

 

从这个图中可以看到，ISurfaceTexture是由ISurface::getSurfaceTexture生成的，而ISurface则是由SurfaceFlinger生成的。在这一过程中，总共使用到了三个匿名binderserver，它们所提供的接口整理如下表：

表格 11‑5 与Surface相关的三个匿名binder

匿名Binder	提供的接口
ISurfaceComposerClient	sp<ISurface> createSurface(…); status_t  destroySurface(SurfaceID sid);
ISurface	sp<ISurfaceTexture> getSurfaceTexture(…);
ISurfaceTexture	status_t requestBuffer(int slot, sp<GraphicBuffer>* buf); status_t setBufferCount(int bufferCount); status_t dequeueBuffer(…); status_t queueBuffer(…); void cancelBuffer(int slot); int query(int what, int* value); status_t setSynchronousMode(bool enabled); status_t connect(int api, QueueBufferOutput* output); status_t disconnect(int api);

由此可见，这三个匿名binder是一环扣一环的，也就是说我们访问的顺序只能是ISurfaceComposerClientàISurfaceàISurfaceTexture。当然，第一个匿名binder就一定是需要由一个实名binder来提供，它就是SurfaceFlinger，而SurfaceFlinger则是在ServiceManager中“注册在案”的。具体是在SurfaceComposerClient::onFirstRef()这个函数中，通过向ServiceManager查询名称为“SurfaceFlinger”的binder server来获得的。不过和其它常见binder server不同的是，SurfaceFlinger虽然在ServiceManager中注册的名称为“SurfaceFlinger”，但它在server端实现的binder接口却是ISurfaceComposer，因而SurfaceComposerClient得到的其实是ISurfaceComposer，这点大家要特别注意，否则可能会搞乱。

//我们可以从SurfaceFlinger的继承关系中看出这一区别，如下代码片断

class SurfaceFlinger :

        publicBinderService<SurfaceFlinger>, //在ServiceManager中注册为“SurfaceFlinger”

        public BnSurfaceComposer, //实现的接口却叫ISurfaceComposer，不知道为什么要这么设计。。。

绕了一大圈后，我们接着分析前面dequeueBuffer函数的实现。很显然SurfaceTextureClient只是一个中介，它间接调用mSurfaceTexture也就是ISurfaceTexture的服务。那么ISurfaceTexture在Server端又是由谁来完成的呢？

图 11‑11 ISurfaceTexture的本地端实现

 

因为这里面牵扯到很多新的类，我们先不做过多解释，到后面BufferQueue小节再详细分析其中的依赖关系。

当mSurfaceTexture->dequeueBuffer返回后，buf变量就是mSlots[]数组中可用的成员序号。接下来就要通过这个序号来获取真正的buffer地址，即mSlots[buf].buffer。

 

Step3@ SurfaceTextureClient::dequeueBuffer。假如返回值result中的标志包含了BUFFER_NEEDS_REALLOCATION，说明BufferQueue为这个Slot重新分配了空间，具体细节请参见下一个小节。此时我们还需要另外调用requestBuffer来确定gbuf的值，这其中又牵涉到很多东西，我们放在下面小节统一解释原因。

通过这两个小节，我们学习了显示系统中两个重要的本地窗口，即FramebufferNativewindow和SurfaceTextureClient。第一个窗口是专门为SurfaceFlinger服务的，它由Gralloc提供支持，相对逻辑上很好理解。而SurfaceTextureClient则是为应用程序服务的，同时它从本质上还是由SurfaceFlinger服务统一管理的，因而涉及到很多跨进程的通信细节。这个小节我们只是简单地勾勒出其中的框架，接下去就要分几个方面来做完整的分析了。

Ø  BufferQueue

为应用程序服务的本地窗口SurfaceTextureClient在server端的实现是BufferQueue。我们将详细解析BufferQueue的内部实现，并结合应用程序端的使用流程来理解清楚它们之间的关系。

 

Ø  Buffer、Consumer、Producer是“生产者-消费者”模型中的三个参与对象，如何协调好它们的工作是应用程序能否正常显示UI的关键。在接下来内容的安排上，我们先讲解Buffer(BufferQueue)与Producer(应用程序)间的交互，然后再专门切入Consumer(SurfaceFlinger)做详细分析