Dalvik——如何支配vm

 一、简介

         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

若果该参数没有点名,系统会自行选择最为恰当的编译器,有时候机器可能同意选择任何模式,例如jit编译器。

切莫是兼具的阳台还发生优化的实现,有时候,快速编译器是由同样名目繁多的c实现的,这个结果碰头于不过移栽编译器还迟迟(当我们对有流行平台都有优化版本的时,这个命名“快速”就重新确切了)。

要程序分析如果能要调试器连接了,vm会变为调试解释器。当次分析了或者调试器中断连接,就见面还原原先的解释器。(用调试解释器会显变慢,这是以评估数据经常要切记的)

JIT编译器可以透过当应用程序AndroidManifest.xml中进入android:vmSafeMode=”true”来不使能,你怀疑JIT编译器会让你的使运行不健康的早晚可采取。

 

六、死锁预测

         如果虚拟机以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信息遭受检测到。

         这只是考虑了监督程序,本地的互斥量和其它资源也会见挑起死锁,而且未会见为它们检测及。

 

七、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。

 

八、dex文件与校验

         出于性能考虑,优化了的dex文件的和校验被裁撤了,这通常为安全,因为文件是当装备及发生的,并且发生取缔修改的权位。

         但是如设备的存储器不可靠,就会见发多少损坏,这便表现也还的虚拟机崩溃。为了迅速诊断这种失败,虚拟机提供了-Xcheckdexsum参数,如果设置了,在内容被应用前所有的dex文件还见面进行和校验。

         如果dalvik.vm.check-dex-sum特点深受如能,那么用框架会以虚拟机创建时供者参数。

         为了使能额外的dex和校验,可以:

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

         不正确的同校验会组织dex数据的动,产生错误并勾画副log文件,如果设备都有了这么的题目C++,那么用之特性写入/data/local.prop很有因此。

         注意dexdump工具每次都见面进行dex和校验,它为得用来检测大量的文书。

 

九、产生标志位

         在“Honeycomb”版本被引入了相同系列之汇编,它们经过标志位写副虚拟机:

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

         这些标志位中为此空格隔开。你可以指定任意多的标志位而她以系特性值的长短限制外(目前是92单字符)。

         这些额外的表明位会吃加到命令行的底端,意味着它会蒙前的设定。这些好用于例如测试不同的-Xmx的价值就android框架层已经设定了了。

 ———————————————–

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