GUI系统之SurfaceFlinger(8)应用程序与BufferQueue的关系

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

GUI系统之SurfaceFlinger章节目录：
blog.csdn.net/uiop78uiop78/article/details/8954508

1.1.1 应用程序与BufferQueue的关系

接着上一小节未解决完的问题继续讲解。

现在我们已经明白了应用程序利用SurfaceFlinger进行绘制工作的大致流程了，只不过在这个过程中直到最后才出现了BufferQueue。应用程序具体是如何借助BufferQueue来完成工作的呢？

仔细观察不难发现，当应用端通过ISurfaceComposerClient::createSurface()来发起创建Surface的请求时，SurfaceFlinger服务进程这边会创建一个Layer。既然Layer代表了一个画面图层，那么它肯定需要有存储图层数据的地方，因而我们选择从这里做为入口。

/*frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp*/

/*应用程序首先是要通过ISurfaceComposerClient来访问createSurface，这个接口实际上只是一个中介，它将应用的请求传送到SurfaceFlinger的消息队列中，而不是直接调用SurfaceFlinger来处理。这样做是有必要的，因为一个系统中需要SurfaceFlinger处理的来自各应用程序的消息是很多的，除非一些紧急情况，否则都应该排队等待*/

sp<ISurface>SurfaceFlinger::createSurface(ISurfaceComposerClient::surface_data_t* params,

constString8& name, const sp<Client>& client, DisplayID d,

uint32_tw, uint32_t h, PixelFormat format, uint32_t flags)

{

    sp<LayerBaseClient>layer;

    sp<ISurface>surfaceHandle;

    …

    sp<Layer>normalLayer;

    switch (flags &eFXSurfaceMask) { //Layer类型

        case eFXSurfaceNormal:

            normalLayer = createNormalSurface(client, d, w, h, flags, format);

            layer =normalLayer;

            break;

        case eFXSurfaceBlur://4.1系统中将Blur与Dim类型当成一种

        case eFXSurfaceDim:

            layer = createDimSurface(client, d, w, h, flags);

            break;

        case eFXSurfaceScreenshot:

            layer = createScreenshotSurface(client, d, w, h, flags);

            break;

    }

    if (layer != 0) {…      

        surfaceHandle = layer->getSurface();

        …

    }

    return surfaceHandle;

}

可以看到，最后返回给应用程序的ISurface对应的变量是surfaceHandle，由layer通过getSurface()产生。从enum值定义来看，当前系统中有多达十几种Layer类型，只不过多数还没有真正实现，目前能用的只有四个，即eFXSurfaceNormal、eFXSurfaceBlur、eFXSurfaceDim、eFXSurfaceScreenshot。第一种就是通常情况下的图层;第二和第三种在当前系统中都被以eFXSurfaceDim来实现，从注释上看，很可能是Blur类型的Layer比较耗资源，所以暂时用Dim来取代。相信在后续的Android版本中还会把它们再区分开来。

Layer和ISurface有什么联系？

图 11‑18 Layer类继承关系

 

/*frameworks/native/services/surfaceflinger/LayerBase.cpp*/

sp<ISurface> LayerBaseClient::getSurface()

{

    sp<ISurface> s;

    Mutex::Autolock _l(mLock);

   LOG_ALWAYS_FATAL_IF(mHasSurface, "LayerBaseClient::getSurface() hasalready been called");

    mHasSurface = true;

    s = createSurface(); //通过这个函数产生一个ISurface

    mClientSurfaceBinder= s->asBinder();

    return s;

}

这个函数只能被调用一次，由mHasSurface来控制。当被第二次调用时，就会发生assert错误。LayerBaseClient通过成员变量mClientSurfaceBinder来记录ISurface。一个系统中同时存在的Layer和Surface通常不会只有一个，那么ISurface是如何知道它所属的Layer的呢？

sp<ISurface> LayerBaseClient::createSurface()

{

    class BSurface : publicBnSurface, public LayerCleaner {

        virtualsp<ISurfaceTexture> getSurfaceTexture() const { return 0; }

    public:

        BSurface(constsp<SurfaceFlinger>& flinger, const sp<LayerBaseClient>&layer)

            :LayerCleaner(flinger, layer) { }

    };

    sp<ISurface> sur(newBSurface(mFlinger, this));

    return sur;

}

和一般的写法不同，ISurface的本地实现BSurface是定义在函数中的。不过这不是问题的关键，关键问题是BSurface中的getSurfaceTexture居然直接返回了一个null(0)，显然如果是这样的话程序就没法继续执行了。唯一的解释是应该有LayerBaseClient的子类重载实现了这一函数，来看下Layer中是不是这样的。

/*frameworks/native/services/surfaceflinger/Layer.cpp*/

sp<ISurface> Layer::createSurface()

{

    class BSurface : publicBnSurface, public LayerCleaner {

        wp<const Layer>mOwner;

        virtualsp<ISurfaceTexture> getSurfaceTexture() const {

           sp<ISurfaceTexture> res;

            sp<constLayer> that( mOwner.promote() );

            if (that != NULL){

                res =that->mSurfaceTexture->getBufferQueue();

            }

            return res;

        }

    public:

        BSurface(constsp<SurfaceFlinger>& flinger, const sp<Layer>& layer)

            : LayerCleaner(flinger,layer), mOwner(layer) { }//mOwner在构造函数中以Layer赋值

    };

    sp<ISurface> sur(newBSurface(mFlinger, this));

    return sur;

}

看来我们猜测的是对的，Layer的确重载了createSurface。而且这里的getSurfaceTexture就不是pseudo的了。函数的最后生成了一个BSurface，注意看下它的构造参数中传入了this指针，也就是Layer对象自身。这个指针是后期ISurface与它通信的关键。同时作为入参的还有mFlinger，这样ISurface也可以访问到SurfaceFlinger了。因为这几个类都运行于同一个进程空间中，可以看到它们都直接是内存地址的传递，不需要IPC通信。

当应用程序通过ISurfaceComposerClient::createSurface()得到一个ISurface后，它会接着使用ISurface::getSurfaceTexture()来取得可用的texture(具体是由Surface在构造时获取，然后再通过Surface::init->setISurfaceTexture来将ISurfaceTexture赋值给SurfaceTextureClient::mSurfaceTexture),这个ISurfaceTexture是应用程序中的opengl本地窗口SurfaceTextureClient实现ANativeWindow规定的“协议”的基础）。

在getSurfaceTexture中，mOwner是一个指向Layer对象的弱指针，that->mSurfaceTexture指的是Layer中的SurfaceTexture类成员变量，所以函数最终是通过SurfaceTexture::getBufferQueue()来获得ISurfaceTexture。更具体地过程是，当Layer第一次被引用时，在onFirstRef()中会对mSurfaceTexture赋值。因为ISurface(即BSurface)持有这个Layer对象(mOwner)，所以当应用程序申请getSurfaceTexture时，它才能间接地向Layer要求取得ISurfaceTexture。我们前面说过，在binder server端，这个接口的实现类就是BufferQueue，如下所示：

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

sp<BufferQueue> SurfaceTexture::getBufferQueue() const {

    Mutex::Autolocklock(mMutex);

    return mBufferQueue;

}

函数直接返回了mBufferQueue，因为这个成员变量在SurfaceTexture构造时就已经初始化过了，它指向一个BufferQueue对象。大家一定要记住，ISurfaceTexture的server端实现是BufferQueue，由于命名上的差异，这点很容易搞错。

这样应用程序与BufferQueue的关系就比较明朗了。虽然中间经历了多次跨进程通信，但对于应用程序来说最终只使用到了BufferQueue(通过ISurfaceTexture)。从本小节的内容中，我们也可以从侧面证明如下几个关键点：

(1) 应用程序可以调用createSurface来建立多个Layer，它们是一对多的关系。理由就是createSurface中没有任何机制来限制应用程序的多次调用，相反，它会把一个应用程序多次申请而产生的Layer统一管理，如下：

sp<ISurface> SurfaceFlinger::createSurface(…constsp<Client>& client)

{

    sp<LayerBaseClient>layer;

    … /*省略的这部分是生成layer的过程，前面已经分析过了*/

    if (layer != 0) {…

        ssize_t  token = addClientLayer(client,layer);//将client与layer记录起来

        surfaceHandle =layer->getSurface();

        if (surfaceHandle !=0) {…

            if (normalLayer !=0) {//只对normal layer生效

               Mutex::Autolock _l(mStateLock);

                mLayerMap.add(layer->getSurfaceBinder(), normalLayer);

            }

        }…

}

为应用程序申请的layer，一方面需要告知SurfaceFlinger，另一方面也要记录到各Client内部中，这两个步骤是由addClientLayer()分别调用Client::attachLayer()和SurfaceFlinger::addLayer_l()来完成的。对于SurfaceFlinger，它需要对系统中当前所有的Layer进行Z-order排序，以决定用户所能看到的“画面”是什么样的。对于Client，它则利用内部的mLayers成员变量来一一记录新增(attachLayer)和移除(detachLayer)的图层。

 

(2) 每个Layer对应一个BufferQueue，换句话说，一个应用程序可能对应多个BufferQueue。Layer没有直接持有BufferQueue，而是由其内部的mSurfaceTexture来管理。

 

我们以下面这个关系图来结束本小节的学习：

图 11‑19 应用程序与BufferQueue的对应关系