SurfaceFlinger英文直译就是surface的投递者,surface就不用翻译了,翻译了反而不好理解。SurfaceFlinger是android的一个服务,其负责管理应用端的surface,将所有的surface复合。他是介于图形库和应用之间的一层。每个应用在它自己的surface完成各种图形操作后,请求SurfaceFlinger显示到屏幕,surfaceflinger就会将所有的surface叠加起来,并且反映到framebuffer. 下面是一张结构图:
zygote实际上是进程的名字,实际的可执行文件是/system/bin下的app_process. app_process的源码在frameworks/base/cmds/app_process下面。
Client表示一个surface,也可以理解为每个应用程序所使用的surface. client属于客户端,surfaceflinger属于服务端,分别属于不同的进程。他们之间通过AIDL通信。surfaceflinger不直接与framebuffer打交道,而是建立在opengl或者skia等图形库之上。opengl, skia都是平台无关的图形库,并不反应具体的图形设备的细节,gralloc.xxx.so才是对每种图形设备framebuffer的抽象,gralloc.xxx.so实现了一套标准的接口,每种具体的图形设备都有一个gralloc文件对应。对图形库而言不关心具体的细节。
在认识了surfaceflinger的作用和在android中的位置之后,再来讲讲surfaceflinger是怎么被系统启动的。先贴一张图:
简单的过程就是Init->Zygote->SystemServer->SurfaceFlinger.
Init是linux启动的第一个进程,Zygote就是由Init进程fork出来的,Zygote在android中非常重要,其负责将每个应该程序fork出一个进程。看看init.rc
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class services
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd
# Make zygote depend on av_settings.
disabled
zygote实际上是进程的名字,实际的可执行文件是/system/bin下的app_process. app_process的源码在frameworks/base/cmds/app_process下面。
-Xzygote /system/bin --zygote --start-system-server
这是对应的参数。
看看app_process的main,其中app_process/app_main.cpp中
int main(int argc, const char* const argv[])
{
...........
// Everything up to '--' or first non '-' arg goes to the vm
int i = runtime.addVmArguments(argc, argv);
// Next arg is parent directory
if (i < argc) {
runtime.mParentDir = argv[i++];
}
// Next arg is startup classname or "--zygote"
if (i < argc) {
arg =