Android系统Surface机制的SurfaceFlinger服务的启动过程分析Word下载.docx

1、 . 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+语

2、言来实现的系统服务。 SystemServer类的静态成员函数init1是一个JNI方法，它是由C+层的函数android_server_SystemServer_init1来实现的，接下来我们就继续分析它的实现。 Step 2. SystemServer.init1cpp view plain copy 在CODE上查看代码片派生到我的代码片static void android_server_SystemServer_init1（JNIEnv* env, jobject clazz） system_init（）; 这个函数定义在文件frameworks/base/services/jni/

3、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 proc（ProcessState:self（）; char propBufPROPERTY_VALUE_MAX; prope

4、rty_get（system_init.startsurfaceflinger, propBuf, 1 if （strcmp（propBuf, ） = 0） / Start the SurfaceFlinger SurfaceFlinger:instantiate（）; if （proc-supportsProcesses（） System server: entering thread pool.n ProcessState:self（）-startThreadPool（）; IPCThreadState:joinThreadPool（）; exiting thread pool.n ret

5、urn NO_ERROR; 函数首先获得System进程中的一个ProcessState单例，并且保存在变量proc中，后面会通过调用它的成员函数supportsProcesses来判断系统是否支持Binder进程间通信机制。我们知道，在Android系统中，每一个需要使用Binder进程间通信机制的进程内部都有一个ProcessState单例，它是用来和Binder驱动程序建立连接的，具体可以参考Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析一文。 函数接下来就检查系统中是否存在一个名称为“system_init.startsurfaceflinge

6、r”的属性。如果存在的话，就将它的值获取回来，并且保存在缓冲区proBuf中。如果不存在的话，那么函数property_get就会将缓冲区proBuf的值设置为“1”。当缓冲区proBuf的值等于“1”的时候，就表示需要在System进程中将SurfaceFlinger服务启动起来，这是通过调用SurfaceFlinger类的静态成员函数instantiate来实现的。 函数最后检查系统是否支持Binder进程间通信机制。如果支持的话，那么接下来就会调用当前进程中的ProcessState单例的成员函数startThreadPool来启动一个Binder线程池，并且调用当前线程中的IPCThr

7、eadState单例来将当前线程加入到前面所启动的Binder线程池中去。从前面 和 两篇文章可以知道，System进程前面在初始化运行时库的过程中，已经调用过当前进程中的ProcessState单例的成员函数startThreadPool来启动Binder线程池了，因此，这里其实只是将当前线程加入到这个Binder线程池中去。有了这个Binder线程池之后，SurfaceFlinger服务在启动完成之后，就可以为系统中的其他组件或者进程提供服务了。 假设系统存在一个名称为“system_init.startsurfaceflinger”的属性，并且它的值等于“1”，接下来我们就继续分析Sur

8、faceFlinger类的静态成员函数instantiate的实现，以便可以了解SurfaceFlinger服务的启动过程。由于SurfaceFlinger类的静态成员函数instantiate是从父类BinderService继承下来的，因此，接下来我们要分析的实际上是BinderService类的静态成员函数instantiate的实现。 Step 3. BinderService.instantiatetemplateclass BinderService public: static void instantiate（） publish（）; 这个函数定义在文件frameworks/b

9、ase/include/binder/BinderService.h中。 BinderService类的静态成员函数instantiate的实现很简单，它只是调用BinderService类的另外一个静态成员函数publish来继续执行启动SurfaceFlinger服务的操作。 Step 4. BinderService.publish static status_t publish（） IServiceManager sm（defaultServiceManager（）; return sm-addService（String16（SERVICE:getServiceName（）, new

10、 SERVICE（）; BinderService是一个模板类，它有一个模板参数SERVICE。当BinderService类被SurfaceFlinger类继承时，模板参数SERVICE的值就等于SurfaceFlinger。因此，BinderService类的静态成员函数publish所执行的操作就是创建一个SurfaceFlinger实例，用来作为系统的SurfaceFlinger服务，并且将这个服务注册到Service Manager中去，这样系统中的其它组件或者进程就可以通过Service Manager来获得SurfaceFlinger服务的Binder代理对象，进而使用它所提供的

11、服务。Binder进程间通信机制中的服务对象的注册过程可以参考Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析一文。 接下来，我们就继续分析SurfaceFlinger服务的创建过程。 Step 5. new SurfaceFlingerSurfaceFlinger:SurfaceFlinger（） : BnSurfaceComposer（）, Thread（false）, init（）; 这个函数定义在文件frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp中。 从前面 一文可以知道，Su

12、rfaceFlinger类继承了BnSurfaceComposer类，而后者是一个实现了ISurfaceComposer接口的Binder本地对象类。此外，SurfaceFlinger类还继承了Thread类，后者是用来创建一个线程的，这个线程就是我们在 一文中提到的UI渲染线程，它的线程执行体函数为SurfaceFlinger类的成员函数threadLoop。后面在分析SurfaceFlinger服务渲染UI的过程时，我们再分析SurfaceFlinger类的成员函数threadLoop的实现。注意，在初始化SurfaceFlinger的父类Thread时，传进去的参数为false，表示先不要将SurfaceFlinger服务的