一、简介

对于下述所有参数，你都可以通过setprop来设置系统特性，shell命令如下：

adbshell setprop

必须重启android运行时从而使得改变生效（adb shell stop：adb shell start）。这是因为，这些设定在zygote进程中处理，而zygote最早启动并且永远存活。

你不可以以无特权用户的身份设定dalvik.*参数及重启系统。你可以在用户调试版本的shell上使用adb root或者运行su命令来获取root权限，如有疑问，

adbshell getprop

可以告诉你setprop是否发生。

如果你不想在设备重启之后特性消失，在/data/local.prop上加一行：

=

重启之后这样的改变也会一直存在，但是如果data分区被擦除了就消失了。（提示：在工作台上创建一个local.prop，然后adb push local.prop /data/，或者，使用类似于adb shell “echo name =value >> /data/local.prop”的命令——注意，引号很重要）

二、扩展的JNI检测

JNI（Java Native Interface），java本地接口，提供了java语言程序调用本地（C/C++）代码的方法。扩展的JNI检测会引起系统运行更慢，但是可以发现一系列的讨厌的bug，防止他们产生问题。

有两个系统参数影响这个功能，这个功能可以通过-Xcheck:jni命令行参数来激活。第一个参数是ro.kernel.android.checkjni，这是通过android编译系统对development的编译来设置的（也可以通过android模拟器设置，除非通过模拟器命令行置了-nojni标志位）。因为这是一个”ro.”特性，设备启动之后参数就不能变了。

为了能触发CheckJNI标志位，第二种特性是dalvik.vm.checkjni，它的值覆盖了ro.kernel.android.checkjni的值。

如果这个特性没有被定义，dalvik.vm.checkjni也没有设置成false，那么-Xcheck:jni标志位就没有传入，JNI检测也就没有使能。

要打开JNI检测，使用以下命令：

adbshell setprop dalvik.vm.checkjni true。

也可以通过系统特性将JNI检测选项传递给虚拟机，dalvik.vm.jniopts的值可以通过-Xjniopts参数传入，例如：

adb shellsetprop dalvik.vm.jniopts forcecopy

更多信息见JNI建议。

三、断言

dalvik虚拟机支持java编程语言的断言表达式，默认它是关闭的，但是可以通过-ea参数的方式(dalvikvm –ea …..)设置dalvik.vm.enableassertions特性。

在其他桌面虚拟机中这个参数同样生效，通过提供class名、package名（后跟“…”），或者特殊值“all”。例如：

adbshell setprop dalvik.vm.enableassertion all

就可以在所有非系统class中使能断言。

这个系统特性比全命令行更受限制，不可以通过-ea入口设置更多，而且没有指定-da入口的方法，而且未来也没有-esa/-dsa等价的东西。

四、字节码校验和优化

系统尝试预校验dex文件中的所有类，从而降低class的负担，从而可以使用一系列的优化来提升运行性能。这些都是通过dexopt命令来实现的，不论是在编译系统中还是在安装上。在开发设备上，dexopt可能在dex文件第一次被使用时运行，而不论它或者它的依赖是否更新过（Just-in-time优化和校验，JIT）。

有两个命令行标志位控制JIT优化和校验，-Xverify和-Xdexopt。andorid框架基于dalvik.vm.dexopt-flags特性来配置这俩参数，如果你设定：

adbshell setprop dalvik.vm.dexopt-flags v=a o=v

那么android框架会将-Xverify:all-Xdexopt:verified传递给虚拟机，这将使能校验并且只优化校验成功的class。这是最安全的设定，也是默认的。

你也可以设定dalvik.vm.dexopt-flags v=n使得框架传输-Xverify:none –Xdexopt:verified从而不使能校验（我们可以传输-Xdexopt:all从而允许优化，但是这并不能优化更多代码，因为没有通过校验的class可能被优化器以同样的理由跳过）。这时class不会被dexopt校验，而没被校验的代码很大难以执行。

使能校验会使得dexopt命令明显花费更多时间，因为校验过程相对较慢，一旦校验和优化过的dex文件准备就绪，校验就不会占用额外的开销除非在加载预校验失败的class。

如果你的dex文件的校验关闭了，而后来又打开了校验器，应用加载会明显变慢（大概40%以上）因为class会在第一次被调用的时候校验。

为了最佳效果，当特性变化的时候你应该为dex文件强制重新调用dexopt，即：

adbshell “rm /data/dalvik-cache/*”

它删除了暂存的dex文件，记住要中止再打开运行时（adb shell stop：adb shell start）。

（老的运行时版本支持布尔型的dalvik.vm.verify-bytecode特性，但是被dalvik.vm.dexopt-flags替代了）

五、运行模式

当前dalvik vm的实现包括三个独立的解释内核：“快速”（fast）、“可移植”（portable）、“调试”（debug）。快速解释器是为当前平台优化的，可能包括手动优化的汇编文件；相对的，可移植解释器是用C写的，可在广泛的平台上使用；调试解释器是可移植解释器的变种，包括了支持程序分析（profiling）和单步。

vm可能也支持just-in-time编译，严格的说它并不是另一个解释器，JIT编译器也可以被同样的标志位使能/不使能（查看dalvik –help的输出信息来查看JIT编译器是否在你的虚拟机里面使能）。

vm允许你在快速、可移植和jit中选择，通过使用-Xint参数的扩展来实现，该参数的值可以通过dalvik.vm.execution-mode系统特性来设置。为了选择可移植解释器，你应该用：

adb shell setpropdalvik.vm.execution-mode int:portable

如果该参数没有指定，系统会自动选择最合适的编译器，有时候机器可能允许选择其他模式，例如jit编译器。

不是所有的平台都有优化的实现，有时候，快速编译器是由一系列的c实现的，这个结果会比可移植编译器还慢（当我们对所有流行平台都有优化版本的时候，这个命名“快速”就更准确了）。

如果程序分析使能或者调试器连接了，vm会变为调试解释器。当程序分析结束或者调试器中断连接，就会恢复原来的解释器。（用调试解释器会明显变慢，这是在评估数据时要记住的）