Android系统Surface机制的SurfaceFlinger服务的启动过程分析Word格式.doc
《Android系统Surface机制的SurfaceFlinger服务的启动过程分析Word格式.doc》由会员分享，可在线阅读，更多相关《Android系统Surface机制的SurfaceFlinger服务的启动过程分析Word格式.doc（12页珍藏版）》请在冰点文库上搜索。
那些使用C++语言来实现的系统服务。
SystemServer类的静态成员函数init1是一个JNI方法，它是由C++层的函数android_server_SystemServer_init1来实现的，接下来我
们就继续分析它的实现。
Step2.SystemServer.init1
[cpp]viewplaincopy在CODE上查看代码片派生到我的代码片
staticvoidandroid_server_SystemServer_init1（JNIEnv*env,jobjectclazz）
system_init（）;
这个函数定义在文件frameworks/base/services/jni/com_android_server_SystemServer.cpp中。
SystemServer类的静态成员函数init1调用另外一个函数system_init来启动那些使用C++语言来实现的系统服务，它的实现在文件
frameworks/base/cmds/system_server/library/system_init.cpp中，如下所示：
extern"
C"
status_tsystem_init（）
LOGI（"
Enteredsystem_init（）"
sp<
ProcessState>
proc（ProcessState:
:
self（））;
charpropBuf[PROPERTY_VALUE_MAX];
property_get（"
system_init.startsurfaceflinger"
propBuf,"
1"
if（strcmp（propBuf,"
）==0）{
//StarttheSurfaceFlinger
SurfaceFlinger:
instantiate（）;
if（proc->
supportsProcesses（））{
LOGI（"
Systemserver:
enteringthreadpool.\n"
ProcessState:
self（）->
startThreadPool（）;
IPCThreadState:
joinThreadPool（）;
exitingthreadpool.\n"
returnNO_ERROR;
函数首先获得System进程中的一个ProcessState单例，并且保存在变量proc中，后面会通过调用它的成员函数supportsProcesses来判
断系统是否支持Binder进程间通信机制。
我们知道，在Android系统中，每一个需要使用Binder进程间通信机制的进程内部都有一个
ProcessState单例，它是用来和Binder驱动程序建立连接的，具体可以参考Android系统进程间通信（IPC）机制Binder中的Server启动过程源
代码分析一文。
函数接下来就检查系统中是否存在一个名称为“system_init.startsurfaceflinger”的属性。
如果存在的话，就将它的值获取回来，
并且保存在缓冲区proBuf中。
如果不存在的话，那么函数property_get就会将缓冲区proBuf的值设置为“1”。
当缓冲区proBuf的值等于“1”
的时候，就表示需要在System进程中将SurfaceFlinger服务启动起来，这是通过调用SurfaceFlinger类的静态成员函数instantiate来实现的。
函数最后检查系统是否支持Binder进程间通信机制。
如果支持的话，那么接下来就会调用当前进程中的ProcessState单例的成员函数
startThreadPool来启动一个Binder线程池，并且调用当前线程中的IPCThreadState单例来将当前线程加入到前面所启动的Binder线程池中去。
从前面和两篇文章可以知道，System进程前面在初
始化运行时库的过程中，已经调用过当前进程中的ProcessState单例的成员函数startThreadPool来启动Binder线程池了，因此，这里其实只是
将当前线程加入到这个Binder线程池中去。
有了这个Binder线程池之后，SurfaceFlinger服务在启动完成之后，就可以为系统中的其他组件或
者进程提供服务了。
假设系统存在一个名称为“system_init.startsurfaceflinger”的属性，并且它的值等于“1”，接下来我们就继续分析
SurfaceFlinger类的静态成员函数instantiate的实现，以便可以了解SurfaceFlinger服务的启动过程。
由于SurfaceFlinger类的静态成员函数
instantiate是从父类BinderService继承下来的，因此，接下来我们要分析的实际上是BinderService类的静态成员函数instantiate的实现。
Step3.BinderService.instantiate
template<
typenameSERVICE>
classBinderService
public:
staticvoidinstantiate（）{publish（）;
}
};
这个函数定义在文件frameworks/base/include/binder/BinderService.h中。
BinderService类的静态成员函数instantiate的实现很简单，它只是调用BinderService类的另外一个静态成员函数publish来继续执行
启动SurfaceFlinger服务的操作。
Step4.BinderService.publish
staticstatus_tpublish（）{
sp<
IServiceManager>
sm（defaultServiceManager（））;
returnsm->
addService（String16（SERVICE:
getServiceName（））,newSERVICE（））;
BinderService是一个模板类，它有一个模板参数SERVICE。
当BinderService类被SurfaceFlinger类继承时，模板参数SERVICE的值就等
于SurfaceFlinger。
因此，BinderService类的静态成员函数publish所执行的操作就是创建一个SurfaceFlinger实例，用来作为系统的
SurfaceFlinger服务，并且将这个服务注册到ServiceManager中去，这样系统中的其它组件或者进程就可以通过ServiceManager来获得
SurfaceFlinger服务的Binder代理对象，进而使用它所提供的服务。
Binder进程间通信机制中的服务对象的注册过程可以参考Android系统进程
间通信（IPC）机制Binder中的Server启动过程源代码分析一文。
接下来，我们就继续分析SurfaceFlinger服务的创建过程。
Step5.newSurfaceFlinger
SurfaceFlinger:
SurfaceFlinger（）
:
BnSurfaceComposer（）,Thread（false）,
init（）;
这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。
从前面一文可以知道，SurfaceFlinger类继承了
BnSurfaceComposer类，而后者是一个实现了ISurfaceComposer接口的Binder本地对象类。
此外，SurfaceFlinger类还继承了Thread类，后者是
用来创建一个线程的，这个线程就是我们在一文中提到的UI渲染线程，它
的线程执行体函数为SurfaceFlinger类的成员函数threadLoop。
后面在分析SurfaceFlinger服务渲染UI的过程时，我们再分析SurfaceFlinger
类的成员函数threadLoop的实现。
注意，在初始化SurfaceFlinger的父类Thread时，传进去的参数为false，表示先不要将SurfaceFlinger服务
的UI渲染线程启动起来，等到后面再启动。
SurfaceFlinger服务在创建的过程中，会调用SurfaceFlinger类的成员函数init来执行初始化的操作，接下来，我们就继续分析它的实
现。
Step6.SurfaceFlinger.init
voidSurfaceFlinger:
init（）
SurfaceFlingerisstarting"
//debuggingstuff...
charvalue[PROPERTY_VALUE_MAX];
debug.sf.showupdates"
value,"
0"
mDebugRegion=atoi（value）;
debug.sf.showbackground"
mDebugBackground=atoi（value）;
LOGI_IF（mDebugRegion,"
showupdatesenabled"
LOGI_IF（mDebugBackground,"
showbackgroundenabled"
这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。
SurfaceFlinger类的成员函数init的实现很简单，它分别获得系统中两个名称为“debug.sf.showupdates”和
“debug.sf.showbackground”的属性的值，并且分别保存在SurfaceFlinger类的成员变量mDebugRegion和mDebugBackground中。
这两个成员变
量是与调试相关的，我们不关心。
这一步执行完成之后，返回到前面的Step4中，即BinderService类的静态成员函数publish中，这时候在前面的Step5中所创建的一
个SurfaceFlinger实例就会被注册到ServiceManager中，这是通过调用ServiceManager的Binder代理对象的成员函数addService来实现的。
由于ServiceManager的Binder代理对象的成员函数addService的第二个参数是一个类型为IBinder的强指针引用。
从前面一文可以知道，
当一个对象第一次被一个强指针引用时，那么这个对象的成员函数onFirstRef就会被调用。
因此，接下来前面所创建的SurfaceFlinger实例的
成员函数onFirstRef就会被调用，以便可以继续执行初始化操作。
Step7.SurfaceFlinger.onFirstRef
onFirstRef（）
run（"
SurfaceFlinger"
PRIORITY_URGENT_DISPLAY）;
//Waitforthemainthreadtobedonewithitsinitialization
mReadyToRunBarrier.wait（）;
}<
spanstyle="
font-family:
Arial,Helvetica,sans-serif;
"
>
<
white-space:
normal;
/span>
函数首先调用从父类继承下来的成员函数run来启动一个名秒为“SurfaceFlinger”的线程，用来执行UI渲染操作。
这就是前面我们所
说的UI渲染线程了。
这个UI渲染线程创建完成之后，首先会调用SurfaceFlinger类的成员函数readyToRun来执行一些初始化操作，接着再循环
调用SurfaceFlinger类的成员函数threadLoop来作为线程的执行体。
mReadyToRunBarrier是SurfaceFlinger类的一个成员变量，它的类型是Barrier，用来描述一个屏障，是通过条件变量来实现的。
我们
可以把它看作是一个线程同步工具，即阻塞当前线程，直到SurfaceFlinger服务的UI渲染线程执行完成初始化操作为止。
接下来，我们就继续分析SurfaceFlinger类的成员函数readyToRun的实现，以便可以了解SurfaceFlinger服务的UI渲染线程的初始化过
程。
Step8.SurfaceFlinger.oreadyToRun
这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp文件中，用来初始化SurfaceFlinger服务的UI渲
染线程，我们分段来阅读：
status_tSurfaceFlinger:
readyToRun（）
LOGI（"
SurfaceFlinger'
smainthreadreadytorun."
"
InitializinggraphicsH/W..."
//weonlysupportonedisplaycurrently
intdpy=0;
{
//initializethemaindisplay
GraphicPlane&
plane（graphicPlane（dpy））;
DisplayHardware*consthw=newDisplayHardware（this,dpy）;
plane.setDisplayHardware（hw）;
这段代码首先创建了一个DisplayHardware对象hw，用来描述设备的显示屏，并且用这个DisplayHardware对象来初始化
SurfaceFlinger类的成员变量mGraphicPlanes所描述的一个GraphicPlane数组的第一个元素。
在DisplayHardware对象hw的创建过程中，会创建
另外一个线程，用来监控控制台事件，即监控硬件帧缓冲区的睡眠和唤醒事件。
在后面一篇文章中介绍SurfaceFlinger服务是如何管理硬件帧
缓冲区时，我们就会看到这个控制台事件监控线程的创建过程。
我们接着往下阅读代码：
//createthesharedcontrol-block
mServerHeap=newMemoryHeapBase（4096,
MemoryHeapBase:
READ_ONLY,"
SurfaceFlingerread-onlyheap"
LOGE_IF（mServerHeap==0,"
can'
tcreatesharedmemorydealer"
mServerCblk=static_cast<
surface_flinger_cblk_t*>
（mServerHeap->
getBase（））;
LOGE_IF（mServerCblk==0,"
tgettosharedcontrolblock'
saddress"
new（mServerCblk）surface_flinger_cblk_t;
这段代码首先创建了一块大小为4096，即4KB的匿名共享内存，接着将这块匿名共享内存结构化为一个surface_flinger_cblk_t对象来
访问。
这个surface_flinger_cblk_t对象就保存在SurfaceFlinger类的成员变量mServerCblk中。
这块匿名共享内存用来保存设备显示屏的属性信息，例如，宽度、高度、密度和每秒多少帧等信息，后面我们就会看到这块匿名共享内
存的初始化过程。
为什么会使用匿名共享内存来保存设备显示屏的属性信息呢？
这是为了方便将这些信息传递给系统中的其它进程访问的。
系
统中的其它进程可以通过调用调用SurfaceFlinger服务的代理对象的成员函数getCblk来获得这块匿名共享内存的内容。
我们再接着往下阅读代码：
//initializeprimaryreen
//（otherdisplayshouldbeinitializedinthesamemanner,but
//asynchronously,astheycouldcomeandgo.Noneofthisissupported
//yet）.
constGraphicPlane&
constDisplayHardware&
hw=plane.displayHardware（）;
constuint32_tw=hw.getWidth（）;
constuint32_th=hw.getHeight（）;
constuint32_tf=hw.getFormat（）;
hw.makeCurrent（）;
这段代码首先获得SurfaceFlinger类的成员变量mGraphicPlan
升级会员 