在前面一篇文章中,我们简要介绍了Android系统Surface机制中的SurfaceFlinger服务。SurfaceFlinger服务是在System进程中启动的,并且负责统一管理设备的帧缓冲区。SurfaceFlinger服务在启动的过程中,会创建两个线程,其中一个线程用来监控控制台事件,而另外一个线程用来渲染系统的UI。在本文中,我们就将详细分析SurfaceFlinger服务的启动过程。
从前面Android系统进程Zygote启动过程的源代码分析一文可以知道,System进程是由Zygote进程启动的,并且是以Java层的SystemServer类的静态成员函数main为入口函数的。因此,接下来我们就从SystemServer类的静态成员函数main开始,分析SurfaceFlinger服务的启动过程,如图1所示。
图1 SurfaceFlinger服务的启动过程
SurfaceFlinger服务的启动过程可以划分为8个步骤,接下来我们就详细分析每一个步骤。
Step 1. SystemServer.main
- public class SystemServer
- {
- ......
- native public static void init1(String[] args);
- public static void main(String[] args) {
- ......
- System.loadLibrary("android_servers");
- init1(args);
- }
- ......
- }
这个函数定义在文件frameworks/base/services/java/com/android/server/SystemServer.java中。
SystemServer类的静态成员函数main首先将android_servers库加载到System进程中来,接着调用另外一个静态成员函数init1来启动那些使用C++语言来实现的系统服务。
SystemServer类的静态成员函数init1是一个JNI方法,它是由C++层的函数android_server_SystemServer_init1来实现的,接下来我们就继续分析它的实现。
Step 2. SystemServer.init1
- static void android_server_SystemServer_init1(JNIEnv* env, jobject clazz)
- {
- 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_t system_init()
- {
- LOGI("Entered system_init()");
- sp<ProcessState> proc(ProcessState::self());
- ......
- char propBuf[PROPERTY_VALUE_MAX];
- property_get("system_init.startsurfaceflinger", propBuf, "1");
- if (strcmp(propBuf, "1") == 0) {
- // Start the SurfaceFlinger
- SurfaceFlinger::instantiate();
- }
- ......
- if (proc->supportsProcesses()) {
- LOGI("System server: entering thread pool.\n");
- ProcessState::self()->startThreadPool();
- IPCThreadState::self()->joinThreadPool();
- LOGI("System server: exiting thread pool.\n");
- }
- return NO_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线程池中去。从前面Android系统进程Zygote启动过程的源代码分析和Android应用程序进程启动过程的源代码分析两篇文章可以知道,System进程前面在初始化运行时库的过程中,已经调用过当前进程中的ProcessState单例的成员函数startThreadPool来启动Binder线程池了,因此,这里其实只是将当前线程加入到这个Binder线程池中去。有了这个Binder线程池之后,SurfaceFlinger服务在启动完成之后,就可以为系统中的其他组件或者进程提供服务了。
假设系统存在一个名称为“system_init.startsurfaceflinger”的属性,并且它的值等于“1”,接下来我们就继续分析SurfaceFlinger类的静态成员函数instantiate的实现,以便可以了解SurfaceFlinger服务的启动过程。由于SurfaceFlinger类的静态成员函数instantiate是从父类BinderService继承下来的,因此,接下来我们要分析的实际上是BinderService类的静态成员函数instantiate的实现。
Step 3. BinderService.instantiate
- template<typename SERVICE>
- class BinderService
- {
- public:
- ......
- static void instantiate() { publish(); }
- ......
- };
这个函数定义在文件frameworks/base/include/binder/BinderService.h中。
BinderService类的静态成员函数instantiate的实现很简单,它只是调用BinderService类的另外一个静态成员函数publish来继续执行启动SurfaceFlinger服务的操作。
Step 4. BinderService.publish
- template<typename SERVICE>
- class BinderService
- {
- public:
- static status_t publish() {
- sp<IServiceManager> sm(defaultServiceManager());
- return sm->addService(String16(SERVICE::getServiceName()), new SERVICE());
- }
- ......
- };
这个函数定义在文件frameworks/base/include/binder/BinderService.h中。
BinderService是一个模板类,它有一个模板参数SERVICE。当BinderService类被SurfaceFlinger类继承时,模板参数SERVICE的值就等于SurfaceFlinger。因此,BinderService类的静态成员函数publish所执行的操作就是创建一个SurfaceFlinger实例,用来作为系统的SurfaceFlinger服务,并且将这个服务注册到Service Manager中去,这样系统中的其它组件或者进程就可以通过Service Manager来获得SurfaceFlinger服务的Binder代理对象,进而使用它所提供的服务。Binder进程间通信机制中的服务对象的注册过程可以参考Android系统进程间通信(IPC)机制Binder中的Server启动过程源代码分析一文。
接下来,我们就继续分析SurfaceFlinger服务的创建过程。
Step 5. new SurfaceFlinger
- SurfaceFlinger::SurfaceFlinger()
- : BnSurfaceComposer(), Thread(false),
- ......
- {
- init();
- }
这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。
从前面Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划一文可以知道,SurfaceFlinger类继承了BnSurfaceComposer类,而后者是一个实现了ISurfaceComposer接口的Binder本地对象类。此外,SurfaceFlinger类还继承了Thread类,后者是用来创建一个线程的,这个线程就是我们在Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划一文中提到的UI渲染线程,它的线程执行体函数为SurfaceFlinger类的成员函数threadLoop。后面在分析SurfaceFlinger服务渲染UI的过程时,我们再分析SurfaceFlinger类的成员函数threadLoop的实现。注意,在初始化SurfaceFlinger的父类Thread时,传进去的参数为false,表示先不要将SurfaceFlinger服务的UI渲染线程启动起来,等到后面再启动。
SurfaceFlinger服务在创建的过程中,会调用SurfaceFlinger类的成员函数init来执行初始化的操作,接下来,我们就继续分析它的实现。
Step 6. SurfaceFlinger.init
- void SurfaceFlinger::init()
- {
- LOGI("SurfaceFlinger is starting");
- // debugging stuff...
- char value[PROPERTY_VALUE_MAX];
- property_get("debug.sf.showupdates", value, "0");
- mDebugRegion = atoi(value);