3.4 Dalvik VM控制VM命令详解

Dalvik虚拟机支持一系列的命令行参数（使用adbshell dalvikvm -help命令获取列表），不可能通过Android应用运行时来传递任意参数，但是可以通过特定的系统参数来影响虚拟机行为。在本节的内容中，将详细讲解常用的控制VM的命令。

3.4.1 基本命令

在Dalvik虚拟机中，可以通过setprop来设置系统特性，使用shell命令的语法格式如下所示：

        adbshell setprop <name> <value>

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

不可以用无特权用户的身份设定dalvik.*参数及重启系统，可以在用户调试版本的shell上使用adb root或者运行su命令的方式来获取root权限，可以通过如下命令告诉setprop是否发生：

        adbshell getprop <name>

如果不想在设备重启之后特性随之消失，可以在/data/local.prop中加上如下所示的命令：

        <name>= <value>

重启之后这样的改变也会一直存在，但是如果data分区被擦除就消失了。在工作台上创建一个local.prop，然后adb push local.prop /data/，或者使用类似于下面格式的命令，注意这里引号很重要：

        adb shell “echo name =value >> /data/local.prop”

3.4.2 扩展的JNl检测

JNI（JavaNative 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

3.4.3 断言

Dalvik虚拟机支持Java编程语言的断言表达式，默认它是关闭的，但是可以通过如下-ea参数的方式设置dalvik.vm.enableassertions特性：

        dalvikvm -ea..

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

        adbshell setprop dalvik.vm.enableassertion all

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

3.4.4 字节码校验和优化

Dalvik VM会尝试预校验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）。

3.4.5 Dalvik VM的运行模式

当前Dalvik VM的实现包括3个独立的解释内核：“快速”（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会变为调试解释器。当程序分析结束或者调试器中断连接，就会恢复原来的解释器。用调试解释器会明显变慢，这是在评估数据时要记住的。

JIT编译器可以通过在应用程序AndroidManifest.xml中加入android:vmSafeMode=“rue”来不使能，当怀疑JIT编译器会使得应用运行不正常的时候可以使用该功能。

3.4.6 死锁预测

如果虚拟机以WITH_DEADLOCK_PREDICTION参数编译，那么死锁预测器会在-Xdeadlockpredict参数中使能（dalvikvm -help会告诉你虚拟机是否编译正确——在Configured中按行查找deadlock_prediction）。这个特性会让虚拟机一直跟踪对象的锁获取的顺序，如果程序试图以与之前看到不同的顺序获取一些锁，虚拟机会log一个warning并有选择地抛出异常。

命令行参数是基于dalvik.vm.deadlock-predict特性设置的，正确的值是“off”，表示不使能它（默认）; “warn”表示log问题但是继续执行；“err”表示从monitor-enter指令中引发一个dalvik.system.PotentialDeadlockError异常；“abort”表示终止整个虚拟机。通常可以这么使用：

        adbshell setprop dalvik.vm.deadlock-predict err

除非可以在log信息滚动的时候一直关注着。注意这个特性是死锁预测，不是死锁检测——在当前实现中，在锁被获取之后才会进行计算（这减轻了代码量，降低了互斥信息外的冗余）。在挂起的进程中执行kill -3时可以发现一个死锁，并且可以在Log信息中检测到。

这仅仅考虑了监督程序，本地的互斥量和其他资源也会引起死锁，而且不会被它检测到。

3.4.7 dump堆栈追踪

和其他桌面虚拟机一样，Dalvik虚拟机收到SIGQUIT（Ctrl-\或者kill -3）时，会为所有的现成dump所有的堆栈追踪。它默认写入Android的log，但是也可以写入一个文件。

dalvik.vm.stack-trace-file特性允许你指定要将线程堆栈追踪写入的文件名，如果不存在，将创建，新的信息将追加到文件尾，文件名通过-Xstacktracefile参数写入虚拟机。例如：

        adbshell setprop dalvik.vm.stack-trace-file /tmp/stack-traces.txt

如果这个特性没有被定义，虚拟机会在收到这个信号时将堆栈追踪信息写入Android log。

3.4.8 dex文件和校验

出于性能考虑，优化过的dex文件和校验被取消了，这通常叫安全，因为文件是在设备上产生的，并且有禁止修改的权限。

但是如果设备的存储器不可靠，就会发生数据损坏，这通常表现为重复的虚拟机崩溃。为了快速诊断这种失败，虚拟机提供了-Xcheckdexsum参数，如果设置了，在内容被使用之前所有的dex文件都会进行和校验。如果dalvik.vm.check-dex-sum特性被使能，那么应用框架会在虚拟机创建时提供这个参数。

为了使能额外的dex和校验，可以用如下命令实现：

        adbshell setprop dalvik.vm.check-dex-sum true

不正确的和校验会组织dex数据的使用，产生错误并写入log文件，如果设备曾经有过这样的问题，那么将这个特性写入/data/local.prop很有用。

3.4.9 产生标志位

在“Honeycomb”版本中引入了一系列的汇编，它们通过标志位写入虚拟机：

        adb shell setprop dalvik.vm.extra-opts "flag1flag2 … flagN"

在这些标志位之间需要用空格隔开。可以指定任意多的标志位，只要它们在系统特性值的长度范围内，目前是92个字符。

这些额外的标志位会被加到命令行的底端，意味着它们会覆盖之前的设定。这些可以用于例如测试不同的-Xmx的值，即使Android框架层已经设定过了。