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