💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
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系统,出于篇幅和精力的原因,本书目前不打算讨论它。