淺析Java卡應(yīng)用執(zhí)行機(jī)制及虛擬機(jī)能效優(yōu)化

崔巖 盧麗敏

【摘要】 面對(duì)日益增多的Java卡應(yīng)用，不同智能卡廠家開(kāi)發(fā)的Java卡在使用過(guò)程中表現(xiàn)出參差不齊的執(zhí)行效率。通過(guò)對(duì)Java卡系統(tǒng)體系和實(shí)現(xiàn)方法研究發(fā)現(xiàn)，Java卡的執(zhí)行能效受整體硬件（CPU、RAM、FLASH等）、軟件（Java卡虛擬機(jī)和Java應(yīng)用）條件所影響，但基于實(shí)際的市場(chǎng)環(huán)境，一味提升卡片硬件性能和約束開(kāi)發(fā)方的應(yīng)用編寫(xiě)習(xí)慣，都不是一個(gè)可行、有效的提高運(yùn)行效率的方法。因此本文將通過(guò)解析一個(gè)簡(jiǎn)單Java卡應(yīng)用實(shí)例是如何被Java卡虛擬機(jī)解析及執(zhí)行的過(guò)程，來(lái)探討優(yōu)化Java卡虛擬機(jī)執(zhí)行效率的簡(jiǎn)單思

【關(guān)鍵詞】 JAVA卡 虛擬機(jī) 執(zhí) 行能效 優(yōu)化

一、引言

自2010年國(guó)內(nèi)運(yùn)營(yíng)商開(kāi)始逐漸使用搭載Java虛擬機(jī)的智能卡產(chǎn)品至今已超過(guò)5年之久，累計(jì)產(chǎn)品發(fā)行量過(guò)億張。同時(shí)，伴隨近年來(lái)移動(dòng)支付的蓬勃發(fā)展，越來(lái)越多的Java卡應(yīng)用如雨后春筍般出現(xiàn)并應(yīng)用在Java智能卡中，使重多用戶享受到Java智能卡及應(yīng)用的便利，那么這些Java應(yīng)用是如何在Java智能卡上運(yùn)行的？以及如何提升Java卡核心——Java卡虛擬機(jī)的執(zhí)行能效，將是本文向大家闡述的重點(diǎn)內(nèi)容。

二、Java卡及Java卡應(yīng)用

2.1為什么要使用Java卡？

ORACLE公司的Java編程語(yǔ)言已逐漸成為除Microsoft公司的c語(yǔ)言體系之外，另一種主流的商業(yè)軟件開(kāi)發(fā)語(yǔ)言。其崛起與發(fā)展如此迅猛，既有Java作為開(kāi)發(fā)語(yǔ)言本身所具備的諸多優(yōu)勢(shì)，也與Java體系開(kāi)發(fā)成本低、易于部署等諸多特點(diǎn)息息相關(guān)。Java語(yǔ)言訴求實(shí)現(xiàn)“應(yīng)用與平臺(tái)無(wú)關(guān)系性”——將上層應(yīng)用與底層平臺(tái)（操作系統(tǒng)及硬件）剝離開(kāi)，以實(shí)現(xiàn)“一次編寫(xiě)，任意運(yùn)行（write once， run anywhere）”的愿景，為了達(dá)到這一目標(biāo)，ORACLE公司提出了Java虛擬機(jī)的概念，并將其應(yīng)用于多個(gè)系統(tǒng)平臺(tái)，取得了巨大成功。

Java語(yǔ)言這種應(yīng)用只需經(jīng)過(guò)一次編譯，就可在任意軟硬件平臺(tái)中運(yùn)行的特質(zhì)，十分符合現(xiàn)今電信智能卡應(yīng)用的開(kāi)發(fā)需求。眾所周知，傳統(tǒng)的電信智能卡應(yīng)用多為電信增值業(yè)務(wù)，數(shù)量少，功能簡(jiǎn)單，由智能卡制造商根據(jù)自身產(chǎn)品的硬件及卡片操作系統(tǒng)（COS）以Native的形式開(kāi)發(fā)實(shí)現(xiàn)。而由于各廠家的應(yīng)用互不兼容，無(wú)法交互使用，因此一個(gè)應(yīng)用需要所有卡片制造商都進(jìn)行開(kāi)發(fā)，消耗巨大的開(kāi)發(fā)、調(diào)試及維護(hù)成本。而隨著移動(dòng)支付領(lǐng)域的迅猛發(fā)展，電信智能卡上需承載越來(lái)越多的第三方應(yīng)用，這些應(yīng)用需求多樣，功能復(fù)雜，且多是由第三方（如銀行等金融機(jī)構(gòu)）開(kāi)發(fā)，無(wú)法繼續(xù)沿用傳統(tǒng)電信智能卡應(yīng)用的native開(kāi)發(fā)模式，于是Java卡的出現(xiàn)完美的解決了這個(gè)問(wèn)題。

2.2 Java Applet是如何在Java虛擬機(jī)上運(yùn)行的？

基于Java卡環(huán)境下的應(yīng)用開(kāi)發(fā)模式與其他高級(jí)語(yǔ)言平臺(tái)開(kāi)發(fā)模式基本類(lèi)似——應(yīng)用的開(kāi)發(fā)方只需考慮如何使應(yīng)用更好的實(shí)現(xiàn)功能，帶給用戶更佳的使用體驗(yàn)，而不必關(guān)心應(yīng)用將裝載在哪個(gè)平臺(tái)，該如何兼顧平臺(tái)的特性。這些問(wèn)題統(tǒng)統(tǒng)交由Java卡虛擬機(jī)來(lái)解決。因此在這種模式下，應(yīng)用開(kāi)發(fā)商只需要開(kāi)發(fā)一版Java卡應(yīng)用（以下稱(chēng)為Java Applet），就可以裝載并運(yùn)行在任意一張搭載了Java卡虛擬機(jī)的智能卡中。

每一個(gè)Java Applet從編寫(xiě)到最終在卡片中運(yùn)行，需要經(jīng)過(guò)以下幾個(gè)步驟：

1.開(kāi)發(fā)者通過(guò)特有的開(kāi)發(fā)環(huán)境，使用Java語(yǔ)言編寫(xiě)源代碼（.Java文件），

2.將Java源碼編譯成字節(jié)碼（.class文件）。字節(jié)碼是是一種Java體系特有的代碼形式，它具有一定的可讀性，并可被Java虛擬機(jī)解析并執(zhí)行。

3.編譯好的字節(jié)碼需要與對(duì)應(yīng)的exp文件配合，通過(guò)轉(zhuǎn)換器轉(zhuǎn)換為cap文件，

4.通過(guò)讀卡器或者空中通道，下載到Java卡上，安裝、實(shí)例化后才可正常使用。

5.當(dāng)這個(gè)應(yīng)用被選擇執(zhí)行時(shí)，卡片的Java運(yùn)行時(shí)找到該應(yīng)用的虛擬機(jī)機(jī)器碼對(duì)應(yīng)的存儲(chǔ)位置，并將其載入Java虛擬機(jī)進(jìn)行解析、執(zhí)行。

在這整套復(fù)雜的過(guò)程中，有以下兩個(gè)最重要的環(huán)境：

A.class文件被轉(zhuǎn)換成.cap文件的過(guò)程

該過(guò)程主要是將class文件的字節(jié)碼轉(zhuǎn)換成可被Java卡虛擬機(jī)識(shí)別并執(zhí)行的虛擬機(jī)代碼。由于ORACLE公司在JCVM規(guī)范中明確規(guī)定了Java虛擬機(jī)所支持的所有指令集，因此這是一個(gè)標(biāo)準(zhǔn)的轉(zhuǎn)換過(guò)程。

B.cap文件下載到卡片中的過(guò)程

該過(guò)程主要是卡商自身實(shí)現(xiàn)的Java運(yùn)行時(shí)對(duì)cap的解析和轉(zhuǎn)譯過(guò)程，由于ORACLE公司僅在相關(guān)規(guī)范中只規(guī)定cap文件的內(nèi)容，但未規(guī)定其在卡片內(nèi)部的存儲(chǔ)結(jié)構(gòu)和格式，因此這是一個(gè)非標(biāo)的處理過(guò)程，各智能卡制造商根據(jù)自身的Java卡設(shè)計(jì)情況將cap文件進(jìn)行解析，并按各自Java卡實(shí)現(xiàn)所設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu)，拆解、組合成私有格式，存儲(chǔ)在卡上。

三、Java卡運(yùn)算能效因素及優(yōu)化方向

3.1影響Java卡運(yùn)算能效的因素

Java卡是相對(duì)比較復(fù)雜的電信智能卡產(chǎn)品，其具備較強(qiáng)大的擴(kuò)展性和靈活的移植性。它在傳統(tǒng)的電信智能卡軟、硬件環(huán)境基礎(chǔ)上，增加一層Java卡虛擬機(jī)和Java運(yùn)行環(huán)境，所有的Java應(yīng)用需要加載到這套Java卡運(yùn)行環(huán)境中才能正常運(yùn)行。因此其運(yùn)算性能受制于整套智能卡軟、硬件條件。具體影響Java卡的運(yùn)算能效的因素包括以下幾點(diǎn)：

硬件層面：

CPU位數(shù)及主頻

RAM容量

Flash讀寫(xiě)速度

安全算法協(xié)處理器支持情況

軟件層面：

Java虛擬機(jī)性能

Applet源碼性能

3.2探尋Java卡性能優(yōu)化的方向

一張Java卡產(chǎn)品的運(yùn)算能效受其軟、硬件環(huán)境的共同影響，理論上，更換更強(qiáng)大的卡片硬件環(huán)境，如更快cpu，更大的RAM空間或讀寫(xiě)更快的Flash存儲(chǔ)器等，都可從根本上提升該Java卡的運(yùn)算能效。同時(shí)，對(duì)Java apple源代碼的編寫(xiě)方式進(jìn)行優(yōu)化，使用更科學(xué)的算法設(shè)計(jì)方法，優(yōu)化代碼執(zhí)行流程，更有規(guī)律性、計(jì)劃性的執(zhí)行高耗時(shí)操作等，也可直接提升該應(yīng)用的執(zhí)行效率。

但從市場(chǎng)化的角度考慮，智能卡制造商對(duì)產(chǎn)品的硬件選型需要考慮成本和利潤(rùn)，在一定時(shí)期內(nèi)，其使用在Java卡產(chǎn)品平臺(tái)上的電信智能卡芯片硬件性能是固定的。而另一方面，Java卡相較傳統(tǒng)native電信智能卡，其設(shè)計(jì)初衷就是提高產(chǎn)品的開(kāi)放性和開(kāi)發(fā)效率，將卡片實(shí)體生產(chǎn)者和卡片應(yīng)用開(kāi)發(fā)者分離，因此在Java卡環(huán)境下Applet的開(kāi)發(fā)必然是離散形式，開(kāi)發(fā)方并不可控，因此從Applet的編寫(xiě)角度提出優(yōu)化要求并不可行。因此，Java卡產(chǎn)品性能可行、有效且可控的優(yōu)化方向，應(yīng)該是從電信智能卡制造商的Java虛擬機(jī)執(zhí)行效能優(yōu)化提升方向入手。

四、Java卡虛擬機(jī)的優(yōu)化分析

4.1 Java虛擬機(jī)執(zhí)行Applet原理解析

研究如何優(yōu)化Java卡虛擬機(jī)的執(zhí)行效率，就需要弄清Java卡虛擬機(jī)是如何解析執(zhí)行Java Applet的。我們以下面這個(gè)簡(jiǎn)單的“HelloWorld”應(yīng)用作為示例，解析Java虛擬機(jī)如何執(zhí)行這個(gè)Applet的，以下是“HelloWorld”應(yīng)用的源代碼：

package com.HelloWorld；

import Javacard.fRAMework.*；

public class HelloWorld extends Applet

{

public static byte[] echoBytes；

private static final short LENGTH_ECHO_BYTES = 256；

public static final byte[] HelloWorld = {

//hello world

（byte）0x80， （byte）0x48， （byte）0x65， （byte）0x6c，（byte）0x6c， （byte）0x6f， （byte）0x57， （byte）0x6f， （byte）0x72，（byte）0x6c， （byte）0x64， （byte）0x53， （byte）0x05

}；

protected HelloWorld（）

{

echoBytes = new byte[LENGTH_ECHO_BYTES]；

register（）；

}

public static void install（byte[] bArray， short bOffset， byte bLength）

{

new HelloWorld（）；

}

public void process（APDU apdu）

{

byte buffer[] = apdu.getBuffer（）；

Util.arrayCopyNonAtomic（buffer， ISO7816.OFFSET_CDATA， HelloWorld， （short）0， （short）HelloWorld.length）；

apdu.setOutgoingAndSend（ （short） ISO7816.OFFSET_ CDATA， （short）HelloWorld.length ）；

}

}

這是一個(gè)最簡(jiǎn)單的Java應(yīng)用，主要實(shí)現(xiàn)的作用是：當(dāng)該應(yīng)用被選擇執(zhí)行后，應(yīng)用向卡外設(shè)備返回“HelloWorld”字符串。

這個(gè)Applet的源碼被編譯并轉(zhuǎn)換后生成了該應(yīng)用的cap文件，cap文件是一種壓縮格式文件，對(duì)其解壓縮后，可以看到它是由以下12個(gè)組件（component）組成：

每個(gè)組件都是一個(gè)表單格式的數(shù)據(jù)結(jié)構(gòu)，各自描述了這個(gè)Java應(yīng)用的某方面信息，我們可以通過(guò)讀卡器或空中下載通道，將這個(gè)cap下載到卡片中，并安裝執(zhí)行。

下載到Java卡后，當(dāng)該Applet被執(zhí)行時(shí)，Java虛擬機(jī)會(huì)執(zhí)行以下操作：

A.讀取cap文件中的Method.cap，下面為cap文件的內(nèi)容：

01 bit[4] flags bit[4] max_stack

10 bit[4] nargs bit[4] max_locals

18 8C 00 00 11 01 00 90 0B 7F 00 01 18 8B 00 02 7A 02 30 8F 00 03 3D 8C 00 04 3B 7A 05 21 19 8B 00 05 2D 1A 08 7B 00 06 03 7B 00 06 92 8D 00 07 3B 19 08 7B 00 06 92 8B 00 08 7A bytecodes

B.載入其中的process函數(shù)的字節(jié)碼并執(zhí)行。

如下為Method comm Component中process函數(shù)的字節(jié)碼：

05 21 19 8B 00 05 2D 1A 08 7B 00 06 03 7B 00 06 92 8D 00 07 3B 19 08 7B 00 06 92 8B 00 08 7A

這些字節(jié)碼實(shí)際是一條一條Java虛擬機(jī)指令，具體的字節(jié)碼分析如下：

05 flags： maxStack=5

21 nargs=2 maxLocals=1

19 aload_1

8B 00 05 invokevirtual

2D astore_2

1A aload_2

08 sconst_5

7B 00 06 getstatic_a

03 sconst_0

7B 00 06 getstatic_a

92 arraylength

8D 00 07 invokestatic

3B pop

19 aload_1

08 sconst_5

7B 00 06 getstatic_a

92 arraylength

8B 00 08 invokevirtual

7A return

對(duì)這些字節(jié)碼進(jìn)行解析可以發(fā)現(xiàn)，在執(zhí)行這個(gè)process函數(shù)時(shí)，大致的過(guò)程主要是通過(guò)getstatic_a獲取數(shù)據(jù)，并通過(guò)astore_2、aload_2、sconst_5等堆棧操作函數(shù)將數(shù)據(jù)放入堆棧，在通過(guò)invokestatic函數(shù)的調(diào)用相應(yīng)的方法對(duì)堆棧中的數(shù)據(jù)進(jìn)行運(yùn)算，最后通過(guò)pop將結(jié)果彈棧輸出結(jié)果，

對(duì)于堆棧的操作，由于緩存數(shù)據(jù)在芯片的RAM中操作，RAM的讀寫(xiě)速度遠(yuǎn)遠(yuǎn)大于Flash存儲(chǔ)域，因此上述操作中涉及堆棧操作的執(zhí)行速度會(huì)很快，對(duì)Java卡虛擬機(jī)執(zhí)行效率的影響也微乎其微。

而對(duì)于獲取數(shù)據(jù)和調(diào)用方法的操作，則需要根據(jù)其指令后面的參數(shù)進(jìn)一步執(zhí)行相關(guān)操縱，例如getstatic_a類(lèi)和invokestatic類(lèi)指令：

7B （getstatic_a函數(shù)） 00 06（參數(shù)）

8D （invokestatic函數(shù)）00 07（參數(shù)）

這兩個(gè)指令的參數(shù)實(shí)際標(biāo)示了該信息在Constant Pool（以下簡(jiǎn)稱(chēng)CP） Component中的位置。CP中主要存儲(chǔ)了整個(gè)Applet中所有類(lèi)、方法和域的入口信息。對(duì)”Hello World”應(yīng)用的CP內(nèi)容進(jìn)行解析如下：

05 tag

00 26 size

00 09 count

06 80 03 00 cp_info1

05 00 00 02 cp_info2

03 80 03 01 cp_info3

01 00 02 00 cp_info4

06 00 00 01 cp_info5

03 80 0A 01 cp_info6

05 00 00 00 cp_info7

06 80 10 02 cp_info8

03 80 0A 08 cp_info9

其中每條cp_info是一個(gè)常量成員的內(nèi)容信息，其結(jié)構(gòu)如下：

cp_info{

u1 tag

u1 info（3）}

由于Get類(lèi)和invoke類(lèi)指令的參數(shù)的結(jié)構(gòu)不同，因此這兩種函數(shù)在CP中獲取進(jìn)一步常量信息的流程也不相同，下面從”Hello World”應(yīng)用的process函數(shù)中分別挑選一個(gè)Get類(lèi)和一個(gè)invoke類(lèi)函數(shù)，闡述一下各自的執(zhí)行流程：

4.1.1 getstatic_a指令

7B 00 06 getstatic_a

00 06表現(xiàn)需要獲取的靜態(tài)數(shù)據(jù)在cp中的位置為“0006”，由于cp中成員index從0000開(kāi)始，因此此處表示需要獲取cp_info7的內(nèi)容“05 00 00 00”。其中“05”表示這是一個(gè)“CONSTANT_StaticFieldref”，即后續(xù)的內(nèi)容在Static Field Component中，其后面第一個(gè)”00 ”表示這是一個(gè)內(nèi)部地址，后二個(gè)“00”表示其在Static Field Component中的index。對(duì)”Hello World”應(yīng)用的Static Field Component內(nèi)容進(jìn)行解析如下：

08 tag

00 1A size

00 04 image_size

00 02 reference_count

00 01 array_init_count

03 type

00 0D count

80 48 65 6C 6C 6F 57 6F 72 6C 64 53 05 要讀取的數(shù)據(jù)

00 00 default_value_count

00 00 non_default_value_count

這里根據(jù)cp中的入口地址找到，需要調(diào)用的常量?jī)?nèi)容“80 48 65 6C 6C 6F 57 6F 72 6C 64 53 05”，即”Hello World”這段字符Unicode碼的數(shù)值。

至此可以看到，根據(jù)method component中解析出需執(zhí)行的虛擬機(jī)指令getstatic_a及其參數(shù)（7B 00 06），最終找到了需要獲取的常量數(shù)據(jù)。

4.1.2 invokestatic指令

8D 00 07（invokestatic）

00 07表示需要獲取的靜態(tài)數(shù)據(jù)在cp中的位置為“0007”，即cp_info8的內(nèi)容“06 80 10 02 ”，其中“06”表示這是一個(gè)“CONSTANT_StaticMethodref”，“80”表示這個(gè)是一個(gè)外部的方法，且包的id是“00”，“10”表示這個(gè)方法是引用的class_token，而最后的“02”是這個(gè)方法的token。連貫起來(lái)理解，就這此處需要調(diào)用的方法是token為00的package下token為10的class中的“02”方法。

由于這條invoke指令調(diào)用的是一個(gè)外部的方法，所以需要到Import Component找到該方法歸屬的package aid，以下是”Hello World”應(yīng)用的Import Component內(nèi)容：

04 tag

00 0B size

01 count

04 minor_version

01 major_version

07 AID_length

A0 00 00 00 62 01 01 AID

由此可以獲知該方法歸屬的包的aid為“A0 00 00 00 62 01 01”，即Javacard.fRAMework包，此時(shí)需要以此aid為檢索條件尋找到該包的export文件，并在其中找到對(duì)應(yīng)的方法、完成調(diào)用。

而如果調(diào)用的是一個(gè)靜態(tài)方法，如invoke的參數(shù)在cp中的內(nèi)容為06 00 00 01，則其中“06”為CONSTANT_ StaticMethodref的tag，第二個(gè)字節(jié)“00”表示這是引用一個(gè)內(nèi)部的靜態(tài)方法，需要到method component中引用該方法，最后兩個(gè)字節(jié)“00 01”代表引用的方法在method component中的偏移地址。此時(shí)Java卡虛擬機(jī)需要再次載入method component表單，并根據(jù)偏移位置載入相應(yīng)的虛擬機(jī)機(jī)器碼，完成方法調(diào)用。

4.2 Java卡虛擬機(jī)優(yōu)化方法

從上面的分析來(lái)看，不管Java卡虛擬機(jī)在實(shí)現(xiàn)getstatic_ a指令或者invokestatic指令時(shí)，都需要載入、解析和檢索cap文件中的多個(gè)數(shù)據(jù)表單。而Java虛擬機(jī)操作對(duì)象的類(lèi)型不同，還支持其他的getxxx和invokexxx指令，他們的執(zhí)行流程與getstatic_a指令和invokestatic指令相同。我們可以將這些指令抽象成GET類(lèi)指令和invoke類(lèi)指令，并統(tǒng)一進(jìn)行優(yōu)化。

回顧上述這兩類(lèi)指令執(zhí)行過(guò)程的分析：

Get類(lèi)指令的實(shí)現(xiàn)過(guò)程需要分別解析Method Component 、Constant Pool Component和Static Field Component三張數(shù)據(jù)表單。

而invoke指令的執(zhí)行過(guò)程更加復(fù)雜，如果是調(diào)用的是內(nèi)部方法，則需要解析Method Component （2次）和Constant Pool Component，而如果要調(diào)用的是外部方法，還需要多解析一次Import Component以及調(diào)用的包內(nèi)的Method Component 和Constant Pool Component。

上述所有的component的內(nèi)容都存儲(chǔ)在Flash存儲(chǔ)單元中，讀取和解析工作需要多次的Flash讀取和擦寫(xiě)操作，雖然單純從一條虛擬機(jī)指令的執(zhí)行過(guò)程中來(lái)看，耗時(shí)還可接受，但在整個(gè)Applet的執(zhí)行過(guò)程中，會(huì)出現(xiàn)上述成千上萬(wàn)次的虛擬機(jī)指令的執(zhí)行，以及與之對(duì)應(yīng)的、且成倍增加的Flash讀寫(xiě)過(guò)程，如此積沙成塔，必然會(huì)拖累Applet整體的執(zhí)行速度。因此我們認(rèn)為針對(duì)此類(lèi)API優(yōu)化方法的基本思路是：

減少API執(zhí)行階段對(duì)多個(gè)component的讀取和解析操作，以實(shí)現(xiàn)降低執(zhí)行過(guò)程中Flash存儲(chǔ)器讀寫(xiě)操作頻率的目的。

為了實(shí)現(xiàn)這樣的目標(biāo)，我們建議：

將原本在Applet執(zhí)行階段的component解析操作，提前到Applet的其他生命周期，并將解析的結(jié)果——被引用成員變量或方法的絕對(duì)地址作為參數(shù)放置method component的Get和invoke指令后面。

這樣在Applet執(zhí)行的過(guò)程中，每次執(zhí)行此類(lèi)函數(shù)的速度將大大提高。

下面的問(wèn)題是：什么時(shí)間點(diǎn)才是執(zhí)行絕對(duì)地址解析的最佳觸發(fā)點(diǎn)？這個(gè)觸發(fā)點(diǎn)應(yīng)該符合以下2個(gè)條件：

1.在整個(gè)Applet的生命周期中執(zhí)行頻率相對(duì)最低；

2.在這個(gè)時(shí)間點(diǎn)執(zhí)行絕對(duì)地址解析對(duì)用戶的感知影響最小。

綜合考慮上述兩個(gè)條件，我們建議在Applet下載到卡片后，進(jìn)行實(shí)例化的過(guò)程中進(jìn)行絕對(duì)地址的解析操作。由于實(shí)例化操作在Applet的整體生命周期中僅會(huì)執(zhí)行一次，同時(shí)，該執(zhí)行過(guò)程一般是由應(yīng)用的安裝方發(fā)起，對(duì)最終用的使用感知基本沒(méi)有影響。

通過(guò)上述方法對(duì)Java虛擬機(jī)字節(jié)碼的執(zhí)行方法進(jìn)行優(yōu)化，以實(shí)現(xiàn)Java虛擬機(jī)對(duì)Java API執(zhí)行效率的提升。

五、結(jié)論

通過(guò)前文的論述，我們不難發(fā)現(xiàn)，由于受制于現(xiàn)有Java卡硬件水平的限制，不可能將所有的數(shù)據(jù)放置在RAM中操作，所以大部分?jǐn)?shù)據(jù)仍只能儲(chǔ)存在Flash存儲(chǔ)器中，而Flash存儲(chǔ)器的操作速度要遠(yuǎn)遠(yuǎn)低于RAM存儲(chǔ)器，因此在一定硬件條件基礎(chǔ)下，影響Java API的執(zhí)行效率的關(guān)鍵因素就是——Flash存儲(chǔ)器讀寫(xiě)速度慢這一Java卡的硬件瓶頸，而這也是我們對(duì)Java卡虛擬機(jī)能效優(yōu)化的主要著力點(diǎn)。由此我們可以總結(jié)出優(yōu)化Java卡虛擬機(jī)運(yùn)行能效，提高Java應(yīng)用執(zhí)行速度的根本方法——減少API執(zhí)行階段對(duì)多個(gè)component的讀取和解析操作，將解析操作提前到Applet實(shí)例化階段，并以被引用成員變量或方法的絕對(duì)地址作為參數(shù)放置method component的Get和invoke指令后面進(jìn)行解析執(zhí)行。

參 考 文 獻(xiàn)

[1]《Virtual Machine Specification Version 3.0.1 Classic Edition》

[2]《Runtime Environment Specification Version 3.0.1 Classic Edition》

[3]《Inside the Java Virtual Machine， Second Edition》

[4]《深入理解Java虛擬機(jī)——JVM高級(jí)特性與最佳實(shí)踐》