吳 昊，張 哲

(東南大學(xué)國家專用集成電路系統(tǒng)工程技術(shù)研究中心，南京210096)

Google 于2008 年發(fā)布的Android 系統(tǒng)，因其開放源碼完全免費(fèi)等特性［1］，在嵌入式領(lǐng)域［2］異軍突起，吸引了大量的方案解決公司和設(shè)備制造廠商，如今占據(jù)智能手機(jī)領(lǐng)域的半壁江山。但官方原生的Android 系統(tǒng)并不支持所有CPU 架構(gòu)，其中Dalvik虛擬機(jī)就是一方面的體現(xiàn)。雖然目前絕大部分的Android 產(chǎn)品是基于ARM 架構(gòu)，但是非ARM 架構(gòu)陣營正努力向Android 靠齊。

為了使非官方支持的架構(gòu)平臺運(yùn)行Android 系統(tǒng)，需要對Android 的多個方面進(jìn)行移植與修改。其中包括最基本的編譯工具鏈的支持、Android 系統(tǒng)的整個編譯系統(tǒng)的修改、bionic 庫的移植和Dalvik虛擬機(jī)的移植。

本文通過分析研究ARM 架構(gòu)Android 系統(tǒng)Dalvik 虛擬機(jī)［3］，為基于自主內(nèi)核Unity 的國產(chǎn)SoC SEP0611 的Dalvik 虛擬機(jī)的移植和優(yōu)化起到指示性作用。第2 節(jié)分析了Dalvik 虛擬機(jī)的硬件平臺相關(guān)性和Java 平臺無關(guān)性，定位Dalvik 虛擬機(jī)移植的重點(diǎn)和關(guān)鍵。第3 節(jié)介紹了Dalvik 虛擬機(jī)在SEP0611國產(chǎn)自主SoC 上的移植，然后重點(diǎn)分析以ARM 架構(gòu)為代表本地方法調(diào)用橋。第4 節(jié)介紹了Dalvik 虛擬機(jī)在SEP0611 國產(chǎn)自主SoC 上的優(yōu)化，并且對Dalvik 虛擬機(jī)優(yōu)化的幾個方向進(jìn)行了分析與研究。

1 Dalvik 虛擬機(jī)平臺

Dalvik 虛擬機(jī)運(yùn)行的是Java 程序，所以Dalvik 虛擬機(jī)有Java 虛擬機(jī)的遺傳基因，我們暫且認(rèn)為Dalvik虛擬機(jī)是經(jīng)過裁剪優(yōu)化過的Java 虛擬機(jī)。Dalvik 虛擬機(jī)是否屬于Java 虛擬機(jī)只是理解層面上的差異:若把Java 虛擬機(jī)理解成運(yùn)行Java 程序的虛擬機(jī)，那Dalvik 虛擬機(jī)就屬于Java 虛擬機(jī)的范疇［4］;若Java虛擬機(jī)是指運(yùn)行特定格式指令集或包含特定技術(shù)專利的虛擬機(jī)，則Dalvik 虛擬機(jī)則不屬于Java 虛擬機(jī)。

1.1 Java 的平臺無關(guān)性

Java 語言有一個眾所周知的強(qiáng)大特性——write once，run anywhere［5］。實(shí)現(xiàn)Java 語言平臺無關(guān)性的關(guān)鍵就是各種不同平臺的虛擬機(jī)與所有平臺都使用統(tǒng)一的存儲格式——Class 字節(jié)碼，即字節(jié)碼是構(gòu)成平臺無關(guān)性的基石，虛擬機(jī)則是字節(jié)碼實(shí)現(xiàn)的載體。

同時(shí)，Java 編譯語言本身體現(xiàn)了平臺無關(guān)性:其基本數(shù)據(jù)類型的值域和行為都是由Java 語言本身定義，而與目標(biāo)平臺無關(guān)。如基本數(shù)據(jù)類型int 都是用32 bit 二進(jìn)制補(bǔ)碼表示。同樣的，Java 虛擬機(jī)內(nèi)部和Class 文件中都是一致的。

至此為止，本文分析平臺無相性的都是從語言本身或體系結(jié)構(gòu)的角度出發(fā)。從這一角度分析影響平臺相關(guān)性的因素包括:Java 平臺的部署;Java 平臺的版本;本地方法的使用;非標(biāo)準(zhǔn)的運(yùn)行庫;對虛擬機(jī)的依賴;對用戶界面的依賴。

1.2 虛擬機(jī)與硬件平臺的相關(guān)性

本文所關(guān)心的平臺相關(guān)性并非上文所述，而是狹義的指虛擬機(jī)本身的實(shí)現(xiàn)在編譯之前與特定目標(biāo)架構(gòu)的相關(guān)性，這也是Java 語言聲稱的平臺無關(guān)性必然帶來的的問題——虛擬機(jī)是平臺相關(guān)的。虛擬機(jī)屏蔽了Java 語言的平臺相關(guān)性，代價(jià)就是在每一個平臺上實(shí)現(xiàn)一種虛擬機(jī)。

當(dāng)然，本文所述的Java 程序有別于大家熟知的Java 程序，因?yàn)樗贒ex 字節(jié)碼。不同平臺的Java 虛擬機(jī)都能運(yùn)行Java 編譯器編譯好的程序，是因?yàn)檫@些Java 虛擬機(jī)都運(yùn)行Class 字節(jié)碼。同樣的，Dalvik 虛擬機(jī)在不同平臺上實(shí)現(xiàn)統(tǒng)一的Dalvik字節(jié)碼——Dex 字節(jié)碼，就能現(xiàn)實(shí)Dalvik 虛擬機(jī)的平臺無關(guān)性。

2 Dalvik 虛擬機(jī)的移植

Dalvik 虛擬機(jī)中Dex 字節(jié)碼成為了Android 應(yīng)用程序平臺無關(guān)性的基石，但真正意義上的應(yīng)用程序的跨平臺運(yùn)行的基礎(chǔ)確屬Dalvik 虛擬機(jī)。Dalvik虛擬本身架構(gòu)是用C 語言實(shí)現(xiàn)，而且Java 應(yīng)用程序中可以帶本地庫，這兩種方法都是Java 程序中JNI(Java Native Interface)機(jī)制的一個體現(xiàn)。通過分析研究發(fā)現(xiàn)，JNI 機(jī)制中的本地方法調(diào)用橋環(huán)節(jié)正是基于自主內(nèi)核Unity 的國產(chǎn)SoC 的Dalvik 虛擬機(jī)移植的關(guān)鍵。

2.1 基于自主內(nèi)核Unity 的國產(chǎn)SoC 介紹

Tiger 是定位于移動多媒體、衛(wèi)星導(dǎo)航產(chǎn)品的高性能應(yīng)用處理器，采用TSMC65nm 工藝，封裝TFBGA400，17 cm×17 cm，主要有以下特性:

(1)UNITY－2 內(nèi)核，主頻最高800 MHz;

(2)多總線架構(gòu);

(3)支持DDR3/DDR2/SRAM/NOR/NAND 存儲器接口;

(4)支持H. 264/MPEG4/DivX/VC1/RV 等主流視頻格式的1080P 解碼;

(5)支持外接AUDIO CODEC 芯片實(shí)現(xiàn)音頻輸入輸出;

(6)支持外接HDMI 芯片實(shí)現(xiàn)HDMI 視頻輸出;

(7)支持24 bit 色LCD 輸出，可支持4 層Overlay;

(8)內(nèi)嵌USB OTG 2.0 控制器，支持外接PHY實(shí)現(xiàn)USB 2.0 傳輸;

(9)支持SDIO 接口和SDHC 存儲卡;

(10)高速SPI/UART/I2C 等串行接口;

(11)支持年月日時(shí)分秒實(shí)時(shí)時(shí)鐘;

(12)支持GPS 定位;

(13)內(nèi)嵌電源管理，可動態(tài)調(diào)整頻率;

2.2 虛擬機(jī)中的JNI 機(jī)制

從Java1.1 開始，JNI 標(biāo)準(zhǔn)成為Java 平臺的一部分，它允許Java 代碼和用其他語言編寫的代碼進(jìn)行交互。使用JNI，需要在使用本地方法的Java源碼中聲明本地方法，然后在C 或C++中實(shí)現(xiàn)該本地方法，最后將本地方法注冊到系統(tǒng)中。聲明時(shí)，必須使用Native 關(guān)鍵字，本地方法的實(shí)現(xiàn)使用的數(shù)據(jù)類型也應(yīng)該遵循JNI 框架，將本地方法注冊到系統(tǒng)是通過調(diào)用JNIRegisterNativeMethods 實(shí)現(xiàn)，該函數(shù)需要傳入所有本地方法的一個集合——本地方法列表。本地方法列表中的每一項(xiàng)都是一個結(jié)構(gòu)體，這個結(jié)構(gòu)體正是JNI 的核心:JNINative－Method。

typedef struct{

const char* name; /* JNI 函數(shù)的名稱* /

const char* signature;/* 描述JNI 函數(shù)的參數(shù)和返回值* /

void* fnPtr; /* JNI 函數(shù)對應(yīng)的C 語言的函數(shù)指針* /

}JNINativeMethod;

其中，Dalvik 虛擬機(jī)比較關(guān)心的部分是該結(jié)構(gòu)體的第2 項(xiàng)Signature。因?yàn)镾ignature 中包含了JNI函數(shù)的參數(shù)和返回值類型，這指明了Java 調(diào)用本地方法時(shí)參數(shù)和返回值的類型，然后虛擬機(jī)根據(jù)架構(gòu)的傳參規(guī)則及Signature 解析的結(jié)果，完成參數(shù)從Java 到C/.C++的傳遞。

2.3 本地方法調(diào)用橋的實(shí)現(xiàn)

上面§2.2 簡單介紹了JNI 機(jī)制，現(xiàn)在來分析JNI 中與特定平臺相關(guān)的部分——本地方法調(diào)用橋。這個部分是移植Dalvik 虛擬機(jī)的關(guān)鍵部分，主要體現(xiàn)在兩個方面:一是特定架構(gòu)平臺下數(shù)據(jù)類型的對齊要求;二是特定架構(gòu)下函數(shù)調(diào)用傳參規(guī)則。事實(shí)上，在特定平臺上實(shí)現(xiàn)這兩個部分就算是完成了Dalvik 機(jī)的移植。剩下的其它工作主要是優(yōu)化和測試了。

從分析ARM 體系架構(gòu)的實(shí)現(xiàn)開始，可以發(fā)現(xiàn)ARM 架構(gòu)遵循ARM EABI 規(guī)范［6］，入口棧地址是8 bit 對齊、64 bit 數(shù)據(jù)(包括long long 和double)在棧中要求8 bit 對齊。因此在解析Signature 時(shí)，遇到‘D’和‘J’，應(yīng)該判斷在棧中存取當(dāng)前數(shù)據(jù)時(shí)是否是8 bit 齊。若不是則需要用預(yù)留或插入一個32 bit 空白數(shù)據(jù)，并使用相對應(yīng)的位來標(biāo)記該32 bit 空白數(shù)據(jù)。

為了實(shí)現(xiàn)該特性，先在HintsEABI. c 的文件中提前解析好Signature，把記錄好的信息存儲在一個32 bit 長的數(shù)據(jù)jniHints 中，該jniHints 作為函數(shù)的返回值返回，被存儲到j(luò)niArgInfo 中。而另一個函文件CallEABI. S 中的函數(shù)dvmPlatformInvoke 的第三個參數(shù)則是jniArgInfo，函數(shù)dvmPlatformInvoke 的功能是:按照函數(shù)調(diào)用傳參規(guī)則實(shí)現(xiàn)函數(shù)函數(shù)的傳遞。這樣，通過HintsEABI.c 和CallEABI.S 的配合工作，完成了JNI 本地方法調(diào)用時(shí)函數(shù)的傳遞。

HintsEABI.c 中生成的jniHints 的主要功能是:在CallEABI.S 中完成本地方法調(diào)用傳遞參數(shù)時(shí)需要為用棧傳遞的部分參數(shù)開辟多大的棧空間。當(dāng)然開辟靜態(tài)的一個大的空間能滿足參數(shù)的傳遞，但這樣的實(shí)現(xiàn)會浪費(fèi)大量的內(nèi)存，這對內(nèi)存相對較小的嵌入式設(shè)備來說無疑是致使的。所以使用這樣一個機(jī)制，開辟一個大小剛剛好的棧來完成參數(shù)傳遞是一種很巧妙的方法。

由于ARM 中l(wèi)ong long 和double 在棧中要求8字節(jié)對齊的特性，需要對生成的jniHints 作一番特殊的處理，jniHints 存儲了jniArgInfo 的低28 bit 和第31 bit:

//dvmPlatformInvokeHints(proto)返回值為jniHints

hints=dvmPlatformInvokeHints(proto);

if(hints ＆ DALVIK_JNI_NO_ARG_INFO){

jniArgInfo |=DALVIK_JNI_NO_ARG_INFO;

}else {

assert((hints ＆ DALVIK_JNI_RETURN_MASK)= =0);jniArgInfo |=hints;

下面來詳細(xì)介紹ARM 架構(gòu)下jniArgInfo 32 bit數(shù)據(jù)每一位的構(gòu)成:

SRRR LLLL HHHHHHHH HHHHHHHH HHHHHHHH

其中，S 位和R 位是各個架構(gòu)平臺通用的，L 和H 構(gòu)成的28 bit 可以由每個架構(gòu)平臺獨(dú)立實(shí)現(xiàn)。

S 是標(biāo)志位，如果被設(shè)置則說明參數(shù)過多(過多的標(biāo)準(zhǔn)以該32 bit 數(shù)據(jù)能表示數(shù)據(jù)為準(zhǔn))則使用方法簽名的方式進(jìn)行參數(shù)解析;

R 表示返回值的數(shù)據(jù)類型;

L 表示需要用棧傳參的部分所需的內(nèi)存大小，單位為8 bit;

H 表示解析參數(shù)過程中需要對double 或long long 數(shù)據(jù)進(jìn)行插入空白數(shù)據(jù)的情況時(shí)進(jìn)行標(biāo)志設(shè)定，當(dāng)某個H 被設(shè)置成1 后，在拷貝下一個數(shù)據(jù)到堆棧之前應(yīng)該先跳過32 bit;

以一個簡單的實(shí)例來加深對各標(biāo)志位的理解:生成jniHints 的重要中間變量如下:

//通過dexProtoGetShorty(proto)獲取signature

const char* sig=dexProtoGetShorty(proto);

int padFlags;

int stackOffset，padMask;

stackOffset=padFlags=0;

padMask=0x00000001

假設(shè)本地方法對對應(yīng)的signature 為”IZBIJCD”，在這種情況下，各變量的結(jié)果為

padFlags=0x00000088

對應(yīng)二進(jìn)制為:

0000 0000 0000 0000 0000 0000 1000 1000 padMask=0x00000400

對應(yīng)二進(jìn)制為:

0000 0000 0000 0000 0000 0100 0000 0000

stackOffset=10

jniArgInfo 的內(nèi)容為0x44000088

各個參數(shù)在寄存器和棧中的位置如圖1 所示。

圖1

圖1 中，棧開始的地址是8 byte 對齊的0x10001000，其中第4 個參數(shù)和第6 個參數(shù)為64 bit數(shù)據(jù)，也需要8 byte 對齊。但是在存儲第3 個參數(shù)后的32 bit 數(shù)據(jù)地址0x10001004 并不是64 bit 對應(yīng)的，所以填充一個32 bit 的pad。由上圖可以看到，需要開辟一個4·2 字大小的空間，這就是為什么jniArgInfo 中的L 位為0100。

第一個布爾類型的參數(shù)Arg1(Z)與第2 個字節(jié)類型的參數(shù)Arg2(B)分別存儲在R2、R3 中，這是由ARM 體系結(jié)構(gòu)APTCS 規(guī)則決定的。前4 個參數(shù)(假設(shè)前4 個參數(shù)大小均為32 bit 或以下)分別由R0、R1、R2、R3 傳遞，其它多余的參數(shù)由棧傳遞。但是JNI 機(jī)制中的本地方法的實(shí)現(xiàn)中第1、第2 個參數(shù)為兩個固定的參數(shù)，并不需要虛擬機(jī)來傳遞，所以Java中調(diào)用本地方法時(shí)傳遞過來的第1 個參數(shù)對應(yīng)本地方法中第3 個參數(shù)，依此類推。這也是為什么上例中的stackOffset 為10，但只為棧開辟了8 字的空間。

ARM 架構(gòu)的jniArgInfo 之所以這樣表示是由ARM 架構(gòu)決定的，如之前所述的ARM 架構(gòu)中l(wèi)ong long 和double 數(shù)據(jù)要棧中要以64 bit 對齊。因此在一個新的架構(gòu)上實(shí)現(xiàn)Dalvik 虛擬機(jī)之前，需要了解該架構(gòu)編譯相關(guān)ABI 的詳細(xì)內(nèi)容，包括基本數(shù)據(jù)類型在內(nèi)存中的對齊方式、入口棧地址的對齊方式、函數(shù)調(diào)用規(guī)范。

基于自主內(nèi)核Unity 架構(gòu)的Tiger，long long 和double 數(shù)據(jù)是以4 byte 方式對齊的，所以L 位是不需要的，需要開辟棧的大小可以直接存在H 位中。U－Core 架構(gòu)下的jniArgInfo 可以表示為:

SRRR0000 00000000 00000000 HHHHHHHH

本地方法調(diào)用橋?qū)崿F(xiàn)的最后一步就是用匯編實(shí)現(xiàn)參數(shù)的傳遞，jniArgInfo 只是為了參數(shù)的傳遞做準(zhǔn)備。這部分內(nèi)容在CallEABI.S 中完成，它實(shí)現(xiàn)了一個名為dvmPlatformInvoke 的函數(shù)，為了保持接口的一致性，最好保持該函數(shù)的名稱。該函數(shù)通過解析jniArgInfo，將Argv 中的內(nèi)容復(fù)制到對應(yīng)的寄存器或堆棧中，Argv 中內(nèi)容的復(fù)制必須嚴(yán)格的遵守對應(yīng)架構(gòu)的函數(shù)傳參數(shù)規(guī)則。

3 Dalvik 虛擬機(jī)的優(yōu)化

利用Oprofile 工具，在SEP0611 開發(fā)板上對Android 應(yīng)用進(jìn)行數(shù)據(jù)記錄，得到以下結(jié)果:

Profiling through timer interrupt

TIMER:0|

samples| % |

－－－－－－－－－－－－－－－－－－

14275 44.1172 libdvm.so

5535 17.1060 libGAL.so

3991 12.3343 vmlinux

3071 9.4910 libGLESv1_CM_VIVANTE.so

2105 6.5055 libc.so

928 2.8680 libandroid_runtime.so

656 2.0274 libEGL_VIVANTE.so

521 1.6102 libGLESv1_CM.so

242 0.7479 galcore

213 0.6583 linker

178 0.5501 libm.so

其中第1 項(xiàng)libdvm.so 就是Dalvik 虛擬機(jī)，它占用CUP 時(shí)鐘的比率最高，達(dá)到了44.117 2%，遠(yuǎn)高于其他進(jìn)程，由此，對Dalvik 虛擬機(jī)進(jìn)行優(yōu)化是非常有必要的。

Dalvik 虛擬機(jī)中字節(jié)碼實(shí)現(xiàn)的集合我們稱之為Java 虛擬機(jī)的執(zhí)行引擎。執(zhí)行引擎是Java 程序運(yùn)行的核心部份，它由純解釋器或JIT(Just in time)解釋器編譯器構(gòu)成。通過Oprofile 工具記錄虛擬機(jī)測試軟件CaffineMark，可以看到解釋器更是占到了運(yùn)行時(shí)間的90+%，因此我們可以看到Dalvik 虛擬機(jī)優(yōu)化的重心就是在執(zhí)行引擎。

3.1 解釋器的優(yōu)化

執(zhí)行引擎的核心是解釋器，解釋器的基本構(gòu)成是一個個的解釋例程。解釋例程的執(zhí)行效率直接影響整個虛擬機(jī)的性能。提高解釋器性能的最好途徑無疑是用匯編重寫解釋器。雖然解釋器的實(shí)現(xiàn)有很多種，但Android 官方實(shí)現(xiàn)的Mtemp 解釋器無疑是最適合嵌入式設(shè)備的，因此在一個新的架構(gòu)上對解釋器進(jìn)行優(yōu)化時(shí)無需閉門造車。

Android 源碼中Dex 字節(jié)碼功能用C 語言作出了描述，給出了解釋器平臺無關(guān)的實(shí)現(xiàn)，這就是為什么在實(shí)現(xiàn)本地方法調(diào)用橋后就完成了移植工作。同時(shí)官方針對ARM 架構(gòu)用匯編重寫了解釋器，這使得在一個新的架構(gòu)上用匯編重寫解釋器的難度降到最低。同時(shí)，我們可以看出執(zhí)行引擎可以與平臺無關(guān)。

在優(yōu)化解釋器之前必須對Dalvik 虛擬機(jī)的Dex字節(jié)碼有深入的了解，從Dex 字節(jié)碼的實(shí)現(xiàn)我們可以看出Dalvik 虛擬機(jī)是基于寄存器的。

基于寄存器［7］和基于棧這個問題體現(xiàn)在虛擬機(jī)底層對字節(jié)碼的處理方面。Dex 字節(jié)碼是dalvik 虛擬機(jī)能直接解釋執(zhí)行的最小單位，它的指令格式與匯編類似，有第1 操作寄存器，第2 操作寄存器，立即數(shù)等。如有一條字節(jié)碼為:add－int/2addr V0，V1。這里的V 表示的是虛擬機(jī)中的寄存器，它是區(qū)別于r 而命名的。值得注意的是，CPU 上是沒有兩個寄存器與V0、V1 相對應(yīng)的。所以我們稱V0、V1 為虛擬機(jī)寄存器，它是用一個棧進(jìn)行模擬的，所以這條指令的執(zhí)行效率要遠(yuǎn)遠(yuǎn)低于真正的匯編:add V0，V0，V1。而對這條Dex 字節(jié)碼的執(zhí)行我們稱之為解釋執(zhí)行，它需要若干條真正的匯編指令進(jìn)行功能模擬。當(dāng)然用C 語言進(jìn)行功能模擬的代價(jià)要比匯編模擬的效率低很多。

3.2 即時(shí)編譯

JIT(Just in time)是執(zhí)行引擎實(shí)現(xiàn)的一個可選擇模塊，即執(zhí)行引擎可以由解釋器單獨(dú)構(gòu)成，也可以是解釋和JIT 編譯器配合工作共同組建。Android系統(tǒng)從2.2 開始在Dalvik 虛擬機(jī)中真正意義上的實(shí)現(xiàn)了JIT 即時(shí)編譯器［8］，經(jīng)過專業(yè)的虛擬機(jī)性能測試軟件測試我們可以發(fā)現(xiàn)虛擬機(jī)性能成倍的增長。當(dāng)然，為了實(shí)現(xiàn)新架構(gòu)平臺的JIT 需要付出很大的代價(jià)。主要包括特定字節(jié)碼的匯編模板實(shí)現(xiàn)、對應(yīng)架構(gòu)LIR 指令集全集的模擬，當(dāng)然，為了配合解釋器工作，解釋器中也需要實(shí)現(xiàn)相應(yīng)對JIT 的處理。

Dalvik 虛擬機(jī)中JIT 的被設(shè)計(jì)成一個可變目標(biāo)的即時(shí)編譯，即JIT 的實(shí)現(xiàn)大部分均與目標(biāo)平臺的架構(gòu)無關(guān)，包括JIT 的整個框架是平臺無關(guān)的、Dex 字節(jié)碼到MIR 的格式的轉(zhuǎn)換可以適用于任何一個平臺。在一個新的架構(gòu)上實(shí)現(xiàn)JIT 只需完成MIR 到LIR 的轉(zhuǎn)換和最終目標(biāo)指令集的模擬，類似于實(shí)現(xiàn)一個小型的編譯器。但即使是這樣，工作量還是非常龐大的，同時(shí)找一個有效可行的調(diào)試方法或技術(shù)路線也是相當(dāng)有難度的。在一個新的架構(gòu)上實(shí)現(xiàn)JIT 之前需要認(rèn)真的評估一下工作量和JIT 帶來的實(shí)在的好處。

經(jīng)過專業(yè)的虛擬機(jī)性能測試軟件測試表明JIT確實(shí)能使虛擬機(jī)性能成倍的提升，但這個數(shù)具對于用戶來說并無知曉。從用戶體驗(yàn)的角度出發(fā)，筆者進(jìn)行了大量的應(yīng)用程序的測試，包括應(yīng)用程序打開的速度，程序運(yùn)行過程的反應(yīng)的速度等測試項(xiàng)。結(jié)果表明，JIT 對用戶體驗(yàn)并無影響。同時(shí)，引入JIT后，目標(biāo)設(shè)備可用的內(nèi)存相比要減少，這是由JIT 的特性決定的:以內(nèi)存空間換取運(yùn)行效率。

4 小結(jié)

本文對Dalvik 虛擬機(jī)在SEP0611 國產(chǎn)自主SoC上的移植和優(yōu)化的方法進(jìn)行了分析，通過對虛擬機(jī)中的JNI 機(jī)制進(jìn)行研究，找到了在虛擬機(jī)移植中的關(guān)鍵環(huán)節(jié)，即本地調(diào)用橋(Callbrige)。在滿足了特定架構(gòu)平臺下數(shù)據(jù)類型的對齊要求和特定架構(gòu)下函數(shù)調(diào)用傳參規(guī)則兩個要求后，實(shí)現(xiàn)了本地調(diào)用橋，在測試中發(fā)現(xiàn)Dalvik 虛擬機(jī)有很大的優(yōu)化余地，提出了優(yōu)化方法，解釋器的優(yōu)化最好途徑是用匯編重寫解釋器，同時(shí)對加入即時(shí)(JIT)編譯器的工作量和優(yōu)點(diǎn)，進(jìn)行了初步的探討。

［1］ 韓超，梁泉. Android 系統(tǒng)原理及開發(fā)要點(diǎn)詳解［M］. 北京:電子工業(yè)出版社，2010:64.

［2］ Palo Alto. Google’s Android becomes the World’s Leading Smart Phone Platform［EB/OL］. http://www. canalys. com/pr/2011/r2011013.html，2011－04－25.

［3］ Googe Inc. Dalvik Virture Machine［EB/OL］. http://www. dalvikvm.com，2007.

［4］ Bill Venners，著.曹曉鋼，蔣靖， ，等譯.深入Java 虛擬機(jī)［M］.北京:機(jī)械工業(yè)出版社，2006.

［5］ 周志明. 深入理解Java 虛擬機(jī)［M］. 北京:機(jī)械工業(yè)出版社，2011.

［6］ ARM Information Center［EB/OL］http://infocenter.arm.com.

［7］ 楊豐盛. Android 技術(shù)內(nèi)幕［M］. 北京:機(jī)械工業(yè)出版社，2011:9.

［8］ 李文生，編譯.原理與技術(shù)［M］.北京:清華大學(xué)出版社，2009.