Android_Dalvik移植.docVIP

Dalvik移植 Dalvik虚拟机可以在很多平台上运行，这些平台的操作系统至少是一个运行着GUNC编译器的类似于UNIX的平台（Linux,BSD,Mac OS X）。本文档指导读者如何把Dalvik虚拟机移植到一个Linux平台上，本文档假定我们要移植的平台和目前android平台在代码架构上有一定的相似性，可以进行移植。 核心库的移植 核心库的源代码主要在Dalvik/libcore和dalvik/vm/native这两个文件夹中。核心库的源代码是用C语言和C++写成的，因此在Linux环境下不需要更改。核心库的代码很多都是来自Apache Harmony项目，但是也有一些是来自OpenSSL、zlb和ICU等项目，因此，为了虚拟机的运行，这些项目需要被移植到新平台上。 JNI Call Bridge的移植 DVM的运行库绝大部分都是用portable C编写的，其中的一个例外是JNI Call Bridge。简单来说，它的作用是把一系列的整型值转变成各种类型的函数参数，并且调用函数。这个调用过程必须符合C函数调用的约定。 为了简化移植，JNI Call Bridge在新平台上通常会使用开源的FFI库（我觉得，这种库，大概类似于java一样，具有通用性吧）。但是，FFI运行不够快，也没有对平台做专门优化，所以，移植JNI Call Bridge首先应该重写一个FFI库。 JNI Call Bridge代码在dalvik/vm/arch/*这个位置上，同时，基于FFI的版本（我觉得大概是在移植的时候的通用版本）在“generic”目录下。每一种架构都有两个源文件，其中一个是定义了JNI Call Bridge函数，函数如下： void dvmPlatformlnvoke(void* pEnv,ClassObject* clazz,int arginfo,int argc,const char* signature,void* func,JValue* pReturn) 这个函数会调用如下C/C++函数：（我想应该是JNI函数） return_type func(JNIEnv* pEnv,Object* this[,args]) 或者 return_type func(JNIEnv* pEnv,ClassObject* clazz[,args])（适用于静态方法） dvmPlatformlnvoke是把argv所指向的值转化为符合C类型调用的值，而后调用我上面指出的函数，再把得到的返回值放入JValue* pReturn所指向的地方。该函数可能使用方法签名来决定如何处理函数中的相关值。至于方法签名，它是一个短小的DEX签名，用一个字符对应一个返回值和一个参数。 而另外一份源文件（前面提过有两个源文件）则定义了一个32位的“hint”。当相应的方法类型被加载时，hint值就会被计算出来，做为“arginfo”参数进入dvmPlatformlnvoke函数，hint可以用来使dvmPlatformlnvoke停止例如扫描函数的返回值、总体参数的大小，以及整型参数64字节条件测试的限制等的ASCII方法签名。（我想hint应该是决定函数是否对返回值或者参数进行方法签名扫描） 解释器的移植 Dalvik虚拟机运行库含有两个解释器，分别是标以“移动型”和“快速型”。 移动型主大体上就是一个C函数，在任何装有GCC的系统上都应该可以被编译出来。如果你的机器没装GCC，那么你应该停用“threaded”模块，因为这个模块依赖于GCC 的goto语句的目录来执行的。不清楚的话可以查找THREADED_INTERP的定义。 快速型使用手工汇编导致的碎片（？？这里不懂）。如果目前系统里没有解释器可用，那么系统就会从C stubs中生成一个解释器，这个解释器运行速度比移动型慢了很多，说它是快速解释器，实在是名不符实。 快速型在系统里是被默认使能的，如果源代码不支持快速型。那么该如何默认使能移动型呢？这可以通过dalvik.vm.execution-mode system来实现。例如，你输入如下一行： adb shell “echo dalvik.vm.execution-mode = int:portable /data/local.prop” 然后重启，这样android应用层框架启动时就自动会使能移动型解释器了。 Mterp解释器架构 如果用汇编语言重写解释器的话，解释器的效能应该会有一个明显的提高再加上相应平台专用架构的优化，dalvik可以用一个指令一次执行完毕（？？这里也不懂）。 实现解释器最简单的方法究竟是用一个大型的开关语句。每条指令执行完毕后，解释器就跳到循环的顶部，根据条件跳到合适的位置（我想使