一、简介
Dalvik虚拟机支持一系列的命令行参数(使用adbshell dalvikvm –help获取列表),但是不可能通过android应用运行时来传递任意参数,但是可以通过特定的系统参数来影响虚拟机行为。
对于下述所有参数,你都可以通过setprop来设置系统特性,shell命令如下:
adbshell setprop <name> <value>
必须重启android运行时从而使得改变生效(adb shell stop:adb shell start)。这是因为,这些设定在zygote进程中处理,而zygote最早启动并且永远存活。
你不可以以无特权用户的身份设定dalvik.*参数及重启系统。你可以在用户调试版本的shell上使用adb root或者运行su命令来获取root权限,如有疑问,
adbshell getprop <name>
可以告诉你setprop是否发生。
如果你不想在设备重启之后特性消失,在/data/local.prop上加一行:
<name>= <value>
重启之后这样的改变也会一直存在,但是如果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
-----------------------------------------------
jni check的方法,可以对非法的jni调用做check,
在/data/local.prop里加上dalvik.vm.checkjni=true, 然后重启
如果没有/data/local.prop文件则自己创建一个放进去
没有root的可以试试下面的,重启你的浏览器就行了
adb shell setprop debug.checkjni 1
用adb shell getprop dalvik.vm.checkjni看看打印的是不是true