AppRuntime类的声明和实现均在App_main.cpp中,它是从AndroidRuntime类派生出来的,图4-1显示了这两个类的关系和一些重要函数:
:-: ![](http://img.blog.csdn.net/20150802153752007?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
图4-1 AppRuntime和AndroidRuntime的关系
由上图我们可知:
- AppRuntime重载了onStarted、onZygoteInit和onExit函数。
前面的代码中调用了AndroidRuntime的start函数,由图4-1可知,这个start函数使用的是基类AndroidRuntime的start,我们来分析一下它,注意它的调用参数。
**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信号
......
constchar* 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;
}
jclassstringClass;
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);
jclassstartClass;
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(JavaVM** pJavaVM,JNIEnv** pEnv)
{
//这个函数绝大部分代码都是设置虚拟机的参数,我们只分析其中的两个。
/*
下面的代码是用来设置JNI check选项的。JNIcheck 指的是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;
} elseif (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);
//JNIcheck中的资源检查,系统中创建的Globalreference个数不能超过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);
returnresult;
}
~~~
关于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");
return0;
}
~~~
我们来看看register_jni_procs,代码如下所示:
**AndroidRuntime.cpp**
~~~
static int register_jni_procs(const RegJNIRecarray[], 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函数
returnjniRegisterNativeMethods(env, "android/debug/JNITest",
gMethods,NELEM(gMethods));
}
~~~
哦,原来mProc就是为Java类注册JNI函数!
至此,虚拟机已创建好,JNI函数也已注册,下一步就要分析CallStaticVoidMethod了。通过这个函数,我们将进入Android所精心打造的Java世界,而且最佳情况是,永远也不回到Native世界。
- 前言
- 第1章 阅读前的准备工作
- 1.1 系统架构
- 1.1.1 Android系统架构
- 1.1.2 本书的架构
- 1.2 搭建开发环境
- 1.2.1 下载源码
- 1.2.2 编译源码
- 1.3 工具介绍
- 1.3.1 Source Insight介绍
- 1.3.2 Busybox的使用
- 1.4 本章小结
- 第2章 深入理解JNI
- 2.1 JNI概述
- 2.2 学习JNI的实例:MediaScanner
- 2.3 Java层的MediaScanner分析
- 2.3.1 加载JNI库
- 2.3.2 Java的native函数和总结
- 2.4 JNI层MediaScanner的分析
- 2.4.1 注册JNI函数
- 2.4.2 数据类型转换
- 2.4.3 JNIEnv介绍
- 2.4.4 通过JNIEnv操作jobject
- 2.4.5 jstring介绍
- 2.4.6 JNI类型签名介绍
- 2.4.7 垃圾回收
- 2.4.8 JNI中的异常处理
- 2.5 本章小结
- 第3章 深入理解init
- 3.1 概述
- 3.2 init分析
- 3.2.1 解析配置文件
- 3.2.2 解析service
- 3.2.3 init控制service
- 3.2.4 属性服务
- 3.3 本章小结
- 第4章 深入理解zygote
- 4.1 概述
- 4.2 zygote分析
- 4.2.1 AppRuntime分析
- 4.2.2 Welcome to Java World
- 4.2.3 关于zygote的总结
- 4.3 SystemServer分析
- 4.3.1 SystemServer的诞生
- 4.3.2 SystemServer的重要使命
- 4.3.3 关于 SystemServer的总结
- 4.4 zygote的分裂
- 4.4.1 ActivityManagerService发送请求
- 4.4.2 有求必应之响应请求
- 4.4.3 关于zygote分裂的总结
- 4.5 拓展思考
- 4.5.1 虚拟机heapsize的限制
- 4.5.2 开机速度优化
- 4.5.3 Watchdog分析
- 4.6 本章小结
- 第5章 深入理解常见类
- 5.1 概述
- 5.2 以“三板斧”揭秘RefBase、sp和wp
- 5.2.1 第一板斧--初识影子对象
- 5.2.2 第二板斧--由弱生强
- 5.2.3 第三板斧--破解生死魔咒
- 5.2.4 轻量级的引用计数控制类LightRefBase
- 5.2.5 题外话-三板斧的来历
- 5.3 Thread类及常用同步类分析
- 5.3.1 一个变量引发的思考
- 5.3.2 常用同步类
- 5.4 Looper和Handler类分析
- 5.4.1 Looper类分析
- 5.4.2 Handler分析
- 5.4.3 Looper和Handler的同步关系
- 5.4.4 HandlerThread介绍
- 5.5 本章小结
- 第6章 深入理解Binder
- 6.1 概述
- 6.2 庖丁解MediaServer
- 6.2.1 MediaServer的入口函数
- 6.2.2 独一无二的ProcessState
- 6.2.3 时空穿越魔术-defaultServiceManager
- 6.2.4 注册MediaPlayerService
- 6.2.5 秋风扫落叶-StartThread Pool和join Thread Pool分析
- 6.2.6 你彻底明白了吗
- 6.3 服务总管ServiceManager
- 6.3.1 ServiceManager的原理
- 6.3.2 服务的注册
- 6.3.3 ServiceManager存在的意义
- 6.4 MediaPlayerService和它的Client
- 6.4.1 查询ServiceManager
- 6.4.2 子承父业
- 6.5 拓展思考
- 6.5.1 Binder和线程的关系
- 6.5.2 有人情味的讣告
- 6.5.3 匿名Service
- 6.6 学以致用
- 6.6.1 纯Native的Service
- 6.6.2 扶得起的“阿斗”(aidl)
- 6.7 本章小结
- 第7章 深入理解Audio系统
- 7.1 概述
- 7.2 AudioTrack的破解
- 7.2.1 用例介绍
- 7.2.2 AudioTrack(Java空间)分析
- 7.2.3 AudioTrack(Native空间)分析
- 7.2.4 关于AudioTrack的总结
- 7.3 AudioFlinger的破解
- 7.3.1 AudioFlinger的诞生
- 7.3.2 通过流程分析AudioFlinger
- 7.3.3 audio_track_cblk_t分析
- 7.3.4 关于AudioFlinger的总结
- 7.4 AudioPolicyService的破解
- 7.4.1 AudioPolicyService的创建
- 7.4.2 重回AudioTrack
- 7.4.3 声音路由切换实例分析
- 7.4.4 关于AudioPolicy的总结
- 7.5 拓展思考
- 7.5.1 DuplicatingThread破解
- 7.5.2 题外话
- 7.6 本章小结
- 第8章 深入理解Surface系统
- 8.1 概述
- 8.2 一个Activity的显示
- 8.2.1 Activity的创建
- 8.2.2 Activity的UI绘制
- 8.2.3 关于Activity的总结
- 8.3 初识Surface
- 8.3.1 和Surface有关的流程总结
- 8.3.2 Surface之乾坤大挪移
- 8.3.3 乾坤大挪移的JNI层分析
- 8.3.4 Surface和画图
- 8.3.5 初识Surface小结
- 8.4 深入分析Surface
- 8.4.1 与Surface相关的基础知识介绍
- 8.4.2 SurfaceComposerClient分析
- 8.4.3 SurfaceControl分析
- 8.4.4 writeToParcel和Surface对象的创建
- 8.4.5 lockCanvas和unlockCanvasAndPost分析
- 8.4.6 GraphicBuffer介绍
- 8.4.7 深入分析Surface的总结
- 8.5 SurfaceFlinger分析
- 8.5.1 SurfaceFlinger的诞生
- 8.5.2 SF工作线程分析
- 8.5.3 Transaction分析
- 8.5.4 关于SurfaceFlinger的总结
- 8.6 拓展思考
- 8.6.1 Surface系统的CB对象分析
- 8.6.2 ViewRoot的你问我答
- 8.6.3 LayerBuffer分析
- 8.7 本章小结
- 第9章 深入理解Vold和Rild
- 9.1 概述
- 9.2 Vold的原理与机制分析
- 9.2.1 Netlink和Uevent介绍
- 9.2.2 初识Vold
- 9.2.3 NetlinkManager模块分析
- 9.2.4 VolumeManager模块分析
- 9.2.5 CommandListener模块分析
- 9.2.6 Vold实例分析
- 9.2.7 关于Vold的总结
- 9.3 Rild的原理与机制分析
- 9.3.1 初识Rild
- 9.3.2 RIL_startEventLoop分析
- 9.3.3 RIL_Init分析
- 9.3.4 RIL_register分析
- 9.3.5 关于Rild main函数的总结
- 9.3.6 Rild实例分析
- 9.3.7 关于Rild的总结
- 9.4 拓展思考
- 9.4.1 嵌入式系统的存储知识介绍
- 9.4.2 Rild和Phone的改进探讨
- 9.5 本章小结
- 第10章 深入理解MediaScanner
- 10.1 概述
- 10.2 android.process.media分析
- 10.2.1 MSR模块分析
- 10.2.2 MSS模块分析
- 10.2.3 android.process.media媒体扫描工作的流程总结
- 10.3 MediaScanner分析
- 10.3.1 Java层分析
- 10.3.2 JNI层分析
- 10.3.3 PVMediaScanner分析
- 10.3.4 关于MediaScanner的总结
- 10.4 拓展思考
- 10.4.1 MediaScannerConnection介绍
- 10.4.2 我问你答
- 10.5 本章小结