Dalvik——tests工具学习文档


1 测试工具的实现
1.1 调研目的
    目前正在进行针对Unicore架构的Dalvik虚拟机改写,为了保证整个Android操作系统在Unicore上的正常运行,我们试图先独立测试改写后的Dalvik虚拟机;而Android2.1源码中包含了dalvik虚拟机的测试工具,其目录位于/android2.1/dalvik/tests下,我们先对它进行调研,看能否用它来测试我们改写后的dalvik虚拟机。
    调研分为三部分进行,首先了解该测试工具的实现方式,其次介绍它的使用方法,最后评估用它测试修改后的dalvik虚拟机的可行性。
1.2 tests简介
首先分析/android2.1/dalvik/tests目录的结构:
-tests dalvik测试工具和测试代码文件夹。
--001——078   文件夹,保存了78个测试代码,主要由/src/*.java(测试所需代码)
以及xpected.txt(测试期望结果文档)和info.txt(测试说明文档);
--ect     试工具的最终实现脚本,用Linux shell命令格式写成;
--run-all-tests   执行文件,测试所有78个测试代码;
--run-test   可执行文件,指定参数来测试特定的测试代码。

1.3 测试工具的实现
    通过上节的介绍,要理解测试工具是如何实现对dalvik虚拟机的测试,就必须理解run-test可执行文件(run-all-tests可以看做是逐一调用run-tests),下面将具体介绍该可执行文件的实现方式。
1.3.1 run-test的参数
1.3.1.1 综述
    进入/android2.1/dalvik/tests,在Linux shell下输入命令:
./run-test –help
    可以出现使用帮助,罗列并解释如下:
run-test –help        打印帮助信息
run-test [options] [test-name]    正常运行命令的格式
run-test --dev [options] [test-name]    开发模式(运行结果dump到stdout)
run-test --update [options] [test-name] 更新模式(运行结果代替expect.txt)
运行参数:
--fast    使用快速解释器(默认)
   -jit     使用JIT
   --portable   使用可移植的解释器
   --debug    等待调试器的连接
   --no-verify   关闭校对功能(默认打开)
   --no-optimize     关闭代码优化功能(默认打开)
   --no-precise   关闭精确GC功能(默认打开)
   --zygote    从Zygote进程创建当前进程,如果使用,当前运行参数会被忽视
--local    使用主机-本地(host-local)模拟器
--valgrind    本地运行时使用内存监测
--reference   使用主机-本地参考(host-local reference)模拟器

    通过帮助信息我们了解到,run-test有正常模式、开发模式、更新模式三种模式和多种参数,下面对参数的含义进行更详细的说明,并评估了该参数对于我们使用本测试工具的价值,在下文中我们根据需要进一步调研一部分参数:
参数                                                含义                                                                              价值
fast                              dalvik的解释器采用快速解释器,与可移植型解释器相对                     高
jit                                  android2.2开始采用的jit技术                                                               低
portable                       dalvik解释器采用可移植型解释器,与快速解释器相对                         高
debug                         调试用,等待调试器连接                                                                     高
verify                          dexopt的校对模式,dexopt用于dex代码的优化                                    中
optimize                       dexopt的优化模式                                                                                中
precise                        GC管理的一个选项                                                                              低
zygote                         直接从Zygote进程创建测试进程                                                          中
local                             使用local设备(不是host上的虚拟机)来测试                                     高
valgrind                       --local并且添加了内存管理的东西                                                        低
reference                    可使用host上的模拟器,模拟local设备的虚拟机进行测试                    高

1.3.1.2 debug
        该参数的帮助文档是:等待调试器的连接(wait for debugger to attach)。为了使用该参数必须实现android的调试器(Debugger),dalvik虚拟机支持许多开发环境下的源码级的调试,任何基于JDWP(Java Debug Wire Protocol)的远程调试工具都可以,包括JDB、Eclipse、JSwat等。
        首先,介绍该参数的实现原理。在本测试的脚本文件/android2.1/dalvik/tests/ect/push-and-run-test-jar(下文将解释为什么是这个)中可以看出,debug参数是通过以下命令才实现的:
代码位置:/android2.1/dalvik/tests/ect/push-and-run-test-jar
源代码:
调试参数设定:
if [ "$DEBUG" = "y" ]; then
    DEX_DEBUG="-agentlib:jdwp=transport=dt_android_adb,server=y,suspend=y"
fi
执行命令:
adb shell cd /data \; dalvikvm $DEX_VERIFY $DEX_OPTIMIZE $DEX_DEBUG \
$GC_OPTS -cp test.jar "-Xint:${INTERP}" -ea Main "$@"
参数解释如下:
transport: 所使用的传输机制,dalvik支持TCP/IP socket、通过adb(dt_android_adb)访
问USB的方式;
server:   决定虚拟机是作为服务器(server)还是客户端(client),作为服务器时,虚拟机等待调试器连接,反之,虚拟机主动试图连接调试器;
suspend: 如果是y,虚拟机在调试器连接之前不运行任何代码,连接时,它会��诉调试器它挂起了,直到有新的指令它才会运行。
    最终--debug的参数变为dalvikvm可执行文件的参数来执行。至于JDWP的工作原理,在此不展开讨论。
下面,介绍--debug参数的具体使用方法(以在Linux下运行android模拟器、执行本测试方法第17号源码为例进行介绍)。
1、在本地Linux环境启动android模拟器
cd /android2.1/out/host/linux-x86/bin (添加了环境变量后就可以在任意目录输入emulator)
emulator
2、运行本测试工具
cd /android2.1/dalvik/tests
./run-test --debug 017
此时在shell下将显示如下内容:
[seucr@android2 tests]$ ./run-test --debug 017-float/
/home/seucr/android2.1_r2/dalvik/tests/017-float: running...
(等待调试器连接)
3、运行DDMS
DDMS(Dalvik Debug Monitor Server)可以看做连接设备和JDWP调试器的桥梁,它显示设备当前的进程、方法等内容,允许向设备发送命令,调试器可以通过它看到设备底层的PID号、进程号等内容。
cd /android2.1/out/host/linux-x86/bin
ddms
此时在DDMS界面上可以看到当前模拟器的运行状态。由于此时已经在运行debug下的测试,因此在DDMS上可以看到一个进程名叫“?”,点击它。
4、运行JDB调试
jdb -attach localhost:8700
此时shell会显示如下内容:
[seucr@android2 bin]$ jdb -attach localhost:8700
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
VM Started: "thread=<3> main", dalvik.system.NativeStart.main(), line=-1 bci=-1
<3> main[1]
此时就已经进入了调试界面,通过help命令可以看到可执行的命令,包括run、step、stepi等很多。直接运行run可以跑完测试程序。
5、结果分析
最终的结果很有可能是测试FAILED(判断依据下文将详细叙述)。这是因为在执行build时前期会导致:
DDM dispatch reg wait timeout
Can't dispatch DDM chunk 52454151: no handler defined
错误,后来就可以正常运行,具体原因不详。但是对比expect.txt和output.txt,可以看出期望的结果已经运行出来了。

  • 1
  • 2
  • 下一页

相关内容