android 4.04的应用程序启动过程及与Zygote的交互（基于静态源码分析）

　　话不多说我们直接切入主题。关于android，我们都知道的是应用程序是由activity构成的。而一个应用程序的具体启动过程，很少有人关心过，下面我们就对一个应用程序的启动过程开始分析。

　　在android中，应用程序的入口是ActivityThead中的main函数。

　　activity 的startActivity最终是在ActivityManagerService中调用。

　　Android应用程序框架层中，ActivityManagerService组件负责为Android应用程序创建新的进程的，它本来也是运行在一个独立的进程之中，不过这个进程是在系统启动的过程中创建的。

　　当系统决定要在一个新的进程中启动一个Activity或者Service时，它就会创建一个新的进程了，然后在这个新的进程中启动这个Activity或者Service。

ActivityManagerService启动新的进程是从其成员函数startProcessLocked开始.

ActivityManagerService.startProcessLocked定义在

/frameworks/base/services/java/com/android/server/am/ActivityManagerService.java

 public final class ActivityManagerService extends ActivityManagerNative implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {

}

调用 Process.start 开始为应用程序创建进程，"android.app.ActivityThread"为进程初始化时加载的Java类，把这个类加载到进程之后，把它里面的main作为进程的入口。

Process.start 定义在

$android/frameworks/base/core/java/android/os/Process.java 文件中：

下面进入startViaZygote函数。

       这个函数定义在frameworks/base/core/java/android/os/Process.java文件中：

view plain

这个函数主要是对argsForZygote进行设置，然后调用zygoteSendArgsAndGetResult函数。

sZygoteWriter是一个Socket写入流，是由openZygoteSocketIfNeeded函数打开的。

Socket由frameworks/base/core/java/com/android/internal/os/ZygoteInit.java文件中的ZygoteInit类在runSelectLoopMode函数侦听。

 

ZygoteInit.runSelectLoopMode

函数定义在frameworks/base/core/java/com/android/internal/os/ZygoteInit.java文件中：

创建进程的语句：

pid = Zygote.forkAndSpecialize(parsedArgs.uid, parsedArgs.gid,

                    parsedArgs.gids, parsedArgs.debugFlags, rlimits,

                    parsedArgs.seInfo, parsedArgs.niceName);

接着：

在子进程中调用handleChildProc函数，这个函数定义在frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java文件中：

又调用了zygoteInitNative.

RuntimeInit.zygoteInitNative函数定义在frameworks/base/core/java/com/android/internal/os/RuntimeInit.java文件中：

转到定义处为：

  private static final native void nativeZygoteInit();

 

函数zygoteInitNative是一个Native函数，实现在frameworks/base/core/jni/AndroidRuntime.cpp文件中：

这里它调用了全局变量gCurRuntime的onZygoteInit函数，这个全局变量的定义在

frameworks/base/core/jni/AndroidRuntime.cpp文件开头的地方：

static AndroidRuntime* gCurRuntime = NULL;

它的类型为AndroidRuntime，它是在AndroidRuntime类的构造函数中初始化的，AndroidRuntime类的构造函数也是定义在frameworks/base/core/jni/AndroidRuntime.cpp文件中：

AndroidRuntime类的声明在frameworks/base/include/android_runtime/AndroidRuntime.h文件中

打开这个文件会看到，它是一个虚拟类，也就是我们不能直接创建一个AndroidRuntime对象，只能用一个AndroidRuntime类的指针来指向它的某一个子类，这个子类就是AppRuntime了，它定义在frameworks/base/cmds/app_process/app_main.cpp文件中：

AppRuntime类继承了AndroidRuntime类

接着一步步的查找，下面一部分就没没有基于源码了，

 

 

所以com_android_internal_os_RuntimeInit_zygoteInit函数，实际是执行了AppRuntime类的onZygoteInit函数。

AppRuntime.onZygoteInit

        这个函数定义在frameworks/base/cmds/app_process/app_main.cpp文件中：

调用ProcessState::startThreadPool启动线程池了，这个线程池中的线程就是用来和Binder驱动程序进行交互的了。

 

 

回到RuntimeInit.zygoteInit函数中在调用完zygoteInitNative后会调用applicationInit

接着调用RuntimeInit.invokeStaticMain

        这个函数定义在frameworks/base/core/java/com/android/internal/os/RuntimeInit.java文件中：

这个cl = Class.forName(className); 会调用类加载器传进来的参数className字符串值为"android.app.ActivityThread"把它加载到进程中

然后获得它的静态成员函数main：

m = cl.getMethod("main", new Class[] { String[].class });

 

函数最后并没有直接调用这个静态成员函数main，而是通过抛出一个异常ZygoteInit.MethodAndArgsCaller，然后让ZygoteInit.main函数在捕获这个异常的时候再调用android.app.ActivityThread类的main函数。  //在注释里面有说这么做是为了清理堆栈。

 

这样就会让android.app.ActivityThread类的main函数觉得自己是进程的入口函数，而事实上，在执行android.app.ActivityThread类的main函数之前，已经做了大量的工作了。

它执行MethodAndArgsCaller的run函数：

执行         mMethod.invoke(null, new Object[] { mArgs });

android.app.ActivityThread类的main函数就被执行了。

ActivityThread.main

        之后就进入消息循环了，在进程中启动Activity或者Service