MIDP2.0及其移植技術(shù)分析

關(guān)鍵詞：J2ME MIDP 移植 平臺無(wú)關(guān) 本地代碼

1 MIDP2.0簡(jiǎn)介

隨著(zhù)現代信息化社會(huì )的發(fā)展，小型移動(dòng)通信設備已經(jīng)從最初的一種單純的通信工具轉變成如今集通信、工作、娛樂(lè )等功能為一體的綜合設備；但僅有這些還不能滿(mǎn)足用戶(hù)的要求。個(gè)性永遠是千變萬(wàn)化的，時(shí)尚也不會(huì )始終為一種模式。因此，在移動(dòng)終端上開(kāi)發(fā)通用的、豐富的應用已成為必然的趨勢。這些應用可以按用戶(hù)的意愿隨時(shí)安裝和刪除。

J2ME（JAVA2 Micro Edition）正是這樣一種JAVA應用開(kāi)發(fā)平臺。實(shí)際上，JAVA語(yǔ)言從其誕生起就以其運行的平臺無(wú)關(guān)性這一強大的優(yōu)勢而成為網(wǎng)絡(luò )應用的寵兒。J2ME是JAVA2標準版本的微型版本，專(zhuān)門(mén)為小型移動(dòng)設備所設計。這些設備處理器的處理能力都不強，可使用的資源也有限。因此，J2ME只包含了J2SE中在移動(dòng)通信設備上所必需的功能和組件，使其能夠在移動(dòng)設備及其有限的資源上開(kāi)發(fā)出豐富多彩且平臺無(wú)關(guān)的應用。J2ME在結構上分為CDC（Connecte Device Configuration）和基于其上，以Foundation Profile為主的規范，以及CLDC（Connecte Limited Device Configuration）和基于其上，以MIDP為主的規范。

MIDP（Mobile Information Device Profile）是移信息設備規范的簡(jiǎn)稱(chēng)。規范具體定義了J2ME適用的硬件和軟件框架，并提供了這個(gè)框架要實(shí)現的基本功能及其標準接口；而應用開(kāi)發(fā)者就可以基于這個(gè)框架開(kāi)發(fā)出各種應用。2000年9月，SUN公司發(fā)布了MIDP的第一個(gè)正式版本MIDP1.0。它將J2ME適用的設備定位在至少擁有數百KB RAM和ROM，并具有基本網(wǎng)絡(luò )和顯示功能的移動(dòng)通信設備上；在該基礎上定義了一系列軟件接的移動(dòng)通信設備上；在該上基礎上定義了一系列軟件接口，其中包括基本輸入輸出、圖形化用戶(hù)接口（GUI）、網(wǎng)絡(luò )、事件機制、文件系統、應用管理系統（AMS）等之后，隨著(zhù)JAVA技術(shù)的不斷發(fā)展和用戶(hù)需求的不斷提高，SUN公司又于2002年11月發(fā)布了MIDP2.0。它對設備的內存資源和處理能力的要求較1.0要高，但MIDP2.0也為應用開(kāi)發(fā)者提供了更方便、更豐富多彩的軟件包，主要增加了游戲接口的實(shí)現、聲音輸出接口的實(shí)現安全網(wǎng)絡(luò )機制的實(shí)現。MIDP2.0的這些特性將使基于移動(dòng)設備的JAVA應用具有更加廣闊的前景，也必將使新一代的移動(dòng)設備發(fā)生革命性的變化并領(lǐng)導時(shí)尚潮流。MIDP2.0接口包如表1所列。

表1 MIDP2.0接口包及其功能

2 MIDP2.0的移植

既然MIDP2.0是定位在移動(dòng)通信設備之上的一系列JAVA應用開(kāi)發(fā)接口，我們就必須考慮如何將整個(gè)MIDP系統嵌入到特定的硬件設備和其上的操作系統中。只有這樣，JAVA應用程序才能運行在該設備上，并利用MIDP提供的強大功能將用戶(hù)帶入一個(gè)全新的JAVA世界。在一個(gè)完全不同的操作系統平臺上，用該平臺上對應的系統API調用（或一系列操作），替換MIDP參考實(shí)現中所有與操作平臺相關(guān)的調用（或操作），使MIDP能在目標平臺上正確地執行所有要求的功能；同時(shí)，調用該平臺上特有的能充分發(fā)揮目標設備硬件特性的接口，替換參考實(shí)現中相應的接口，使MIDP能在目標平臺上更高效地運行，這個(gè)過(guò)程就稱(chēng)為MIDP的移植。

MIDP由許多不同的部分組成，每一部分完成MIDP一個(gè)特定的功能接口。其中需要移植的部分主要包括事件處理、文件系統、用戶(hù)圖形化接口、網(wǎng)絡(luò )、AMS、多媒體。它們都分為高端的JAVA層和低端的本地方法層。JAVA層是用JAVA語(yǔ)言實(shí)現的，由KVM解釋執行；因此沒(méi)有涉及到與操作系統平臺相關(guān)的調用和操作，可以不經(jīng)修改就在任何操作平臺上運行，是平臺無(wú)關(guān)的（PlateForm Independent）。它的移植主要是為滿(mǎn)足用戶(hù)的特殊要求而進(jìn)行的個(gè)性化工作。本地方法層（NativeCode）是指為提高代碼的執行效率，保持JAVA語(yǔ)言的平臺無(wú)關(guān)性而使用C語(yǔ)言實(shí)現的部分MIDP功能的代碼。本地即是指它是與當前的操作平臺相關(guān)的，它的移植才是涉及到具體平臺和執行效率而進(jìn)行的具體調用和操作的替換過(guò)程，其結構如圖1所示。

下面，我們就具體到MIDP的每一個(gè)部分的移植進(jìn)行討論。

2.1 事件處理

MIDP的事件處理部分要處理的事件主要來(lái)自?xún)蓚€(gè)方面：①來(lái)自虛擬機底層的事件，如虛擬機的異常消息；②來(lái)自MIDP內部的事件，如屏幕刷新、按鍵消息、觸控筆點(diǎn)擊消息、時(shí)鐘消息等。由于不同的平臺可能使用不同的事件消息獲取和傳遞機制，因此MIDP事件處理的移植也集中在這上面，其實(shí)現被放在本地方法層的文件nativeGUI.c中的函數GetAndStoreKVMEvent中。我們只需根據目標平臺獲取和傳遞事件的要求修改該文件中的相應函數即可。

例如，Windows采用消息響應機制來(lái)處理各種事件，所有消息都可以通過(guò)系統API調用GetMessage獲取，系統會(huì )調用消息處理函數WndProc(HWND hwnd、UINTiMsg、WPARAM wParam、LRARAM 1Param)，在其中處理和傳遞不同的事件。其大致實(shí)現過(guò)程如下：

void

GetAndStoreNextKVMEvent(bool_t forever,ulong64 waitUntil){

MSG msg；

……

while(GetMessage(msg,NULL,0,0)){

……

TranslateMessage(msg);

DispatchMessage(msg);

if(gotEvent){

StoreMIDPEvent(kvmEvent);

Return;

}

}

return;

}

static LRESULT CALLBACK

WndProc (HWND hwnd,UINT iMsg,WPARAM wParam,LPARAM lParam){

……

switch(iMsg){

case WM_CREATE:

……

case WM_KEYDOWN:

case WM_KEYUP:

……

}

}

MIDP在GetAndStoreNextKVMEvent中獲取事件后，就完全獨立地傳遞和處理事件消息，與平臺無(wú)關(guān)，因此無(wú)需移植。

2.2 文件系統

基于MIDP的JAVA應用以及MIDP本身在某些時(shí)候要求數據能夠長(cháng)期保存，即使在應用退出或系統掉電的情況下，數據也不能丟失。這就必須借助于MIDP的文件系統。MIDP的文件系統同樣分為JAVA層（稱(chēng)為RMS，即Record Manage System）和本地方法層。一般情況下，文件系統的JAVA層不用移植就可以在任何平臺上運行，但如果目標平臺的文件系統較為特殊，例如采用數據庫的記錄方式保存數據，甚至根本就沒(méi)有提供高效的數據存取接口，我們就必須自己實(shí)現數據存取接口。這樣，JAVA層就需要跳過(guò)RMS而直接通過(guò)本地方法調用本地接口，相應的RMS的JAVA代碼就可以從MIDP中刪去。

而在文件系統的本地方法層，MIDP會(huì )調用目標平臺的數據存取接口來(lái)實(shí)現MIDP本身的數據存取。這些接口是平臺相關(guān)的，是文件系統中需要移植的部分。這些調用被放在文件src/share/native/storage.c中，主要包括文件的打開(kāi)（open）、文件的關(guān)閉（close）、文件的讀寫(xiě)（read、write）、文件屬性的獲?。╯ize、freesize等）、文件的刪除（delete）、文件的定位（seek）、文件的刪節（truncate）等。以下便是MIDP文件系統在Windows下的部分實(shí)現。

文件的打開(kāi)：

int storageOpen(char**ppszError,char*pszAsciiFilename,int ioMode){

……

handle=open(pszAsciiFilename,flags,creationMode)；

……

}

文件的關(guān)閉：

void storageClose(char**ppszError,int handle){

……

status=close(handle)；

……

}

文件的讀?。?/P>

int storageRead(char**ppszError,int handle,char*buffer,int length)

{

……

bytesRead=read(handle,buffer,length);

……

}

文件的寫(xiě)入：

void storageWrite(char**ppszError,int handle,char*buffer,int length){

……

bytesWritten=write(handle,buffer,length);

……

}

還有許多其它有關(guān)文件的操作，移植時(shí)只需使用目標平臺的API替換以上的Widnows調用，這里就不再逐一列舉。

2.3 用戶(hù)圖形化接口

用戶(hù)圖形化接口包括畫(huà)點(diǎn)、畫(huà)線(xiàn)、作圓、作橢圓、位圖拷貝等基本作圖函數（可在GRAPHICS.C中找到）；有關(guān)定時(shí)器、屏幕刷新和鍵盤(pán)觸控筆消息等有關(guān)與用戶(hù)交互的操作（可在TEXT.C中找到），它是整個(gè)MIDP移植中工作量最大，也是對上層應用的執行效率影響最大的一個(gè)部分。這是因為用戶(hù)在應用中看到的各種圖形和文字都是調用底層的圖形函數在屏幕上作圖的結果。由于屏幕要頻繁刷新，圖形函數也就成為應用調用最多的接口。因此，移植者必須使每一個(gè)底層作圖函數與硬件設備緊密配合起來(lái)，并使用最高效的算法。

在不同的平臺上，能最大地發(fā)揮其作圖功能的函數和算法不盡相，這就要求移植者作大量細致的工作，按照MIDP規范的要求逐一重新實(shí)現每一個(gè)作圖函數和屏幕刷新函 數。下面我們就以將畫(huà)線(xiàn)函數和位圖拷貝函數在Windows上的實(shí)現為例，簡(jiǎn)單說(shuō)明移植要做的工作（鍵盤(pán)、觸控筆是以事件消息的方式實(shí)現的，它們的移植與事件消息的移植相同）。

Windows的畫(huà)線(xiàn)函數接口：

Void LCDUIdrawLine(int pixel,short*clip,void*dst,int dotted,int x1,int y1,int x2,int y2){

……

Polyline(hdc,pts,2);/*繪x1,y1點(diǎn)像素信號*/

……

}

Windwos的屏幕刷新函數：

Void refreshPaintWindow(int x1,int y1,int x2,int y2){

RECT r；

If(x1x2){

r.left=x1+x_offset;r.right=x2+x_offset;

}else{

r.left=x2+x_offset;r.right=x1+x_offset;

}

if(y1y2){

r.top=y1+y_offset;r.bottom=y2+y_offset;

}else{

r.top=y2+y_offset;r.bottom=y1+y_offset；

}

++r.bottom;++r.right;

InvalidateRect(hMainWindow,r,KNI_TRUE);

}

如果目標平臺對這些GUI接口函數有不同實(shí)現法，可以用這些方法替換以上的Windows系統調用，這樣才能使MIDP圖形化用戶(hù)接口正確地工作，并充分發(fā)揮目標平臺的工作效率。

2.4 網(wǎng)絡(luò )

MIDP的網(wǎng)絡(luò )功能是指基于MIDP的J2ME應用可以通過(guò)HTTP等網(wǎng)絡(luò )協(xié)議進(jìn)行下載安裝，不同的MIDlet實(shí)體也可以通過(guò)它交換信息，實(shí)現資源共享。遵循HTTP協(xié)議的規定，移植者必須利用目標平臺的底層網(wǎng)絡(luò )接口重新實(shí)現網(wǎng)絡(luò )的初始化（networkInit）、建立連接（open0）、斷開(kāi)連接（close0）、接收數據（read0）、獲取緩沖區的剩余空間（available0）、關(guān)閉發(fā)送（shutdownOutput）。如果目標設備具有服務(wù)器功能，還要實(shí)現serversocket所有上述功能。所有上述接口都在文件socketProtocol_md.c中實(shí)現。

Windwos中獲取IP地址的實(shí)現：

Int prim_com_sun_midp_io_j2me_socket_Protocol_getIpNumber

(char*host)

{

……

hp=gethostbyname(host);

……

}

如果目標平臺還需要其它網(wǎng)絡(luò )協(xié)議（datagram、comm），其移植過(guò)程與Socket的移植基本相同。

2.5 應用管理系統（AMS）

MIDP的應用管理系統(application management system)負責管理當前設備中安裝的J2ME應用，其功能包括MIDlet的加載、安裝、顯示、更新和刪除。AMS從main.c中的函數main()開(kāi)始執行，根據其輸入初始化一些系統參數，包括系統路徑（classJ2ME MIDP 移植 平臺無(wú)關(guān) 本地代碼）、堆空間大?。╤eapsize）、命令行（command line）等，然后就啟動(dòng)KVM，而KVM就會(huì )從AMS的JAVA界面main.java開(kāi)始解釋執行java代碼。AMS的所有管理功能都是用JAVA語(yǔ)言實(shí)現的，因此AMS的實(shí)現是與平臺無(wú)關(guān)的。但不同的平臺可能有不同的系統參數和格式，對AMS的界面網(wǎng)絡(luò )也可能有不同的要求。所以，移植者有可能要修改main.c中解析系統參數的部分，保證AMS能正確解析目標平臺的所有參數；同時(shí)修改AMS的JAVA層，使其界面網(wǎng)絡(luò )滿(mǎn)足用戶(hù)的需求。

2.6 多媒體

MIDP2.0較MIDP1.0最大的改變就是在MIDP2.0中向應用提供了音頻接口（Audio API）的支持。音頻接口是移動(dòng)設備媒體接口MMAPI（Mobile Media API）的一部分。音頻的播放過(guò)程為5個(gè)部分（unrealized、realized、prefetched、started、closed），同時(shí)它有自己的音頻播放事件的傳道和處理過(guò)程。MIDP音頻播放部分所要做的移植工作就主要集中在聲音播放接口，事件的處理方式和兼容不同的音頻文件格式上。

播放接口的移植：不同的目標平臺，提供的音頻系統API是不同的，有的系統甚至根本沒(méi)有提供播放音頻的API。這時(shí)，移植者就要根據目標平臺的實(shí)現情況替換或自己實(shí)現音頻的播放接口。

Windows的音頻播放接口（win32/native/MMATONE.C）：

Java_javax_microedition_media_Manager_nPlayTone(KNITRAPS)

{

……

chn1=getMidiChnl();

if(chnl==-1){

KNI_ReturnInt(0)；

}

tones[chn].msg=((note0xff)8)|0x00000090|(chnl0xf);

msg=((vol0xff)16)|((note0xff)8)|0x90|(chnl 0xf);

midiOutShortMsg(midiOut,msg);

timerID=timeSetEvent(dur,TIMERES,(LPTIME CALLBACK)timeToneProc,(DWORD)chnl,TIME_ONESHOT);

tones[chnl].timerID=timerID;

……

}

事件傳遞的移植：MIDP中音頻播放結束的事件（EOM）是專(zhuān)門(mén)通過(guò)系統的消息機制傳遞，而不是通過(guò)MIDP的事件傳遞，因此也需要移植：

Windows---OM的傳遞（win32/native/MMAEVT.C）:void injectNativeEvent(int pID,int curMTime){

PostMessage(hMain Window,WM_APP,(WPARAM)(pID),(LPARAM)(curMTime));

return;

}

3 總結

綜上所述，MID2.0的移植要以?xún)蓚€(gè)方面為出發(fā)點(diǎn)：①兼容性。移植后的MIDP實(shí)現必須能夠在目標平臺上正常運行，所有與目標平臺不兼容的調用都必須替換為能完成相同功能且兼容的目標平臺的系統調用或過(guò)程。②高效性。移植后的MIDP實(shí)現必須能充分發(fā)揮目標平臺的效率和特性，用最小的代價(jià)完成MIDP的功能。另外，MIDP的移植還要分滿(mǎn)足最終用戶(hù)的個(gè)性化要求，為它們設計出豐富多彩的界面網(wǎng)絡(luò )。