Java在手机平台上的Porting

这两天在跑一个比较简单的J2ME的Case，整个项目不会超过3k 行的代码，但还是做得我很辛苦，因为我完全不会Java。只是对C/C++比较熟悉，看那些语法基本没有问题，拿着入门的书一般看一般就开发起来。

随着项目进入后期，需要进行兼容性测试的时候，问题来了.

记得Java世界有这么一句话，“一次编译，到处运行”，但我发现，除了MIDP1.0的代码大部分机器都能安装（并非都能使用），2.0的内容在很多机器上支持得“千奇百怪”。于是乎仔细分析了手机平台上的JVM环境的构造。

以我这个case MIDP1.0的版本为例子吧，软件中用到的资源有：

字体，输入法，控件（菜单，文本框，列表框，图片，文字，输入框），声音，其他TAPI相关内容。

手机厂商为了使得Java里的界面风格要和自己手机的风格要一样，所以将很多控件接口接到了手机平台上，所以你可以看到字体，输入法，文本框，输入框，菜单都会和手机上其他地方是一样的。（测试的过程中发现一款MTK的机器，输入框没有做接口，为Java默认的界面，超丑）。

我们遇到的问题是：

1. 部分Java支持全屏显示，部分不支持，针对不支持全屏的需要多几套版本。找了几个手机平台，发现不支持全屏的原因是部分手机在刷新 电池，信号，时间的时候单独控制的，尤其是feature phone, 界面上的status bar 一直在刷新，当全屏遮盖的时候需要独立处理，比较麻烦。

2. 内存分配不一样。导致当java里空间耗用过大的时候，java没有办法运行。在Porting Java的时候一般会预先分配给java一块空间，这块空间是不可变化的，所以当运行时需要分配大量空间的程序就跑不起来。不过我朋友研究的动态分配技术也许可以解决这样的问题。

3. 部分协议支持不完善，java协议里可以支持TAPI来的消息，但很多手机包括一些中高端的都不支持，我知道的有SMS，MMS，vCalendar.... 。咨询过公司做Java Engine的同事，支持这些协议需要理出很多低级接口和Vendor一起测试，比较麻烦。很多技术普通的公司就没有办法处理了。

4. 各个知名厂商有自己独立的接口，这个是最头疼的，如果加上厂商的接口，就是“一次编译，到处都不能运行”。知名厂商也有苦衷，太通用了，谁都能模仿... FT。

 

总的感觉，J2ME的执行很大程序是依赖被Porting的嵌入式环境，为了J2ME的和谐环境，我们需要牺牲很多东西去适应。曾看过一个调查数据，从网络下的J2ME的程序在手机上成功安装 & 运行率不足60%。J2ME，感觉还有好多路要走。