Android系统启动分析(Init->Zygote->SystemServer->Home activity)

整个Android系统的启动分为Linux Kernel的启动和Android系统的启动。Linux Kernel启动起来后，然后运行第一个用户程序，在Android中就是init程序。

-------------------------------------------------

以下的内容应该算是学习笔记，特地整理成文。

-------------------------------------------------

1 init程序

init是linux系统中用户空间的第一个进程。由于Android是基于linux内核的，所以init也是Android系统中用户空间的第一个进程，它的进程号是1。init程序并不是由一个源文件组成的，而是由一组源代码文件的目标文件链接而成，这些文件位于如下目录：

<android source code directory>/system/core/init/

它的主要职责在于：

1)、挂载目录，比如/sys, /dev, /proc

mkdir("/dev", 0755);
mkdir("/proc", 0755);
mkdir("/sys", 0755);
......

2)、初始化属性，提供property service(属性服务)管理Android系统中的属性

3)、处理配置文件命令（主要是init.rc脚本文件）

4)、性能分析和执行其它进程

2.1 init分析

init进程的入口函数是main，主要做了这些工作：

1)、解析配置文件，主要是系统配置文件init.rc和与硬件平台相关的配置文件（如init.xxx.rc），在此阶段，也会解析service。

init.rc文件包含五个类型的声明：

• Actions（动作以命令流程命名，有一个触发器决定动作是否发生）

• on <trigger>
          <command>
          <command>

• Commands

• class_start <serviceclass>
      Start all services of the specified class if they are not already running

• Services（是init进程启动的程序，以及当服务退出时init进程会视情况重启服务）
• Options（选项是对服务的描述，它们影响init进程如何以及何时启动服务）

• service <name> <pathname> [ <argument> ]*
          <option>
          <option>

• Imports

• import <path>
      Parse an init config file, extending the current configuration.

Action	Service	描述
on	early-init	设置init进程以及它创建的子进程的优先级，设置init进程的安全环境
on	init	设置全局环境，为cpu accounting创建cgroup(资源控制)挂载点
on	fs	挂载mtd分区
on	post-fs	改变系统目录的访问权限
on	post-fs-data	改变/data目录以及它的子目录的访问权限
on	boot	基本网络的初始化，内存管理等等
service	servicemanager	启动系统管理器管理所有的本地服务，比如位置、音频、Shared preference等等
service	zygote	启动zygote作为应用进程

2)、执行各个阶段的动作，创建zygote的工作就是在其中某个阶段完成。

3)、调用property_init初始化属性相关的资源，并且通过property_start_service启动属性服务。

4)、init进入一个无限循环，然后等待响应。

2.2 属性服务

应用程序可以通过这个属性机制，查询或设置属性。这个属性服务是怎么实现的呢？其中与init.c和属性服务有关的代码：

property_init();
property_set_fd = start_property_service();

2.2.1 属性服务初始化

首先创建存储空间，property_service.c中有property_init函数

void property_init(void){
    init_property_area(); // 初始化属性存储区域
    // 加载default.prop文件
    load_properties_from_file(PROP_PATH_RAMDISK_DEFAULT);
}

虽然属性区域是由init进程创建的，但Android系统希望其它进程也能读取这块内存里的东西。为了做到这一点，它做了以下的工作：

1)、把属性区域创建在共享内存上，而共享内存是可以跨进程的。

2)、Android利用gcc的constructor属性，指明了一个__libc_prenit函数，当bionic libc库被加载时，将自动调用这个__libc_preni，这个函数内部就将完成共享内存到本地进程的映射工作。这样一来，其它进程就知道了这个共享内存。

接着，客户端进程获取存储空间。

2.2.2 属性服务器的分析

2.2.2.1 启动属性服务器

init进程会启动一个属性服务器，而客户端只能通过与属性服务器交互来设置属性。

2.2.2.2 处理设置属性请求

接受请求的地方在init进程中，当属性服务器收到客户端请求时，init会调用handle_property_set_fd进行处理。

if(ufds[1].revents == POLLIN){
    handle_property_set_fd(property_set_fd);
}

当客户端的权限满足要求时，init就调用property_set进行相关处理。

if(check_perms(msg.name, cr.uid, cr.gid)){
    property_set((char *) msg.name, (char *) msg.value);
}

2.2.2.3 客户端发送请求

客户端通过property_set发送请求，property_set由libcutils库提供。

int property_set(const chatr *key, const char *value){
    prop_msg msg;
    unsigned resp;
    // other code
    ......
    msg.cmd = PROP_MSG_SETPROP; // 设置消息码
    strcpy((char *) msg.name, key);
    strcpy((char *) msg.value, value);
    // 发送请求
    return send_prop_msg(&msg);
}

static int send_prop_msg(prop_msg *msg){
    int s;
    int r;
    // 建立和属性服务器的socket链接
    s = socket_local_client(PROP_SERVICE_NAME, ANDROID_SOCKET_NAMESPACE_RESERVED, SOCK_STREAM);
    if(s < 0){
        return -1;
    }
    // 通过socket发送
    while((r = send(s, msg, sizeof(prop_msg), 0)) < 0){
        if((errno == EINTR) || (errno == EAGAIN)){
            continue;
        }
        break;
    }

    if(r == sizeof(prop_msg)){
        r = 0;
    } else {
        r = -1;
    }

    close(s);
    return r;
}

2 zygote分析

zygote本身是一个Native的应用程序，与驱动、内核等无关。它是由init进程根据init.rc文件中的配置创建的。zygote最初的名字叫“app_process”，这个名字是在Android.mk文件中指定的。在运行中，app_process通过linux下的pctrl系统调用将自己的名字换成了zygote。

在Java中，我们知道不同的虚拟机实例会为不同的应用分配不同的内存。假如Android应用应该尽可能快地启动，但如果Android系统为每一个应用启动不同的Dalvik虚拟机实例，就会消耗大量的内存以及时间。因此，为了克服这个问题，Android系统创造了”zygote”。zygote让Dalvik虚拟机共享代码、低内存占用以及最小的启动时间成为可能。

zygote进程由init通过fork而来，在init.rc中设置的启动参数如下：

-Xzygote /system/bin --zygote --start-system-server

zygote的原型app_process对应的源文件是App_main.cpp。

int main(int argc, const char* const argv[]){
    ......
    AppRuntime runtime;
    ......
    int i = runtime.addVmArguments(argc, argv);
    if(i < argc){
        runtime.mParentDir = argv[i++];
    }

    if(i < argc){
        arg = argv[i++];
        if(0 == strcmp("--zygote", arg)){
            bool startSystemServer = (i < argc) ? strcmp(argv[i], "--start-system-server") == 0: false;
            setArgv0(argv0, "zygote");
            set_process_name("zygote"); // 设置进程名
            runtime.start("com.android.internal.os.ZygoteInit", startSystemServer);
        }
        ......
    }
    ......
}

2.1 AppRuntime分析

AppRuntime从AndroidRuntime类派生，它的声明和实现在App_main.cpp中。AppRuntime重载了onStarted, onZygoteInit和onExit函数。其中AndroidRuntime::start(const char* className, const bool startSystemServer)函数做了几件事情：

2.1.1 创建虚拟机--startVm

int AndroidRuntime::startVm(JavaVm** pJavaVM, JNIEnv** pEnv){
    // JNI check是指Native层调用JNI函数时，系统所做的一些检查工作。例如，调用NewUTFString函数时，系统会检查传入的字符串是不是符合UTF-8的要求。
    property_get("dalvik.vm.checkjni", propBuf, "");
    ......
    // 设置虚拟机的heapsize，默认为16MB
    strcpy(heapsizeOptsBuf, "-Xmx");
    property_get("dalvik.vm.heapsize", heapsizeOptsBuf + 4, "16m");
    ......
    if(checkJni){
        opt.optionsString = "-Xcheck:jni";
        mOptions.add(opt);
        // JNI check中的资源检查，系统中创建的Global Reference个数不能超过2000
        opt.optionString = "-Xjnigreflimit:2000";
        mOptions.add(opt);
    }

    // 调用JNI_CreateJavaVM创建虚拟机，pEnv返回当前线程的JNIEnv变量
    if(JNI_CreateJavaVM(pJavaVM, pEnv, &initArgs) < 0){
        goto bail;
    }

    return 0;

bail:
    free(stackTraceFile);
    return result;
}

2.1.2 注册JNI函数--startReg

int AndroidRuntime::startReg(JNIEnv* env){
    ......
    if(register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0){
        env->PopLocalFrame(NULL);
        return -1;
    }
    env->PopLocalFrame(NULL);
    return 0;
}

static int register_jni_procs(const RegJNIRec array[], size_t count, JNIEnv* env){
    for(size_t i = 0; i < count; i++){
        if(array[i].mProc(env) < 0){
            return -1;
        }
    }
    return 0;
}

statci const RegJNIRec gRegJNI[] = {
    REG_JNI(register_android_debug_JNITest),
    REG_JNI(register_com_android_internal_os_RuntimeInit),
    REG_JNI(register_android_os_SystemClock),
    ......
}

上面的mProc就是为Java类注册JNI函数。

2.1.3 通过JNI调用Java函数，进入Java世界

env->CallStaticVoidMethod(startClass, startMeth, strArray);

CallStaticVoidMethod最终将调用com.android.internal.os.ZygoteInit的main函数。

public static void main(String argv[]){
    try{
        SamplingProfilerIntegration.start();
        // 1. 注册zygote用的socket. 基于AF_UNIX类型，是一个本机socket
        registerZygoteSocket();
        // 2. 预加载类和资源
        preloadClasses();
        preloadResources();
        ......
        // 强制执行一次垃圾回收
        gc();

        if(argv[1].equals("true")){
            startSystemServer(); // 3. 启动system_server进程。该进程是framework的核心。
        } else if(!argv[1].equals("false")){
            throw new RuntimeException(argv[0] + USAGE_STRING);
        }

        if(ZYGOTE_FORK_MODE){
            runForkMode();
        } else {
            runSelectLoopMode(); // 4. zygote调用这个函数，进入等待唤醒的状态
        }
        closeServerSocket();
    } catch(MethodAndArgsCaller caller){
        caller.run();
    } catch(RuntimeException ex){
        closeServerSocket();
        throw ex;
    }
    ......
}

3 SystemServer分析

SystemServer是由Zygote通过Zygote.forkSystemServer函数fork出来的。

pid = Zygote.forkSystemServer();
if(pid == 0){ // 子进程返回0，即systemServer
    handleSystemServerProcess(parseArgs);
}

在handleSystemServerProcess函数中，首先会关闭从Zygote继承下来的socket，并设置SystemServer进程的一些参数，然后调用RuntimeInit.java中的ZygoteInit函数。

public static final void zygoteInit(String[] argv) throws ZygoteInit.MethodAndArgsCaller {
    commonInit();
    // native层的初始化
    zygoteInitNative();
    ......
    invokeStaticMain(startClass, startArgs); // 调用com.android.server.SystemServer类的main函数
}

SystemServer调用了zygoteInitNative后，将与Binder通信系统建立联系，这样SystemServer就可以使用Binder了。zygoteInitNative中调用了onZygoteInit()

virtual void onZygoteInit(){
    sp proc = ProcessState::self();
    if(proc->supportsProcesses()){
        proc->startThreadPool(); // 启动一个线程，用于Binder通信
    }
}

而另外一个关键函数invokeStaticMain

private static void invokeStaticMain(String className, String[] argv) throws ZygoteInit.MethodAndArgsCaller {
    // 参数传入，className = "com.android.server.SystemServer"
    ......
    Method m;
    try{
        m = cl.getMethod("main", new Class[] { String[].class }); // 找到com.android.server.SystemServer类的main函数
    } catch(NoSuchMethodException ex){
        ......
    } catch(SecurityException ex){
        ......
    }

    ......
    throw new ZygoteInit.MethodAndArgsCaller(m, argv); // 主动抛出一个异常
}

抛出的异常在哪里被捕获呢？上面已经给出过了。也就是在ZygoteInit.java中

......
catch(MethodAndArgsCaller caller){
    caller.run(); // 调用caller的run函数
}

而MethodAndArgsCaller的run函数如下：

public void run(){
    try{
        mMethod.invoke(null, new Object[] { mArgs }); // mMethod为com.android.server.SystemServer的main函数
    } catch(IllegalAccessException ex){
        ......
    }
}

为什么要主动抛出这样一个异常来执行main函数呢？

《深入理解Android 卷I》中是这样解释的：这个调用是在ZygoteInit.main中，相当于Native的main函数，也即入口函数，位于堆栈的顶层。如果不采用抛异常的方式，而是在invokeStaticMain那调用，则会浪费之前函数调用所占用的一些调用堆栈。

那么，这个main函数又做了什么工作呢？

public static void main(String[] args){
    System.loadLibrary("android_servers"); // 加载libandroid_servers.so
    init1(args); // 调用native的init1函数
}

其中init1函数创建了一些系统服务，然后把调用线程加入到Binder通信中。期间还通过JNI调用了com.android.server.SystemServer类的init2函数，通过单独创建一个线程，用以启动系统的各项服务，如PowerManagerService, BatteryService, WindowManagerService, ActivityManagerService等。

public static final void init2(){
    Slog.i(TAG, "Entered the Android system server!");
    Thread thr = new ServerThread();
    thr.setName("android.server.ServerThread");
    thr.start();
}

这个函数的主要功能是创建新的线程ServerThread，它的override的run方法在SystemServer.java中，主要做了以下一些工作：

private void run() {
    ......
    // Initialize native services.
    System.loadLibrary("android_servers");
    ......
    // Initialize the system context.
    createSystemContext();
    ......
    startCoreServices();
    startOtherServices();
    ......
}

/**
 * Starts some essential services that are not tangled up in the bootstrap process.
 */
private void startCoreServices() {
    // Tracks the battery level.  Requires LightService.
    mSystemServiceManager.startService(BatteryService.class);

    // Tracks application usage stats.
    mSystemServiceManager.startService(UsageStatsService.class);
    mActivityManagerService.setUsageStatsManager(
            LocalServices.getService(UsageStatsManagerInternal.class));
    // Update after UsageStatsService is available, needed before performBootDexOpt.
    mPackageManagerService.getUsageStatsIfNoPackageUsageInfo();

    // Tracks whether the updatable WebView is in a ready state and watches for update installs.
    mSystemServiceManager.startService(WebViewUpdateService.class);
}

/**
 * Starts a miscellaneous grab bag of stuff that has yet to be refactored
 * and organized.
 */
private void startOtherServices() {
    ......
    try {
        Slog.i(TAG, "Reading configuration...");
        SystemConfig.getInstance();

        traceBeginAndSlog("StartSchedulingPolicyService");
        ServiceManager.addService("scheduling_policy", new SchedulingPolicyService());
        Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);

        mSystemServiceManager.startService(TelecomLoaderService.class);

        traceBeginAndSlog("StartTelephonyRegistry");
        telephonyRegistry = new TelephonyRegistry(context);
        ServiceManager.addService("telephony.registry", telephonyRegistry);
        Trace.traceEnd(Trace.TRACE_TAG_SYSTEM_SERVER);
        ......
    }
    ......
}

至此，让我们总结一下SystemServer

1)、ZygoteInit调用startSystemServer创建system_server进程。

2)、SystemServer调用handleSystemServerProcess完成自己的使命。

3)、handleSystemServerProcess抛出异常，最终调用com.android.server.SystemServer的main函数。

4)、main函数加载libandroid_server.so并调用native的init1函数。

5)、init1函数通过JNI调用com.android.server.SystemServer类的init2函数。init2函数创建一个线程，用于加载各种service。

6)、init1函数最终加入到Binder通信系统。 

4 Zygote的分裂

zygote分裂出system_server后，就等待runSelectLoopMode等待并处理来自客户的请求。那么，谁会向zygote发送消息呢？这里以一个activity的启动为例作分析。

4.1 ActivityManagerService发送请求

ActivityManagerService由SystemServer创建。假设通过startActivity来启动一个新的acitivity，而这个activity属于一个还未启动的进程，那么这个进程又如何启动呢？先看ActivityManagerService中的startProcessLocked函数

private final void startProcessLocked(ProcessRecord app, String hostingType, String hostingNameStr){
    ......
    int pid = Process.start("android.app.ActivityThread", mSimpleProcessManagement ? app.processName : null, uid, uid, gids, debugFlags, null);
    ......
}

Process.start位于android.os.Process中，而它又调用了startViaZygote, zygoteSendArgsAndGetPid。而在zygoteSendArgsAndGetPid中，首先打开了和zygote通信的socket，接着把请求的参数发到zygote，然后读取zygote处理完的结果，得知是某个进程的pid。

由于ActivityManagerService驻留于SystemServer进程中，所以正是SystemServer向Zygote发送了消息。

还记得前面提过的runSelectLoopMode函数么？它在里面又调用了ZygoteConnection的runOnce

boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {
    try{
        args = readArgumentList(); // 读取SystemServer发送过来的参数
        descriptors = mSocket.getAncillaryFileDescriptors();
    } 

    ......

    pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid, parsedArgs.gids, parsedArgs.debugFlags, rlimits);
    ......
    if(pid ==0){
        handleClientProc(parsedArgs, descriptors, newStderr); //子进程处理
        return true;
    } else {
        return handleParentProc(pid, descriptors, parsedArgs);
    }
}

由此可见，zygote分裂子进程后，自己将在handleParentProc中做一些扫尾工作，然后继续等待请求进行下一次分裂。

4.2 zygote响应请求的流程

1)、Zygote进程调用runSelectLoopMode

2)、SystemServer进程发送消息到Zygote

3)、Zygote通过fork创建子进程

4)、子进程调用android.app.ActivityThread的main函数

5 Home界面启动

待Application Framework层的ActivityManagerService准备就绪后，就会通知各个模块，继续执行上层应用。

先附一张体系结构图：

    // We now tell the activity manager it is okay to run third party
    // code.  It will call back into us once it has gotten to the state
    // where third party code can really run (but before it has actually
    // started launching the initial applications), for us to complete our
    // initialization.
    mActivityManagerService.systemReady(new Runnable() {
        @Override
        public void run() {
            Slog.i(TAG, "Making services ready");
            ......
            try {
                mActivityManagerService.startObservingNativeCrashes();
            } catch (Throwable e) {
                reportWtf("observing native crashes", e);
            }
            ......
            try {
                if (networkScoreF != null) networkScoreF.systemReady();
            } catch (Throwable e) {
                reportWtf("making Network Score Service ready", e);
            }
            ......
            try {
                if (networkManagementF != null) networkManagementF.systemReady();
            } catch (Throwable e) {
                reportWtf("making Network Managment Service ready", e);
            }
            ......
            try {
                if (networkStatsF != null) networkStatsF.systemReady();
            } catch (Throwable e) {
                reportWtf("making Network Stats Service ready", e);
            }
            ......
            try {
                if (networkPolicyF != null) networkPolicyF.systemReady();
            } catch (Throwable e) {
                reportWtf("making Network Policy Service ready", e);
            }
            ......
            try {
                if (connectivityF != null) connectivityF.systemReady();
            } catch (Throwable e) {
                reportWtf("making Connectivity Service ready", e);
            }
            ......
            try {
                if (audioServiceF != null) audioServiceF.systemReady();
            } catch (Throwable e) {
                reportWtf("Notifying AudioService running", e);
            }
            ......
        }
    });      

public void systemReady(final Runnable goingCallback) {
    ......
    // Start up initial activity.
    mBooting = true;
    startHomeActivityLocked(mCurrentUserId, "systemReady");
    ......
}

这样一来，就启动了Home界面，完成了整个Android启动流程。

下面是启动流程图：

 

参考：

《深入理解Android 卷I》 邓凡平 著

Android启动过程深入解析

Android系统启动过程

转载于:https://www.cnblogs.com/lao-liang/p/5067312.html