1 測試工具的實現(xiàn)
1.1 調研目的
目前正在進行針對Unicore架構的Dalvik虛擬機改寫，為了保證整個Android操作系統(tǒng)在Unicore上的正常運行，我們試圖先獨立測試改寫后的Dalvik虛擬機；而Android2.1源碼中包含了dalvik虛擬機的測試工具，其目錄位于/android2.1/dalvik/tests下，我們先對它進行調研，看能否用它來測試我們改寫后的dalvik虛擬機。
調研分為三部分進行，首先了解該測試工具的實現(xiàn)方式，其次介紹它的使用方法，最后評估用它測試修改后的dalvik虛擬機的可行性。
1.2 tests簡介
首先分析/android2.1/dalvik/tests目錄的結構：
-tests dalvik測試工具和測試代碼文件夾。
--001——078 文件夾，保存了78個測試代碼，主要由/src/*.java（測試所需代碼）
以及xpected.txt（測試期望結果文檔）和info.txt（測試說明文檔）；
--ect 試工具的最終實現(xiàn)腳本，用Linux shell命令格式寫成；
--run-all-tests 執(zhí)行文件，測試所有78個測試代碼；
--run-test 可執(zhí)行文件，指定參數(shù)來測試特定的測試代碼。
1.3 測試工具的實現(xiàn)
通過上節(jié)的介紹，要理解測試工具是如何實現(xiàn)對dalvik虛擬機的測試，就必須理解run-test可執(zhí)行文件（run-all-tests可以看做是逐一調用run-tests），下面將具體介紹該可執(zhí)行文件的實現(xiàn)方式。
1.3.1 run-test的參數(shù)
1.3.1.1 綜述
進入/android2.1/dalvik/tests，在Linux shell下輸入命令：
./run-test –help
可以出現(xiàn)使用幫助，羅列并解釋如下：
run-test –help 打印幫助信息
run-test [options] [test-name] 正常運行命令的格式
run-test --dev [options] [test-name] 開發(fā)模式（運行結果dump到stdout）
run-test --update [options] [test-name] 更新模式（運行結果代替expect.txt）
運行參數(shù)：
--fast 使用快速解釋器（默認）
-jit 使用JIT
--portable 使用可移植的解釋器
--debug 等待調試器的連接
--no-verify 關閉校對功能（默認打開）
--no-optimize 關閉代碼優(yōu)化功能（默認打開）
--no-precise 關閉精確GC功能（默認打開）
--zygote 從Zygote進程創(chuàng)建當前進程，如果使用，當前運行參數(shù)會被忽視
--local 使用主機-本地（host-local）模擬器
--valgrind 本地運行時使用內存監(jiān)測
--reference 使用主機-本地參考（host-local reference）模擬器
通過幫助信息我們了解到，run-test有正常模式、開發(fā)模式、更新模式三種模式和多種參數(shù)，下面對參數(shù)的含義進行更詳細的說明，并評估了該參數(shù)對于我們使用本測試工具的價值，在下文中我們根據(jù)需要進一步調研一部分參數(shù)：
參數(shù) 含義 價值
fast dalvik的解釋器采用快速解釋器，與可移植型解釋器相對 高
jit android2.2開始采用的jit技術 低
portable dalvik解釋器采用可移植型解釋器，與快速解釋器相對 高
debug 調試用，等待調試器連接 高
verify dexopt的校對模式，dexopt用于dex代碼的優(yōu)化 中
optimize dexopt的優(yōu)化模式 中
precise GC管理的一個選項 低
zygote 直接從Zygote進程創(chuàng)建測試進程 中
local 使用local設備（不是host上的虛擬機）來測試 高
valgrind --local并且添加了內存管理的東西 低
reference 可使用host上的模擬器，模擬local設備的虛擬機進行測試 高
1.3.1.2 debug
該參數(shù)的幫助文檔是：等待調試器的連接（wait for debugger to attach）。為了使用該參數(shù)必須實現(xiàn)android的調試器（Debugger），dalvik虛擬機支持許多開發(fā)環(huán)境下的源碼級的調試，任何基于JDWP（Java Debug Wire Protocol）的遠程調試工具都可以，包括JDB、Eclipse、JSwat等。
首先，介紹該參數(shù)的實現(xiàn)原理。在本測試的腳本文件/android2.1/dalvik/tests/ect/push-and-run-test-jar（下文將解釋為什么是這個）中可以看出，debug參數(shù)是通過以下命令才實現(xiàn)的：
代碼位置：/android2.1/dalvik/tests/ect/push-and-run-test-jar
源代碼：
調試參數(shù)設定：
if [ "$DEBUG" = "y" ]; then
DEX_DEBUG="-agentlib:jdwp=transport=dt_android_adb,server=y,suspend=y"
fi
執(zhí)行命令：
adb shell cd /data \; dalvikvm $DEX_VERIFY $DEX_OPTIMIZE $DEX_DEBUG \
$GC_OPTS -cp test.jar "-Xint:${INTERP}" -ea Main "$@"
參數(shù)解釋如下：
transport： 所使用的傳輸機制，dalvik支持TCP/IP socket、通過adb（dt_android_adb）訪
問USB的方式；
server： 決定虛擬機是作為服務器（server）還是客戶端（client），作為服務器時，虛擬機等待調試器連接，反之，虛擬機主動試圖連接調試器；
suspend： 如果是y，虛擬機在調試器連接之前不運行任何代碼，連接時，它會告訴調試器它掛起了，直到有新的指令它才會運行。
最終--debug的參數(shù)變?yōu)閐alvikvm可執(zhí)行文件的參數(shù)來執(zhí)行。至于JDWP的工作原理，在此不展開討論。
下面，介紹--debug參數(shù)的具體使用方法（以在Linux下運行android模擬器、執(zhí)行本測試方法第17號源碼為例進行介紹）。
1、在本地Linux環(huán)境啟動android模擬器
cd /android2.1/out/host/linux-x86/bin （添加了環(huán)境變量后就可以在任意目錄輸入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調試器的橋梁，它顯示設備當前的進程、方法等內容，允許向設備發(fā)送命令，調試器可以通過它看到設備底層的PID號、進程號等內容。
cd /android2.1/out/host/linux-x86/bin
ddms
此時在DDMS界面上可以看到當前模擬器的運行狀態(tài)。由于此時已經(jīng)在運行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]
此時就已經(jīng)進入了調試界面，通過help命令可以看到可執(zhí)行的命令，包括run、step、stepi等很多。直接運行run可以跑完測試程序。
5、結果分析
最終的結果很有可能是測試FAILED（判斷依據(jù)下文將詳細敘述）。這是因為在執(zhí)行build時前期會導致：
DDM dispatch reg wait timeout
Can't dispatch DDM chunk 52454151: no handler defined
錯誤，后來就可以正常運行，具體原因不詳。但是對比expect.txt和output.txt，可以看出期望的結果已經(jīng)運行出來了。
1.3.2 run-test的實現(xiàn)——基礎
run-test可執(zhí)行文件是一個Linux Shell的腳本文件，下面分析它的執(zhí)行流程，從而調研本測試工具是如何測試dalvik虛擬機的。
run-test的執(zhí)行流程圖如下所示：
對于我們使用run-test來說，沒有必要詳細介紹內部的信息傳遞機制、具體參數(shù)的含義，只需要了解到它是怎么實現(xiàn)對dalvik虛擬機的測試的，下面具體就最后一個模塊“選擇要執(zhí)行的腳本”來進行闡述。
我們以使用默認的不含運行時參數(shù)的run-test命令為例進行介紹：
代碼位置：/android2.1/dalvik/tests/run-test 第218——230行
其代碼可簡化為如下流程圖：
從這張流程圖中可以清晰地看到執(zhí)行的過程和判斷的依據(jù)，但是又會產生兩個疑問：這樣為什么就能測試dalvik虛擬機了呢？宏build和run又是怎樣、是在哪兒執(zhí)行的呢？
1.3.3 run-test的實現(xiàn)——進階
1.3.3.1 測試dalvik原理
首先解決第一個疑問，為什么這樣就能測試dalvik虛擬機。
dalvik虛擬機的作用包括兩部分：解釋和運行。解釋是將android應用程序、framework層等處所用的JAVA代碼解釋為.dex格式，運行是通過dalvik虛擬機來執(zhí)行該.dex文件。如果有本地調用則通過JNI Call Bridge來解決。而上述流程圖中可以明顯看出，run-test可執(zhí)行文件正是重復了dalvik虛擬機的工作，并且將當前dalvik虛擬機的代碼運行結果和標準android2.1的dalvik虛擬機的運行結果比對從而判斷虛擬機能否正常運行。
下圖表示了android對于*.java的處理流程，可以粗略表征dalvik虛擬機的工作流程。
1.3.3.2 run-test最終實現(xiàn)方式
下面解決第二個問題：宏build和run又是怎樣、是在哪兒執(zhí)行的呢？
在run-test中有如下定義：
代碼位置：/android2.1/dalvik/tests/run-test
源代碼：
39 export JAVA="java"
export JAVAC="javac -target 1.5"
export RUN="${progdir}/etc/push-and-run-test-jar"
44 build="build"
run="run"
192 if [ '!' -r "$build" ]; then
cp "${progdir}/etc/default-build" build
fi
if [ '!' -r "$run" ]; then
cp "${progdir}/etc/default-run" run
fi
從這里可以清晰地看出，最終執(zhí)行沒有運行時參數(shù)的run-test的宏build和run的是/tests/ect/default-build和/tests/ect/default-run（其實是/tests/ect/push-and-run-test-jar）腳本文件。其中default-build將.jar轉化為.dex（解釋的功能），default-run將執(zhí)行push-and-run-test-jar腳本，它通過如下語句來實現(xiàn)dalvik的運行功能：
代碼位置：/android2.1/dalvik/tests/ect/push-and-run-test-jar
源代碼：
108 adb push test.jar /data
adb push test-ex.jar /data
130 adb shell cd /data \; dalvikvm $DEX_VERIFY $DEX_OPTIMIZE $DEX_DEBUG \
$GC_OPTS -cp test.jar "-Xint:${INTERP}" -ea Main "$@"
這里也就解釋了宏build和run事實上是在一個運行android的鏡像的ARM設備（device）上執(zhí)行的，因為它必須要執(zhí)行adb shell、adb push，必須要執(zhí)行鏡像根目錄下的/system/bin/dalvikvm可執(zhí)行文件來解析.jar，而在當前dalvikvm是基于ARM架構編譯出來的，在本地（host）上是不可執(zhí)行的文件。
1.3.4 測試源代碼
測試代碼并不是沒有針對性的任意JAVA程序，其組成都有如下規(guī)律：
1、代碼結構：
--src 保存了源代碼
-Main.java 執(zhí)行的java代碼（有點像C里面的main()函數(shù)的意思）
-*.java Main.java要調用的其他方法（面向對象而已）
--expect.txt 保存了android2.1的官方dalvik運行Main.java的結果
--info.txt 介紹了這個測試的內容
--src2 少數(shù)有，用于在更換了編譯生成了.class文件導致的“API不匹配”情況處理
2、代碼測試目標明確，分門別類地測試了參數(shù)設定、參數(shù)傳遞、進程管理、指針、線程、gc等等各個方面，通過查看哪個代碼測試結果和expect.txt不同，可以了解到dalvik虛擬機在處理哪方面問題上有錯誤。
2 測試工具的使用
2.1 測試工具在ARM設備上的使用方法
2.1.1 使用條件
從1.3.3節(jié)的分析可知，本測試工具的使用目前必須有以下兩個條件：
1、 有ARM架構的android設備或者本地虛擬機（？可能由--local參數(shù)決定）；
2、 在Linux環(huán)境下可連接到該設備；
其中第一個條件是由/android2.1/dalvik/tests/ect/push-and-run-test-jar中的adb命令、dalvikvm可執(zhí)行文件（android整體編譯生成，目前TARGET-ARCH為ARM）決定的，對于將.java解釋為.dex是否需要設備還沒有進行測試，第二個條件是由/android2.1/dalvik/tests/下的腳本文件寫法決定的，它使用了Linux shell，因此只能在Linux下執(zhí)行，不能在windows下運行該腳本。
2.1.2 使用方法
根據(jù)上述條件，可以寫出本測試工具的使用流程。
1、進入android2.1目錄，編譯android源碼
cd /USERDIR/android2.1
make
編譯結束后，進入/out/target/product/generic/system/bin，查看是否生成了dalvikvm，如果沒有，編譯錯誤，重新檢查并編譯。
2、在本地Linux環(huán)境android模擬器上測試其虛擬機（可省略，直接做第三步，但不推薦）
（1）啟動模擬器
cd /out/host/linux-x86/bin （添加了環(huán)境變量后就可以在任意目錄輸入emulator）
emulator
（2）進入/android2.1/dalvik/tests/目錄，shell下輸入：
./run-test 代碼文件夾名稱 測試指定文件夾的代碼
./run-all-tests 測試整個tests的78個代碼
即可運行本測試工具。
在本模式下可以用的參數(shù)包括—fast、--portable、--no-verify、--no-optimize和--reference，--debug和--zygote沒有測試，--local、--vargrind不可用。
3、在ARM架構的android設備上測試其虛擬機
（1）連接Linux環(huán)境（VMware虛擬機、Linux操作系統(tǒng)等等）到外部android設備。該步方法不統(tǒng)一，但衡量標準是，能在Linux下敲adb shell能連接到該設備。
（2）進入/android2.1/dalvik/tests/目錄，shell下輸入：
./run-test 代碼文件夾名稱 測試指定文件夾的代碼
./run-all-tests 測試整個tests的78個代碼
即可運行本測試工具。
2.1.3 測試結果分析
對于任何一個測試，評判測試成功與否的標準是對比android2.1官方dalvik運行該測試代碼的結果（expect.txt）和用戶dalvik運行測試代碼的結果（output.txt）是否相同。
如果結果相同，則測試成功，會在shell下顯示
android2.1_r2/dalvik/tests/代碼文件夾名稱: succeeded!
如果結果不相同，則測試失敗，會在shell下顯示
/android2.1_r2/dalvik/tests/017-float: FAILED!
#################info
CONTENT 測試內容
#################diffs
--- expect.txt 2010-06-23 08:58:55.000000000 +0800
+++ output.txt 生成時間
CONTENT 不同的地方
#################
file left in /tmp/test-NUM 測試生成的東西
根據(jù)這些可以找出哪里不同，從/tmp/test-NUM（/是LINUX的根目錄）文件夾下可以查看到dalvik運行的結果，更方便查處錯誤的所在。需要注意的是，不是報FAILED錯就代表著dalvik有問題。例如浮點運算會和具體硬件有關，測試結果和expect.txt很有可能不同，因此如果發(fā)現(xiàn)錯誤，需要逐個分析再對dalvik功能下結論。
3 后記
本測試工具的使用必須是在android設備運行起來、能使用adb和dalvikvm可執(zhí)行文件的情況下， 對該設備的虛擬機工作功能正確性進行測試。因此，本測試應該是放在dalvik修改工作的最后進行。
