8.5.1 SurfaceFlinger的诞生
最后更新于：2022-04-02 05:52:45
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(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<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& 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系统，出于篇幅和精力的原因，本书目前不打算讨论它。
';