4.2　zygote分析

zygote本身是一个Native的应用程序，与驱动、内核等均无关系。根据第3章对init的介绍我们可以知道，zygote是由init进程根据init.rc文件中的配置项创建的。在分析它之前，我们有必要先简单介绍一下“zygote”这个名字的来历。zygote最初的名字叫“app_process”，这个名字是在Android.mk文件中指定的，但在运行过程中，app_process通过Linux下的pctrl系统调用将自己的名字换成了“zygote”，所以我们通过ps命令看到的进程名是“zygote”。

zygote玩的这一套“换名把戏”并不影响我们的分析，它的原型app_process所对应的源文件是App_main.cpp，代码如下所示：

[—＞App_main.cpp]

int main（int argc,const char*const argv[]）

{

/*

zygote进程由init通过fork而来，我们回顾一下init.rc中设置的启动参数：

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

*/

mArgC=argc；

mArgV=argv；

mArgLen=0；

for（int i=0；i＜argc；i++）{

mArgLen+=strlen（argv[i]）+1；

}

mArgLen—；

AppRuntime runtime；

//调用Appruntime的addVmArguments，这个函数很简单，读者可以自行分析。

int i=runtime.addVmArguments（argc,argv）；

if（i＜argc）{

//设置runtime的mParentDir为/system/bin。

runtime.mParentDir=argv[i++]；

}

if（i＜argc）{

arg=argv[i++]；

if（0==strcmp（"—zygote"，arg））{

//我们传入的参数满足if的条件，而且下面的startSystemServer的值为true。

bool startSystemServer=（i＜argc）?

strcmp（argv[i]，"—start-system-server"）==0：false；

setArgv0（argv0，"zygote"）；

//设置本进程的名称为zygote，这正是前文所讲的“换名把戏”。

set_process_name（"zygote"）；

//①调用runtime的start，注意第二个参数startSystemServer为true。

runtime.start（"com.android.internal.os.ZygoteInit"，

startSystemServer）；

}

……

}

……

}

zygote的这个main函数虽然很简单，但其重要功能却是由AppRuntime的start来完成的。下面，我们就来具体分析这个AppRuntime。

4.2.1　AppRuntime分析

AppRuntime类的声明和实现均在App_main.cpp中，它是从AndroidRuntime类派生出来的，图4-1显示了这两个类的关系和一些重要函数。

由图4-1我们可知：

AppRuntime重载了onStarted、onZygoteInit和onExit函数。

前面的代码调用了AndroidRuntime的start函数，由图4-1可知，这个start函数使用的是基类AndroidRuntime的start，我们来分析一下它，注意它的调用参数。

4.2　zygote分析 - 图1

图　4-1　AppRuntime和AndroidRuntime的关系

[—＞AndroidRuntime.cpp]

void AndroidRuntime：start（const char*className,const bool startSystemServer）

{

//className的值是"com.android.internal.os.ZygoteInit"。

//startSystemServer的值是true。

char*slashClassName=NULL；

char*cp；

JNIEnv*env；

blockSigpipe（）；//处理SIGPIPE信号。

……

const char*rootDir=getenv（"ANDROID_ROOT"）；

if（rootDir==NULL）{

//如果环境变量中没有ANDROID_ROOT，则新增该变量，并设置值为“/system"。

rootDir=“/system"；

……

setenv（"ANDROID_ROOT"，rootDir，1）；

}

//①创建虚拟机

if（startVm（&mJavaVM，&env）！=0）

goto bail；

//②注册JNI函数

if（startReg（env）＜0）{

goto bail；

}

jclass stringClass；

jobjectArray strArray；

jstring classNameStr；

jstring startSystemServerStr；

stringClass=env-＞FindClass（"java/lang/String"）；

//创建一个有两个元素的String数组，即Java代码String strArray[]=new String[2]。

strArray=env-＞NewObjectArray（2，stringClass,NULL）；

classNameStr=env-＞NewStringUTF（className）；

//设置第一个元素为"com.android.internal.os.ZygoteInit"。

env-＞SetObjectArrayElement（strArray，0，classNameStr）；

startSystemServerStr=env-＞NewStringUTF（startSystemServer?"true"："false"）；

//设置第二个元素为"true"，注意这两个元素都是String类型，即字符串。

env-＞SetObjectArrayElement（strArray，1，startSystemServerStr）；

jclass startClass；

jmethodID startMeth；

slashClassName=strdup（className）；

/*

将字符串“com.android.internal.os.ZygoteInit”中的“.”换成“/”，这样就变成了“com/android/internal/os/ZygoteInit”，这个名字符合JNI规范，我们可将其简称为ZygoteInit类。

*/

for（cp=slashClassName；*cp！='\0'；cp++）

if（*cp=='.'）

*cp='/'；

startClass=env-＞FindClass（slashClassName）；

……

//找到ZygoteInit类的static main函数的jMethodId。

startMeth=env-＞GetStaticMethodID（startClass，"main"，

"（[Ljava/lang/String；）V"）；

……

/*

③通过JNI调用Java函数，注意调用的函数是main，所属的类是com.android.internal.os.ZygoteInit，传递的参数是“com.android.internal.os.ZygoteInit true”，在调用ZygoteInit的main函数后，zygote便进入了Java世界！也就是说，zygote是开创Android系统中Java世界的盘古。

*/

env-＞CallStaticVoidMethod（startClass,startMeth,strArray）；

//zygote退出，在正常情况下，zygote不需要退出。

if（mJavaVM-＞DetachCurrentThread（）！=JNI_OK）

LOGW（"Warning：unable to detach main thread\n"）；

if（mJavaVM-＞DestroyJavaVM（）！=0）

LOGW（"Warning：VM did not shut down cleanly\n"）；

bail：

free（slashClassName）；

}

通过上面的分析，我们找到了三个关键点（见代码中的①、②、③），它们共同组成了开创Android系统中Java世界的三部曲。现在让我们来具体地观察它们。

1.创建虚拟机————startVm

我们先看三部曲中的第一部：startVm，这个函数没有特别之处，就是调用JNI的虚拟机创建函数，但是创建虚拟机时的一些参数却是在startVm中确定的，其代码如下所示：

[—＞AndroidRuntime.cpp]

int AndroidRuntime：startVm（JavaVMpJavaVM,JNIEnvpEnv）

{

//这个函数绝大部分代码都是设置虚拟机的参数，我们只分析其中的两个。

/*

下面的代码是用来设置JNI check选项的。JNI check指的是Native层调用JNI函数时，系统所做的一些检查工作。例如，调用NewUTFString函数时，系统会检查传入的字符串是不是符合UTF-8的要求。JNI check还能检查资源是否被正确释放。但这个选项也有副作用，比如：

1）因为检查工作比较耗时，所以会影响系统运行速度。

2）有些检查过于严格，例如上面的字符串检查，一旦出错，则调用进程就会abort。

所以，JNI check选项一般只在调试的eng版设置，在正式发布的user版中则不设置该选项了。

下面这几句代码就控制着是否启用JNI check，这是由系统属性决定的，eng版如经过特殊配置，也可以去掉JNI check。

*/

property_get（"dalvik.vm.checkjni"，propBuf，""）；

if（strcmp（propBuf，"true"）==0）{

checkJni=true；

}else if（strcmp（propBuf，"false"）！=0）{

property_get（"ro.kernel.android.checkjni"，propBuf，""）；

if（propBuf[0]=='1'）{

checkJni=true；

}

}

……

/*

设置虚拟机的heapsize，默认为16MB。绝大多数厂商都会修改这个值，一般是32MB。heapsize不能设置得过小，否则在操作大尺寸的图片时无法分配所需内存。

这里有一个问题，即heapsize既然是系统级的属性，那么能否根据不同应用程序的需求来进行动态调整呢？我开始也考虑过能否实现这一构想，不过希望很快就破灭了。对这一问题，我们将在本章的拓展内容中深入讨论。

*/

strcpy（heapsizeOptsBuf，"-Xmx"）；

property_get（"dalvik.vm.heapsize"，heapsizeOptsBuf+4，"16m"）；

opt.optionString=heapsizeOptsBuf；

mOptions.add（opt）；

if（checkJni）{

opt.optionString="-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）{

LOGE（"JNI_CreateJavaVM failed\n"）；

goto bail；

}

result=0；

bail：

free（stackTraceFile）；

return result；

}

关于dalvik虚拟机的详细参数，读者可以参见Dalvik/Docs/Dexopt.html中的说明。这个Docs目录下的内容，或许可帮助我们更深入地了解dalvik虚拟机。

2.注册JNI函数——startReg

前面已经介绍了如何创建虚拟机，下一步则需要给这个虚拟机注册一些JNI函数。正是因为后续Java世界用到的一些函数是采用native方式实现的，所以才必须提前注册这些函数。

下面我们来看看这个startReg函数，代码如下所示：

[—＞AndroidRuntime.cpp]

int AndroidRuntime：startReg（JNIEnv*env）

{

//注意，设置Thread类的线程创建函数为javaCreateThreadEtc。

//它的作用将在对Thread进行分析时（第5章）详细介绍。

androidSetCreateThreadFunc（（android_create_thread_fn）javaCreateThreadEtc）；

env-＞PushLocalFrame（200）；

//注册JNI函数，gRegJNI是一个全局数组。

if（register_jni_procs（gRegJNI,NELEM（gRegJNI），env）＜0）{

env-＞PopLocalFrame（NULL）；

return-1；

}

env-＞PopLocalFrame（NULL）；

//下面这句话应当是“码农”休闲时的小把戏。在日新月异的IT世界中，它现在绝对是“文物”了。

//createJavaThread（"fubar"，quickTest，（void*）"hello"）；

return 0；

}

我们来看看register_jni_procs，代码如下所示：

[—＞AndroidRuntime.cpp]

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）{//仅仅是一个封装，调用数组元素的mProc函数return-1；

}

}

return 0；

}

上面的函数调用的不过是数组元素的mProc函数，让我们再直接看看这个全局数组的gRegJNI变量。

[—＞AndroidRuntime.cpp：gRegJNI声明]

static const RegJNIRec gRegJNI[]={

REG_JNI（register_android_debug_JNITest），

REG_JNI（register_com_android_internal_os_RuntimeInit），

REG_JNI（register_android_os_SystemClock），

REG_JNI（register_android_util_EventLog），

REG_JNI（register_android_util_Log），

……//共有100项

}；

REG_JNI是一个宏，宏里面包括的就是那个mProc函数，这里我们来分析一个例子。

[—＞android_debug_JNITest.cpp]

int register_android_debug_JNITest（JNIEnv*env）

{

//为android.debug.JNITest类注册它所需要的JNI函数。

return jniRegisterNativeMethods（env，"android/debug/JNITest"，

gMethods,NELEM（gMethods））；

}

哦，原来mProc就是为Java类注册了JNI函数！

至此，虚拟机已创建好，JNI函数也已注册，下一步就要分析CallStaticVoidMethod了。通过这个函数，我们将进入Android精心打造的Java世界，而且最佳的情况是，永远也不回到Native世界。