MIDP2.0及其移植技术分析
减小字体
增大字体例如，Windows采用消息响应机制来处理各种事件，所有消息都可以通过系统API调用GetMessage获取，系统会调用消息处理函数WndProc(HWND hwnd、UINTiMsg、WPARAM wParam、LRARAM 1Param)，在其中处理和传递不同的事件。其大致实现过程如下：
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中获取事件后，就完全独立地传递和处理事件消息，与平台无关，因此无需移植。
javascript:window.open(this.src);" style="cursor:pointer;"/>
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）、文件属性的获取（size、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<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接口函数有不同实现法，可以用这些方法替换以上的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 移植 平台无关 本地代码）、堆空间大小（heapsize）、命令行（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&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）是专门通过系统的消息机制传递，而不是通过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的移植还要分满足最终用户的个性化要求，为它们设计出丰富多彩的界面网络。
Tags：
作者：佚名
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“MIDP2.0及其移植技术分析”更多相关内容
中查找“MIDP2.0及其移植技术分析”更多相关内容