8.5　SurfaceFlinger分析

这一节要对SurfaceFlinger进行分析。相比较而言，SurfaceFlinger不如AudioFlinger复杂。

8.5.1　SurfaceFlinger的诞生

SurfaceFlinger驻留于system_server进程，这一点和Audio系统的几个Service不太一样。它创建的位置在SystemServer的init1函数中（本书4.3.2节的第3点有介绍）。虽然位于SystemServer这个重要进程中，但是SF创建的代码却略显波澜不惊，没有什么特别之处。SF的创建首先会调用instantiate函数，代码如下所示：

[—＞SurfaceFlinger.cpp]

void SurfaceFlinger：instantiate（）{

defaultServiceManager（）-＞addService（

String16（"SurfaceFlinger"），new SurfaceFlinger（））；

}

前面在图8-14中指出了SF同时从BnSurfaceComposer和Thread类中派生，相关代码如下所示：

class SurfaceFlinger：public BnSurfaceComposer,protected Thread

从Thread派生这件事给了我们一个很明确的提示：

SurfaceFlinger会单独启动一个工作线程。

我们知道，Thread类的工作线程要通过调用它的run函数来创建，那这个run函数是在什么地方调用的呢？当然，最有可能的就是在构造函数中：

[—＞SurfaceFlinger.cpp]

SurfaceFlinger：SurfaceFlinger（）

：BnSurfaceComposer（），Thread（false），

mTransactionFlags（0），

mTransactionCount（0），

mResizeTransationPending（false），

mLayersRemoved（false），

mBootTime（systemTime（）），

mHardwareTest（"android.permission.HARDWARE_TEST"），

mAccessSurfaceFlinger（"android.permission.ACCESS_SURFACE_FLINGER"），

mDump（"android.permission.DUMP"），

mVisibleRegionsDirty（false），

mDeferReleaseConsole（false），

mFreezeDisplay（false），

mFreezeCount（0），

mFreezeDisplayTime（0），

mDebugRegion（0），

mDebugBackground（0），

mDebugInSwapBuffers（0），

mLastSwapBufferTime（0），

mDebugInTransaction（0），

mLastTransactionTime（0），

mBootFinished（false），

mConsoleSignals（0），

mSecureFrameBuffer（0）

{

init（）；//上面没有调用run。必须到init去检查一番。

}

//init函数更简单了。

void SurfaceFlinger：init（）

{

char value[PROPERTY_VALUE_MAX]；

property_get（"debug.sf.showupdates"，value，"0"）；

mDebugRegion=atoi（value）；

property_get（"debug.sf.showbackground"，value，"0"）；

mDebugBackground=atoi（value）；

}

嗯？上面的代码竟然没有创建工作线程？难道在其他地方？读者别急着在文件中搜索“run”，先猜测一下答案。

根据之前所学的知识，另外一个最有可能的地方就是onFirstRef函数了，这个函数在对象第一次被sp化后调用，很多初始化的工作也可以在这个函数中完成。

事实是这样吗？一起来看——

1.onFirstRef分析

onFirstRef的代码如下所示：

[—＞SurfaceFlinger.cpp]

void SurfaceFlinger：onFirstRef（）

{

//梦里寻他千百度，却是在onFirstRef中创建了工作线程。

run（"SurfaceFlinger"，PRIORITY_URGENT_DISPLAY）；

/*

mReadyToRunBarrier类型为Barrier，这个类封装了一个Mutex对象和一个Condition对象。如果读者还记得第5章有关同步类的介绍，理解这个Barrier就非常简单了。下面调用的wait函数表示要等待一个同步条件满足。

*/

mReadyToRunBarrier.wait（）；

}

onFirstRef创建工作线程后，将等待一个同步条件，那么这个同步条件在哪里被触发呢？相信不用多说大家也知道：

在工作线程中被触发，而且极有可能是在readyToRun函数中。

注意　不清楚Thread类的读者可以复习一下与第5章有关Thread类的知识。

2.readyToRun分析

SF的readyToRun函数将完成一些初始化工作，代码如下所示：

[—＞SurfaceFlinger.cpp]

status_t SurfaceFlinger：readyToRun（）

{

int dpy=0；

{

//①GraphicPlane是什么？

GraphicPlane&plane（graphicPlane（dpy））；

//②为这个GraphicPlane设置一个HAL对象————DisplayHardware。

DisplayHardware*const hw=new DisplayHardware（this,dpy）；

plane.setDisplayHardware（hw）；

}

//创建Surface系统中的“CB”对象，按照老规矩，应该先创建一块共享内存，然后使用placment new。

mServerHeap=new MemoryHeapBase（4096，

MemoryHeapBase：READ_ONLY，

"SurfaceFlinger read-only heap"）；

/*

注意这个“CB”对象的类型是surface_flinger_cblk_t。为什么在CB上打引号呢？因为这个对象谈不上什么控制，只不过被用来存储一些信息罢了。其控制作用完全达不到audio_track_cblk_t的程度。基于这样的事实，我们把前面提到的SharedBuffer家族称之为CB对象。

*/

mServerCblk=

static_cast＜surface_flinger_cblk_t*＞（mServerHeap-＞getBase（））；

//placement new创建surface_flinger_cblk_t。

new（mServerCblk）surface_flinger_cblk_t；

const GraphicPlane&plane（graphicPlane（dpy））；

const DisplayHardware&hw=plane.displayHardware（）；

const uint32_t w=hw.getWidth（）；

const uint32_t h=hw.getHeight（）；

const uint32_t f=hw.getFormat（）；

hw.makeCurrent（）；

//当前只有一块屏。

mServerCblk-＞connected|=1＜＜dpy；

//屏幕在“CB”对象中的代表是display_cblk_t。

display_cblk_t*dcblk=mServerCblk-＞displays+dpy；

memset（dcblk，0，sizeof（display_cblk_t））；

dcblk-＞w=plane.getWidth（）；

dcblk-＞h=plane.getHeight（）；

……//获取屏幕信息。

//还用上了内联汇编语句。

asm volatile（""："memory"）；

/*

下面是一些和OpenGL相关的函数调用。读者如果感兴趣，可以研究一下，

至少SurfaceFlinger.cpp中所涉及的相关代码还不算难懂。

*/

glActiveTexture（GL_TEXTURE0）；

glBindTexture（GL_TEXTURE_2D，0）；

……

glOrthof（0，w,h，0，0，1）；

//LayerDim是Dim类型的Layer。

LayerDim：initDimmer（this,w，h）；

//还记得在onFirstRef函数中的wait吗？下面的open将触发这个同步条件。

mReadyToRunBarrier.open（）；

//资源准备好后，init将启动bootanim程序，这样就见到开机动画了。

property_set（"ctl.start"，"bootanim"）；

return NO_ERROR；

}

在上面的代码中，列出了两个关键点（即①和②），下面一一进行分析。

（1）GraphicPlane介绍

GraphicPlane是屏幕在SF代码中的对应物，根据前面的介绍可知，目前Android只支持一块屏幕，所以SF定义了一个一元数组：

GraphicPlane mGraphicPlanes[1]；

GraphicPlane虽无什么特别之处，但它有一个重要的函数，叫setDisplayHardware，这个函数把代表显示设备的HAL对象和GraphicPlane关联起来了。这也是下面要介绍的第二个关键点DisplayHardware。

（2）DisplayHardware介绍

从代码上看，这个和显示相关的HAL对象是在工作线程中new出来的，先看它的构造函数，代码如下所示：

[—＞DisplayHardware.cpp]

DisplayHardware：DisplayHardware（

const sp＜SurfaceFlinger＞&flinger，

uint32_t dpy）

：DisplayHardwareBase（flinger,dpy）

{

init（dpy）；//最重要的是这个init函数。

}

init函数非常重要，应进去看看。下面先思考一个问题。

前面在介绍FrameBuffer时说过，显示这一块需要使用FrameBuffer，但在GraphicBuffer中用的却是ashmem创建的共享内存。也就是说，之前在共享内存中绘制的图像和FrameBuffer没有什么关系。那么FrameBuffer是在哪里创建的呢？

答案就在init函数中，代码如下所示：

[—＞DisplayHardware.cpp]

void DisplayHardware：init（uint32_t dpy）

{

//FrameBufferNativeWindow实现了对FrameBuffer的管理和操作，该类中创建了两个

//FrameBuffer，分别起到FrontBuffer和BackBuffer的作用。

mNativeWindow=new FramebufferNativeWindow（）；

framebuffer_device_t const*fbDev=mNativeWindow-＞getDevice（）；

mOverlayEngine=NULL；

hw_module_t const*module；//Overlay相关

if（hw_get_module（OVERLAY_HARDWARE_MODULE_ID，&module）==0）{

overlay_control_open（module，&mOverlayEngine）；

}

……

EGLint w,h，dummy；

EGLint numConfigs=0；

EGLSurface surface；

EGLContext context；

mFlags=CACHED_BUFFERS；

//EGLDisplay在EGL中代表屏幕。

EGLDisplay display=eglGetDisplay（EGL_DEFAULT_DISPLAY）；

……

/*

surface是EGLSurface类型，下面这个函数会将EGL和Android中的Display系统绑定起来，后续就可以利用OpenGL在这个Surface上绘画，然后通过eglSwappBuffers输出图像了。

*/

surface=eglCreateWindowSurface（display,config，

mNativeWindow.get（），NULL）；

……

mDisplay=display；

mConfig=config；

mSurface=surface；

mContext=context；

mFormat=fbDev-＞format；

mPageFlipCount=0；

}

看了上面的代码，现在可以回答前面的问题了：

SF创建FrameBuffer，并将各个Surface传输的数据（通过GraphicBuffer）混合后，再由自己传输到FrameBuffer中显示。

注意　本节的内容，实际上涉及另外一个比Surface更复杂的Display系统，出于篇幅和精力的原因，本书目前不打算讨论它。