SurfaceFlinger驻留于system_server进程，这一点和Audio系统的几个Service不太一样。它创建的位置在SystemServer的init1函数中（第4章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() { charvalue[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() { intdpy = 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, "SurfaceFlingerread-only heap"); /* 注意这个“CB“对象的类型是surface_flinger_cblk_t。为什么在CB上打引号呢？因为这个对象 谈不上什么控制，只不过被用来存储一些信息罢了。其控制作用完全达不到audio_track_cblk_t 的程度。基于这样的事实，我们把前面提到的SharedBuffer家族称之为CB对象。 */ mServerCblk= static_cast<surface_flinger_cblk_t*>(mServerHeap->getBase()); //placementnew创建surface_flinger_cblk_t new(mServerCblk) surface_flinger_cblk_t; constGraphicPlane& plane(graphicPlane(dpy)); constDisplayHardware& hw = plane.displayHardware(); constuint32_t w = hw.getWidth(); constuint32_t h = hw.getHeight(); constuint32_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(); ......//获取屏幕信息 //还用上了内联汇编语句。 asmvolatile ("":::"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"); returnNO_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; EGLintnumConfigs=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系统，出于篇幅和精力的原因，本书目前不打算讨论它。