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