下面记载的都是手机java实现中各种奇怪的毛病,bug,或者……特性,是根据某项目的开发经验总结出来的。但是涵盖的手机型号还是有限。因此很有可能某些“特性”会存在于更多的采用了相同JVM(比如平台相同、生产厂商)的手机上。


JAVA手机网[www.cnjm.net]

== 早期S60的内存泄漏 ==

这个bug可以上溯至2003年,甚至更早。表现为java应用中如果使用了Class.getResourceAsStream("本地文件")无法释 放其占用的内存,是的,没有任何办法,无论是调用获得的的InputStream实例的close()或将其设为null,甚至显式强制 System.gc(),都没有效果。结果就是至少和本地文件同尺寸的内存成为了无法回收的垃圾。这个问题还影响到以 Class.getResourceAsStream()为基础的Image.createImage()(这个是最要命的,如何能够不使用图片资源 呢!)。

这个bug据说在新的S60上已经解决了。但是Nokia3230(4.0526.2ch)、Nokia7610(6.0525.0ch)都存在这个问 题。对于这些个有问题的机型,在java程序中是无法完美解决这个问题的,只能尽量避免。比如集中、统一载入资源,永不释放(也就是说,尽量控制泄漏的次 数)。当然,这会对已有代码造成很大影响。毕竟手机java应用是内存受限系统的典型,大多数情况下,珍贵的内存中只保留需要的资源。

== 键盘响应事件 ==

在MIDP1中,获取键盘事件只能自己实现Canvas.keyPressed()。但是MotorolaE398和SonyEricssonK700c 的实现却很奇怪。表现为左右软键有可能在这个方法中捕获不到。而是否能够成功捕获,取决于keyPressed()方法中代码的行数……

我承认我没彻底搞清楚这其中的玄机。鬼知道Motorola和SonyEricsson是怎么实现的JVM。我只知道把keyPressed中的所有代码提取到另外一个函数中,在keyPressed只把参数传递给新函数,问题就消失了……

== 超慢的drawRegion ==

除了N-Gage QD,几乎所有的NokiaS60手机都实现了MIDP2的支持。MIDP2中,最为重要的几个特性之一就是Graphics.drawRegion。这个API可以方便的将图片旋转、剪切之后画到画布上。

但是,这个API在Nokia3230、Nokia7610等手机上的实际性能表现让人实在不敢恭维。于是,这个最重要的API成了摆设……没什么怎么办,只能急需延用MIDP1的做法,自己实现剪切和旋转,或者像我一样懒,直接要求美工把旋转之后的图片全都做出来……
JAVA手机网[www.cnjm.net]

== 诡异的内存容量 ==

按照官方Spec,Java在Nokia3125上的可用内存(即Java Heap Size)为512k。但是实际测试的结果是,Nokia3125只有412k左右的实际内存,相差整整100k。不过好在Nokia3125并不是种市 场保有量很高的型号。但是它是我正在使用的型号……

== 无法repaint ==

这个问题只存在于SonyEricssonK700c。表现为在keyPressed()中调用repaint()进行屏幕重画没有任何反映。
JAVA手机网[www.cnjm.net]

解决办法是,在keyReleased()中补一个repaint()……

== UTF8 ==

还是SonyEricssonK700c的问题。问题存在于new String(byte[], charset)上。也就是说,当获得了某个byte[],并希望用UTF8作为字符集将其转换为字符串的时候,使用上述方法在 SonyEricssonK700c上会出现丢失字符的现象。这个现象很诡异,以至于我目前没有搞清楚什么情况下会丢失字符(我甚至专门写了个测试程序在 真机上跑,得出的结论是丢失字符的原因可能会很复杂,简单的拿被丢掉字符附近的一个子串来测没有任何问题)。

幸亏还是有解决办法的。不用new String就完了,而要用更加麻烦的办法,比如像我一样,用ByteArrayInputStream,外面套 InputStreamReader(bais, "UTF8"),然后用StringBuffer一个一个char读进来,最后再toString()……

== 不可靠的copyArea ==

这是Motorola机器上的问题,V3和E398都有。copyArea是Graphics的作整块屏幕像素copy的常用API(2D动态背景的游戏 几乎是必不可少)。按照Sun官方的Spec,手机厂商有义务来保证其API实现不存在覆盖冲突问题。但是Motorola显然做得不够好。在 Motorola手机上使用这个API会随机产生贴图混乱的情况……

解决办法是自己实现另外一套机制。比如使用另外一张至少和屏幕同样大小的Image作为缓冲,用两次drawImage来替代copyArea……不过这 个方法显而易见的缺点是消耗了更多的内存(那可是不小于屏幕尺寸的Image啊!)。如果内存实在吃紧,只能退而再求其次,作为缓冲的Image继续缩 水,drawImage的次数继续增加……不过这个时候需要自己手工解决覆盖冲突……
JAVA手机网[www.cnjm.net]

== 无法安静下来的3220 ==

不知道这个问题是不是在S40平台上都有,手里S40又支持MIDI的手机实在是太少了……

3220的一个很明显的特征就是声音大。以至调用了VolumeControl.setLevel(0)之后还是有声音,和Sun官方的Spec完全不符……没办法,只能在需要静音的时候,再补一个VolumeControl.setMute(true)。

== 永不ready ==

这是一段手机java获取网络数据的常用代码:while(InputStream.ready()) { InputStream.read() }。

JAVA手机网[www.cnjm.net]
但是经测试,在Nokia3230上,这个ready永远返回false……没办法,如果不改上述代码的话,就自己实现一个继承类吧。