android Gui系统之SurfaceFlinger(1)---SurfaceFlinger概论【转】

阅读目录

• 2.1硬件接口的抽象
• 2.2接口的稳定性
• 3.1Gralloc模块的加载
• 4.2dequeuebuffer

转自：https://www.cnblogs.com/deman/p/5584198.html

阅读目录

• 1.OpenGL & OpenGL ES
• 2.Android的硬件接口HAL
• 3.Android显示设备：Gralloc & 　FrameBuffer
• 4.FrameBufferNativeWindow
• 5.Surface

GUI 是任何系统都很重要的一块。

android GUI大体分为4大块。

1）SurfaceFlinger

2）WMS

3）View机制

4）InputMethod

这块内容非常之多，但是理解后，可以触类旁通，其实现在主流的系统，包括andorid，ios在构架上，都是有很多相识之处。

我们先来讲SurfaceFlinger

 

回到顶部

1.OpenGL & OpenGL ES

OPenGL ES 是android系统绘画的基础。关于OpenGL部分，可以百度了解下。

先来看一个OpenGL & SurfaceFlinger之间的框架图：

回到顶部

2.Android的硬件接口HAL

回到顶部

2.1硬件接口的抽象

回到顶部

2.2接口的稳定性

Android已经把各个硬件都接口都统一定义在：

libhardware/include/hardware/ 具体代码可以参考：https://github.com/CyanogenMod/android_hardware_libhardware/tree/cm-12.0/include/hardware

 

回到顶部

3.Android显示设备：Gralloc & 　FrameBuffer

回到顶部

3.1Gralloc模块的加载

class FramebufferNativeWindow 
    : public ANativeObjectBase<
        ANativeWindow, 
        FramebufferNativeWindow, 
        LightRefBase<FramebufferNativeWindow> >
{

ANativeWindow是什么东西？

ANativeWindow是OpenGL 在android平台的显示类型。

所以FramebufferNativeWindow就是一种Open GL可以显示的类型。

FramebufferNativeWindow的构造函数上面已经贴出来了，进一步分析如下：

1）加载module，上面已经分析过了。

2）打开fb & gralloc，也已经分析过了。

3）根据fb的设备属性，获得buffer数。这个buffer后面会解释。

4）给每个buffer初始化，并分配空间。这里new NativeBuffer只是指定buffer的类型，或者分配了一个指针，但是没有分配内存，所以还需要alloc操作。

5）为本地窗口属性赋值。

目前buffer默认值是在2~3,后面会介绍3缓冲技术，就会用到3个buffer。

双缓冲技术：

把一组图画，画到屏幕上，画图是需要时间的，如果时间间隔比较长，图片就是一个一个的画在屏幕的，看上去就会卡。

如果先把图片放在一个缓冲buffer中，待全部画好后，把buffer直接显示在屏幕上，这就是双缓冲技术。

 

回到顶部

4.2dequeuebuffer

int FramebufferNativeWindow::dequeueBuffer(ANativeWindow* window, 
        ANativeWindowBuffer** buffer, int* fenceFd)
{
    FramebufferNativeWindow* self = getSelf(window);
    Mutex::Autolock _l(self->mutex);
    framebuffer_device_t* fb = self->fbDev;

    int index = self->mBufferHead++;
    if (self->mBufferHead >= self->mNumBuffers)
        self->mBufferHead = 0;

    // wait for a free non-front buffer
    while (self->mNumFreeBuffers < 2) {
        self->mCondition.wait(self->mutex);
    }
    ALOG_ASSERT(self->buffers[index] != self->front);

    // get this buffer
    self->mNumFreeBuffers--;
    self->mCurrentBufferIndex = index;

    *buffer = self->buffers[index].get();
    *fenceFd = -1;

    return 0;
}

代码不多，但是却是核心功能，通过它来获取一块可渲染的buffer。

1）获取FramebufferNativeWindow对象。为什么没有使用this 而是使用了传入ANativeWindow的方式，此处我们并不关心。

2）获得一个Autolock的锁，函数结束，自动解锁。

3）获取mBufferHead变量，这里自增，也就是使用下一个buffer，一共只有3个，（原因上面已经解释），所以循环取值。

4）如果没有可用的缓冲区，等待bufferqueue释放。一旦获取后，可用buffer就自减

 

回到顶部

5.Surface

Surface是另一个本地窗口，主要和app这边交互。注意：app层java代码无法直接调用surface，只是概念上surface属于app这一层的。

首先Surface是ANativeWindow的一个子类。

可以推测，surface需要解决如下几个问题：

1）面向上层（java层）提供画板。由谁来分配这块内存

2）与SurfaceFlinger是什么关系

Surface::Surface(
        const sp<IGraphicBufferProducer>& bufferProducer,
        bool controlledByApp)

 

sp<IGraphicBufferProducer>& bufferProducer 是分配surface内存的。它到底是什么呢？

 先来看看从ViewRootImpl到获取surface的过程。

ViewRootImpl持有一个java层的surface对象，开始是空的。

后续的流程见上面的流程图。也就是-说ViewRootImpl持有的surface对象，最终是对SurfaceComposerClient的创建的surface的一个“引用”。

由此分析可以看到 一个ISurfaceClient->ISurfaceComposerClient->IGraphicBufferProducer.当然binder需要一个实名的server来注册。

在ServiceManager中可以看到，这些服务查询的是“SurfaceFlinger”。

也就是，这些东东都是SurfaceFlinger的内容。

SurfaceFlinger::SurfaceFlinger()
    :   BnSurfaceComposer(),

SurfaceFlinger是BnSurfaceComposer的一个子类。也就是ISurfaceComposer的一个实现。

surface虽然是为app层服务的，但是本质上还是由SurfaceFlinger来管理的。

SurfaceFlinger怎么创建和管理surface，需要通过BufferQueue，将在下一篇讨论。

参考：

《深入理解android内核设计思想》 林学森