J2ME移植-键值
1. J2ME标准api中Canvas中定义的键值有17(方向、确定、#*、数字键) + 4(游戏键) = 21个。在一般的手机中，这缺少了“左/右功能键”和“C键”，由于这三个键在标准api中并未给出，所以不同的手机厂商对其的支持也不同。
| 手机平台 | 左功能键 | 右功能键 | C键 |
| Nokia | -6 | -7 | -8 |
| Moto | -21 | -22 | -8 |
| SonyEricsson | -6 | -7 | -8 |
| Samsung | -6 | -7 | -8 |
| Sun Emulator | -6 | -7 | -8 |
2. 有些手机不支持RMS，例如Nokia5300(S40 3rd, FP2)、Samsung手机。
3. 有些手机如果没有签名，每一次io连接都需要用户确认，比如sonyericsson手机、S40 5th, FP1。
4. 有些手机对全屏支持不太好，例如sonyericsson手机，在Canvas中draw()时坐标定位有偏移。
以上是我在开发中想重点强调的问题，下面是一些网友之谈，这些问题在我的开发中并没有遇到很强的阻力，但回头想想可能是我运气不错没有遇到相关问题。这里摘录过来供大家参考(原文出处已无从考证)。
编写易于移植的J2ME代码
我写第一个J2ME游戏的时候，根本就没想过移植的问题。所以那个游戏也就很难移植了。反过来，如果你已经计划好要移植了，那么事情就简单的多。这一节说的是代码问题。那就想想，不同手机之间在代码上会有哪些差异。
(1) 屏幕尺寸不同
这儿谈的主要问题，是自适应控件。所谓控件，就是菜单、文本框、列表框、进度条等等。这些控件的大小必须可以根据屏幕大小自适应的调整。按照第一篇说的方法，将屏幕大小作为变量参与到控件尺寸的计算即可得到正确的尺寸（自适应后的）。其次就是得到正确尺寸后怎么把它画出来。
这要看你的GUI是怎么画得了，如果是用线画的，那就很简单；如果使用了图片，那么就可能要更换图片了。我的控件使用了图片平铺和画线结合，所以可以很容易的改变尺寸。如果控件变大了，则绘制时增加平铺的次数即可。
顺便说一下，这些控件我只用了一个类表示，使用参数化的方法区分使用，毕竟咱要尽量少用类吧。
(2) 支持的API不同
如果你的游戏只限于使用Midp1.0，那么移植的时候就不用考虑什么了。实际上由于我们经常要使用图片翻转、象素绘制、全屏等，往往要用到厂商API或Midp2.0。显然移植的时候要考虑到这些API的差异。
我的办法是将这些api封装一层，比如我需要使用创建透明子图的API，于是封装了一个函数createSubImg。这是Nokia版本：
public static Image createSubImg(Image img,int []imgRect){
Image subImg = DirectUtils.createImage(imgRect[2],imgRect[3],0) ;
subImg.getGraphics().drawImage(img,-imgRect[0],-imgRect[1],20);
return subImg ;
}
这是Midp2.0版本：
public static Image createSubImg(Image img,int []imgRect) {
return Image.createImage(img,imgRect[0],imgRect[1],imgRect[2],imgRect[3],0) ;
}
对于不同机型，该函数的实现不同，但功能相同，因此使用这个函数的代码在移植时无需修改。当然这样做增加了一些间接性，有可能降低性能。
(3) 按键代码不同
我们知道MIDP提供了Game Action，和按键代码无关，但这不够用啊，我们完全可以定义自己的Game Action，但首先让我们定义自己的虚拟按键码吧。我使用位记录每个键的状态，每个位代表一个按键，一个int有32个位所以足够了。
当keyPressed发生时，我记下哪些键被按下；同样当keyReleased时，将那些被松开的键使用的位清0。某个键，也就是这个键盘状态整数里的某个位，就是我定义的一个虚拟键。当然它的值总是2的n次方了，和key code完全不搭边，所以需要我们用一个映射函数将key code映射到这些虚拟键。
这个函数就是移植的关键，每个机型都要改写这个映射函数，在里面填入正确的key code。你可以在虚拟键的基础上再定义Game Action，支持在游戏中设置按键，这样就更灵活了。
(4) 封装库
如果想不更改一行代码就从MotorolaV600移植到Nokia N-Gage，那么为他们封装不同的库吧。我就这样在1分钟内完成了移植。我的库包含了一个游戏框架类（内含游戏循环和渲染函数，键盘处理，以及若干跨机型的工具函数），一个图形组管理类（管理图片的载入切割旋转绘制和动画等，有点像GameAPI中的Sprite）和一个控件类（包含了所有我需要的控件）。
这3个类封装了不同机型的所有差异，我需要为每种机型改写这三个类，当然大部分代码是相同的了。此外我还写了一个工具支持图形组管理类，所见即所得的编辑动画和管理图片，当然这也对移植有帮助。
总结：以上几条，总得讲来，无非是拆合而以。主要是要将差异性独立出来，便于更改。但是移植总得来讲还是比较郁闷，主要原因是各种机型有各自的bug，这就需要特殊处理啦。各位写代码时一定要想好移植的问题啊！