MIDP2.0及其移植技術(shù)分析
加入技術(shù)交流群
關(guān)鍵詞：J2ME MIDP 移植 平臺無關(guān) 本地代碼
1 MIDP2.0簡介
隨著現(xiàn)代信息化社會的發(fā)展，小型移動通信設(shè)備已經(jīng)從最初的一種單純的通信工具轉(zhuǎn)變成如今集通信、工作、娛樂等功能為一體的綜合設(shè)備；但僅有這些還不能滿足用戶的要求。個(gè)性永遠(yuǎn)是千變?nèi)f化的，時(shí)尚也不會始終為一種模式。因此，在移動終端上開發(fā)通用的、豐富的應(yīng)用已成為必然的趨勢。這些應(yīng)用可以按用戶的意愿隨時(shí)安裝和刪除。
J2ME（JAVA2 Micro Edition）正是這樣一種JAVA應(yīng)用開發(fā)平臺。實(shí)際上，JAVA語言從其誕生起就以其運(yùn)行的平臺無關(guān)性這一強(qiáng)大的優(yōu)勢而成為網(wǎng)絡(luò)應(yīng)用的寵兒。J2ME是JAVA2標(biāo)準(zhǔn)版本的微型版本，專門為小型移動設(shè)備所設(shè)計(jì)。這些設(shè)備處理器的處理能力都不強(qiáng)，可使用的資源也有限。因此，J2ME只包含了J2SE中在移動通信設(shè)備上所必需的功能和組件，使其能夠在移動設(shè)備及其有限的資源上開發(fā)出豐富多彩且平臺無關(guān)的應(yīng)用。J2ME在結(jié)構(gòu)上分為CDC（Connecte Device Configuration）和基于其上，以Foundation Profile為主的規(guī)范，以及CLDC（Connecte Limited Device Configuration）和基于其上，以MIDP為主的規(guī)范。
MIDP（Mobile Information Device Profile）是移信息設(shè)備規(guī)范的簡稱。規(guī)范具體定義了J2ME適用的硬件和軟件框架，并提供了這個(gè)框架要實(shí)現(xiàn)的基本功能及其標(biāo)準(zhǔn)接口；而應(yīng)用開發(fā)者就可以基于這個(gè)框架開發(fā)出各種應(yīng)用。2000年9月，SUN公司發(fā)布了MIDP的第一個(gè)正式版本MIDP1.0。它將J2ME適用的設(shè)備定位在至少擁有數(shù)百KB RAM和ROM，并具有基本網(wǎng)絡(luò)和顯示功能的移動通信設(shè)備上；在該基礎(chǔ)上定義了一系列軟件接的移動通信設(shè)備上；在該上基礎(chǔ)上定義了一系列軟件接口，其中包括基本輸入輸出、圖形化用戶接口（GUI）、網(wǎng)絡(luò)、事件機(jī)制、文件系統(tǒng)、應(yīng)用管理系統(tǒng)（AMS）等之后，隨著JAVA技術(shù)的不斷發(fā)展和用戶需求的不斷提高，SUN公司又于2002年11月發(fā)布了MIDP2.0。它對設(shè)備的內(nèi)存資源和處理能力的要求較1.0要高，但MIDP2.0也為應(yīng)用開發(fā)者提供了更方便、更豐富多彩的軟件包，主要增加了游戲接口的實(shí)現(xiàn)、聲音輸出接口的實(shí)現(xiàn)安全網(wǎng)絡(luò)機(jī)制的實(shí)現(xiàn)。MIDP2.0的這些特性將使基于移動設(shè)備的JAVA應(yīng)用具有更加廣闊的前景，也必將使新一代的移動設(shè)備發(fā)生革命性的變化并領(lǐng)導(dǎo)時(shí)尚潮流。MIDP2.0接口包如表1所列。
表1 MIDP2.0接口包及其功能
| 包 | 功 能 |
| javax.microedition.lcdui | 提供一系列用戶界面接口 |
| javax.microedition.lcdui.game | 專門用于游戲設(shè)計(jì)的接口 |
| javax.microedition.rms | 數(shù)據(jù)管理，用于保存數(shù)據(jù)記錄 |
| javax.microedition.midlet | JAVA應(yīng)用管理接口 |
| javax.microedition.io | 基本網(wǎng)絡(luò)連接接口 |
| javax.microedition.media | 媒體接口規(guī)范（JSR-135）的實(shí)現(xiàn)包 |
| javax.microedition.media.control | 媒體播放器的控制類 |
| javax.microedition.pki | 數(shù)字簽名規(guī)范的實(shí)現(xiàn)接口（用于安全網(wǎng)絡(luò)） |
| java.io | JAVA基本輸入輸出接口 |
| java.lang | JAVA基本數(shù)據(jù)類型接口 |
| java.util | JAVA基本應(yīng)用接口 |
2 MIDP2.0的移植
既然MIDP2.0是定位在移動通信設(shè)備之上的一系列JAVA應(yīng)用開發(fā)接口，我們就必須考慮如何將整個(gè)MIDP系統(tǒng)嵌入到特定的硬件設(shè)備和其上的操作系統(tǒng)中。只有這樣，JAVA應(yīng)用程序才能運(yùn)行在該設(shè)備上，并利用MIDP提供的強(qiáng)大功能將用戶帶入一個(gè)全新的JAVA世界。在一個(gè)完全不同的操作系統(tǒng)平臺上，用該平臺上對應(yīng)的系統(tǒng)API調(diào)用（或一系列操作），替換MIDP參考實(shí)現(xiàn)中所有與操作平臺相關(guān)的調(diào)用（或操作），使MIDP能在目標(biāo)平臺上正確地執(zhí)行所有要求的功能；同時(shí)，調(diào)用該平臺上特有的能充分發(fā)揮目標(biāo)設(shè)備硬件特性的接口，替換參考實(shí)現(xiàn)中相應(yīng)的接口，使MIDP能在目標(biāo)平臺上更高效地運(yùn)行，這個(gè)過程就稱為MIDP的移植。
MIDP由許多不同的部分組成，每一部分完成MIDP一個(gè)特定的功能接口。其中需要移植的部分主要包括事件處理、文件系統(tǒng)、用戶圖形化接口、網(wǎng)絡(luò)、AMS、多媒體。它們都分為高端的JAVA層和低端的本地方法層。JAVA層是用JAVA語言實(shí)現(xiàn)的，由KVM解釋執(zhí)行；因此沒有涉及到與操作系統(tǒng)平臺相關(guān)的調(diào)用和操作，可以不經(jīng)修改就在任何操作平臺上運(yùn)行，是平臺無關(guān)的（PlateForm Independent）。它的移植主要是為滿足用戶的特殊要求而進(jìn)行的個(gè)性化工作。本地方法層（NativeCode）是指為提高代碼的執(zhí)行效率，保持JAVA語言的平臺無關(guān)性而使用C語言實(shí)現(xiàn)的部分MIDP功能的代碼。本地即是指它是與當(dāng)前的操作平臺相關(guān)的，它的移植才是涉及到具體平臺和執(zhí)行效率而進(jìn)行的具體調(diào)用和操作的替換過程，其結(jié)構(gòu)如圖1所示。
下面，我們就具體到MIDP的每一個(gè)部分的移植進(jìn)行討論。
2.1 事件處理
MIDP的事件處理部分要處理的事件主要來自兩個(gè)方面：①來自虛擬機(jī)底層的事件，如虛擬機(jī)的異常消息；②來自MIDP內(nèi)部的事件，如屏幕刷新、按鍵消息、觸控筆點(diǎn)擊消息、時(shí)鐘消息等。由于不同的平臺可能使用不同的事件消息獲取和傳遞機(jī)制，因此MIDP事件處理的移植也集中在這上面，其實(shí)現(xiàn)被放在本地方法層的文件nativeGUI.c中的函數(shù)GetAndStoreKVMEvent中。我們只需根據(jù)目標(biāo)平臺獲取和傳遞事件的要求修改該文件中的相應(yīng)函數(shù)即可。
例如，Windows采用消息響應(yīng)機(jī)制來處理各種事件，所有消息都可以通過系統(tǒng)API調(diào)用GetMessage獲取，系統(tǒng)會調(diào)用消息處理函數(shù)WndProc(HWND hwnd、UINTiMsg、WPARAM wParam、LRARAM 1Param)，在其中處理和傳遞不同的事件。其大致實(shí)現(xiàn)過程如下：
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中獲取事件后，就完全獨(dú)立地傳遞和處理事件消息，與平臺無關(guān)，因此無需移植。
2.2 文件系統(tǒng)
基于MIDP的JAVA應(yīng)用以及MIDP本身在某些時(shí)候要求數(shù)據(jù)能夠長期保存，即使在應(yīng)用退出或系統(tǒng)掉電的情況下，數(shù)據(jù)也不能丟失。這就必須借助于MIDP的文件系統(tǒng)。MIDP的文件系統(tǒng)同樣分為JAVA層（稱為RMS，即Record Manage System）和本地方法層。一般情況下，文件系統(tǒng)的JAVA層不用移植就可以在任何平臺上運(yùn)行，但如果目標(biāo)平臺的文件系統(tǒng)較為特殊，例如采用數(shù)據(jù)庫的記錄方式保存數(shù)據(jù)，甚至根本就沒有提供高效的數(shù)據(jù)存取接口，我們就必須自己實(shí)現(xiàn)數(shù)據(jù)存取接口。這樣，JAVA層就需要跳過RMS而直接通過本地方法調(diào)用本地接口，相應(yīng)的RMS的JAVA代碼就可以從MIDP中刪去。
而在文件系統(tǒng)的本地方法層，MIDP會調(diào)用目標(biāo)平臺的數(shù)據(jù)存取接口來實(shí)現(xiàn)MIDP本身的數(shù)據(jù)存取。這些接口是平臺相關(guān)的，是文件系統(tǒng)中需要移植的部分。這些調(diào)用被放在文件src/share/native/storage.c中，主要包括文件的打開（open）、文件的關(guān)閉（close）、文件的讀寫（read、write）、文件屬性的獲?。╯ize、freesize等）、文件的刪除（delete）、文件的定位（seek）、文件的刪節(jié)（truncate）等。以下便是MIDP文件系統(tǒng)在Windows下的部分實(shí)現(xiàn)。
文件的打開：
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);
……
}
文件的寫入：
void storageWrite(char**ppszError,int handle,char*buffer,int length){
……
bytesWritten=write(handle,buffer,length);
……
}
還有許多其它有關(guān)文件的操作，移植時(shí)只需使用目標(biāo)平臺的API替換以上的Widnows調(diào)用，這里就不再逐一列舉。
2.3 用戶圖形化接口
用戶圖形化接口包括畫點(diǎn)、畫線、作圓、作橢圓、位圖拷貝等基本作圖函數(shù)（可在GRAPHICS.C中找到）；有關(guān)定時(shí)器、屏幕刷新和鍵盤觸控筆消息等有關(guān)與用戶交互的操作（可在TEXT.C中找到），它是整個(gè)MIDP移植中工作量最大，也是對上層應(yīng)用的執(zhí)行效率影響最大的一個(gè)部分。這是因?yàn)橛脩粼趹?yīng)用中看到的各種圖形和文字都是調(diào)用底層的圖形函數(shù)在屏幕上作圖的結(jié)果。由于屏幕要頻繁刷新，圖形函數(shù)也就成為應(yīng)用調(diào)用最多的接口。因此，移植者必須使每一個(gè)底層作圖函數(shù)與硬件設(shè)備緊密配合起來，并使用最高效的算法。
在不同的平臺上，能最大地發(fā)揮其作圖功能的函數(shù)和算法不盡相，這就要求移植者作大量細(xì)致的工作，按照MIDP規(guī)范的要求逐一重新實(shí)現(xiàn)每一個(gè)作圖函數(shù)和屏幕刷新函 數(shù)。下面我們就以將畫線函數(shù)和位圖拷貝函數(shù)在Windows上的實(shí)現(xiàn)為例，簡單說明移植要做的工作（鍵盤、觸控筆是以事件消息的方式實(shí)現(xiàn)的，它們的移植與事件消息的移植相同）。
Windows的畫線函數(shù)接口：
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的屏幕刷新函數(shù)：
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);
}
如果目標(biāo)平臺對這些GUI接口函數(shù)有不同實(shí)現(xiàn)法，可以用這些方法替換以上的Windows系統(tǒng)調(diào)用，這樣才能使MIDP圖形化用戶接口正確地工作，并充分發(fā)揮目標(biāo)平臺的工作效率。
2.4 網(wǎng)絡(luò)
MIDP的網(wǎng)絡(luò)功能是指基于MIDP的J2ME應(yīng)用可以通過HTTP等網(wǎng)絡(luò)協(xié)議進(jìn)行下載安裝，不同的MIDlet實(shí)體也可以通過它交換信息，實(shí)現(xiàn)資源共享。遵循HTTP協(xié)議的規(guī)定，移植者必須利用目標(biāo)平臺的底層網(wǎng)絡(luò)接口重新實(shí)現(xiàn)網(wǎng)絡(luò)的初始化（networkInit）、建立連接（open0）、斷開連接（close0）、接收數(shù)據(jù)（read0）、獲取緩沖區(qū)的剩余空間（available0）、關(guān)閉發(fā)送（shutdownOutput）。如果目標(biāo)設(shè)備具有服務(wù)器功能，還要實(shí)現(xiàn)serversocket所有上述功能。所有上述接口都在文件socketProtocol_md.c中實(shí)現(xiàn)。
Windwos中獲取IP地址的實(shí)現(xiàn)：
Int prim_com_sun_midp_io_j2me_socket_Protocol_getIpNumber
(char*host)
{
……
hp=gethostbyname(host);
……
}
如果目標(biāo)平臺還需要其它網(wǎng)絡(luò)協(xié)議（datagram、comm），其移植過程與Socket的移植基本相同。
2.5 應(yīng)用管理系統(tǒng)（AMS）
MIDP的應(yīng)用管理系統(tǒng)(application management system)負(fù)責(zé)管理當(dāng)前設(shè)備中安裝的J2ME應(yīng)用，其功能包括MIDlet的加載、安裝、顯示、更新和刪除。AMS從main.c中的函數(shù)main()開始執(zhí)行，根據(jù)其輸入初始化一些系統(tǒng)參數(shù)，包括系統(tǒng)路徑（classJ2ME MIDP 移植 平臺無關(guān) 本地代碼）、堆空間大?。╤eapsize）、命令行（command line）等，然后就啟動KVM，而KVM就會從AMS的JAVA界面main.java開始解釋執(zhí)行java代碼。AMS的所有管理功能都是用JAVA語言實(shí)現(xiàn)的，因此AMS的實(shí)現(xiàn)是與平臺無關(guān)的。但不同的平臺可能有不同的系統(tǒng)參數(shù)和格式，對AMS的界面網(wǎng)絡(luò)也可能有不同的要求。所以，移植者有可能要修改main.c中解析系統(tǒng)參數(shù)的部分，保證AMS能正確解析目標(biāo)平臺的所有參數(shù)；同時(shí)修改AMS的JAVA層，使其界面網(wǎng)絡(luò)滿足用戶的需求。
2.6 多媒體
MIDP2.0較MIDP1.0最大的改變就是在MIDP2.0中向應(yīng)用提供了音頻接口（Audio API）的支持。音頻接口是移動設(shè)備媒體接口MMAPI（Mobile Media API）的一部分。音頻的播放過程為5個(gè)部分（unrealized、realized、prefetched、started、closed），同時(shí)它有自己的音頻播放事件的傳道和處理過程。MIDP音頻播放部分所要做的移植工作就主要集中在聲音播放接口，事件的處理方式和兼容不同的音頻文件格式上。
播放接口的移植：不同的目標(biāo)平臺，提供的音頻系統(tǒng)API是不同的，有的系統(tǒng)甚至根本沒有提供播放音頻的API。這時(shí)，移植者就要根據(jù)目標(biāo)平臺的實(shí)現(xiàn)情況替換或自己實(shí)現(xiàn)音頻的播放接口。
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中音頻播放結(jié)束的事件（EOM）是專門通過系統(tǒng)的消息機(jī)制傳遞，而不是通過MIDP的事件傳遞，因此也需要移植：
Windows---OM的傳遞（win32/native/MMAEVT.C）:void injectNativeEvent(int pID,int curMTime){
PostMessage(hMain Window,WM_APP,(WPARAM)(pID),(LPARAM)(curMTime));
return;
}
3 總結(jié)
綜上所述，MID2.0的移植要以兩個(gè)方面為出發(fā)點(diǎn)：①兼容性。移植后的MIDP實(shí)現(xiàn)必須能夠在目標(biāo)平臺上正常運(yùn)行，所有與目標(biāo)平臺不兼容的調(diào)用都必須替換為能完成相同功能且兼容的目標(biāo)平臺的系統(tǒng)調(diào)用或過程。②高效性。移植后的MIDP實(shí)現(xiàn)必須能充分發(fā)揮目標(biāo)平臺的效率和特性，用最小的代價(jià)完成MIDP的功能。另外，MIDP的移植還要分滿足最終用戶的個(gè)性化要求，為它們設(shè)計(jì)出豐富多彩的界面網(wǎng)絡(luò)。
評論