手机 Java 之怪现象
ok,我承认题目是用来吸引眼球的。但是,不能不承认的是,这篇文章会很有用,很有用……尽管目前可能只是对我有用……因为我记性不够好……
下面记载的都是手机 java 实现中各种奇怪的毛病,bug,或者……特性,是根据某项目的开发经验总结出来的。但是涵盖的手机型号还是有限。因此很有可能某些“特性”会存在于更多的采用了相同 JVM(比如平台相同、生产厂商)的手机上。
== 早期 S60 的内存泄漏 ==
这个 bug 可以上溯至 2003 年,甚至更早。表现为 java 应用中如果使用了 Class.getResourceAsStream("本地文件") 无法释放其占用的内存,是的,没有任何办法,无论是调用获得的的 InputStream 实例的 close() 或将其设为 null,甚至显式强制 System.gc(),都没有效果。结果就是至少和本地文件同尺寸的内存成为了无法回收的垃圾。这个问题还影响到以 Class.getResourceAsStream() 为基础的 Image.createImage()(这个是最要命的,如何能够不使用图片资源呢!)。
这个 bug 据说在新的 S60 上已经解决了。但是 Nokia 3230(4.0526.2ch)、Nokia 7610(6.0525.0ch)都存在这个问题。对于这些个有问题的机型,在 java 程序中是无法完美解决这个问题的,只能尽量避免。比如集中、统一载入资源,永不释放(也就是说,尽量控制泄漏的次数)。当然,这会对已有代码造成很大影响。毕竟手机 java 应用是内存受限系统的典型,大多数情况下,珍贵的内存中应该只保留需要的资源。
== 键盘响应事件 ==
在 MIDP1 中,获取键盘事件只能自己实现 Canvas.keyPressed()。但是 Motorola E398 和 SonyEricsson K700c 的实现却很奇怪。表现为左右软键有可能在这个方法中捕获不到。而是否能够成功捕获,取决于 keyPressed() 方法中代码的行数……
我承认我没彻底搞清楚这其中的玄机。鬼知道 Motorola 和 SonyEricsson 是怎么实现的 JVM。我只知道把 keyPressed 中的所有代码提取到另外一个函数中,在 keyPressed 只把参数传递给新函数,问题就消失了……
== 超慢的 drawRegion ==
除了 N-Gage QD,几乎所有的 Nokia S60 手机都实现了对 MIDP2 的支持。MIDP2 中,最为重要的几个特性之一就是 Graphics.drawRegion。这个 API 可以方便的将图片旋转、剪切之后画到画布上。
但是,这个 API 在 Nokia 3230、Nokia 7610 等手机上的实际性能表现让人实在不敢恭维。于是,这个最重要的 API 成了摆设……没什么怎么办,只能延用 MIDP1 的做法,自己实现剪切和旋转,或者像我一样懒,直接要求美工把旋转之后的图片全都做出来……
== 诡异的内存容量 ==
按照官方 Spec,Java 在 Nokia 3125 上的可用内存(即 Java Heap Size)为 512k。但是实际测试的结果是,Nokia3125 只有 412k 左右的实际内存,相差整整 100k。不过好在 Nokia 3125 并不是种市场保有量很高的型号。但是它是我正在使用的型号……
== 无法 repaint ==
这个问题只存在于 SonyEricsson K700c。表现为在 keyPressed() 中调用 repaint() 进行屏幕重画没有任何反映。
解决办法是,在 keyReleased() 中补一个 repaint()……
== UTF8 ==
还是 SonyEricsson K700c 的问题。问题存在于 new String(byte[], charset) 上。也就是说,当获得了某个 byte[],并希望用 UTF8 作为字符集将其转换为字符串的时候,使用上述方法在 SonyEricsson K700c 上会出现丢失字符的现象。这个现象很诡异,以至于我目前没有搞清楚什么情况下会丢失字符(我甚至专门写了个测试程序在真机上跑,得出的结论是丢失字符的原因可能会很复杂,简单的拿被丢掉字符附近的一个子串来测没有任何问题)。
幸亏还是有解决办法的。不用 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 的次数继续增加……不过这个时候需要自己手工解决覆盖冲突……
== 无法安静下来的 3220 ==
不知道这个问题是不是在 S40 平台上都有,手里 S40 又支持 MIDI 的手机实在是太少了……
3220 的一个很明显的特征就是声音大。以至调用了 VolumeControl.setLevel(0) 之后还是有声音,和 Sun 官方的 Spec 完全不符……没办法,只能在需要静音的时候,再补一个 VolumeControl.setMute(true)。
== 永不 ready ==
这是一段手机 java 获取网络数据的常用代码:while(InputStream.ready()) { InputStream.read() }。
但是经测试,在 Nokia 3230 上,这个 ready 永远返回 false……没办法,如果不改上述代码的话,就自己实现一个继承类吧。
下面记载的都是手机 java 实现中各种奇怪的毛病,bug,或者……特性,是根据某项目的开发经验总结出来的。但是涵盖的手机型号还是有限。因此很有可能某些“特性”会存在于更多的采用了相同 JVM(比如平台相同、生产厂商)的手机上。
== 早期 S60 的内存泄漏 ==
这个 bug 可以上溯至 2003 年,甚至更早。表现为 java 应用中如果使用了 Class.getResourceAsStream("本地文件") 无法释放其占用的内存,是的,没有任何办法,无论是调用获得的的 InputStream 实例的 close() 或将其设为 null,甚至显式强制 System.gc(),都没有效果。结果就是至少和本地文件同尺寸的内存成为了无法回收的垃圾。这个问题还影响到以 Class.getResourceAsStream() 为基础的 Image.createImage()(这个是最要命的,如何能够不使用图片资源呢!)。
这个 bug 据说在新的 S60 上已经解决了。但是 Nokia 3230(4.0526.2ch)、Nokia 7610(6.0525.0ch)都存在这个问题。对于这些个有问题的机型,在 java 程序中是无法完美解决这个问题的,只能尽量避免。比如集中、统一载入资源,永不释放(也就是说,尽量控制泄漏的次数)。当然,这会对已有代码造成很大影响。毕竟手机 java 应用是内存受限系统的典型,大多数情况下,珍贵的内存中应该只保留需要的资源。
== 键盘响应事件 ==
在 MIDP1 中,获取键盘事件只能自己实现 Canvas.keyPressed()。但是 Motorola E398 和 SonyEricsson K700c 的实现却很奇怪。表现为左右软键有可能在这个方法中捕获不到。而是否能够成功捕获,取决于 keyPressed() 方法中代码的行数……
我承认我没彻底搞清楚这其中的玄机。鬼知道 Motorola 和 SonyEricsson 是怎么实现的 JVM。我只知道把 keyPressed 中的所有代码提取到另外一个函数中,在 keyPressed 只把参数传递给新函数,问题就消失了……
== 超慢的 drawRegion ==
除了 N-Gage QD,几乎所有的 Nokia S60 手机都实现了对 MIDP2 的支持。MIDP2 中,最为重要的几个特性之一就是 Graphics.drawRegion。这个 API 可以方便的将图片旋转、剪切之后画到画布上。
但是,这个 API 在 Nokia 3230、Nokia 7610 等手机上的实际性能表现让人实在不敢恭维。于是,这个最重要的 API 成了摆设……没什么怎么办,只能延用 MIDP1 的做法,自己实现剪切和旋转,或者像我一样懒,直接要求美工把旋转之后的图片全都做出来……
== 诡异的内存容量 ==
按照官方 Spec,Java 在 Nokia 3125 上的可用内存(即 Java Heap Size)为 512k。但是实际测试的结果是,Nokia3125 只有 412k 左右的实际内存,相差整整 100k。不过好在 Nokia 3125 并不是种市场保有量很高的型号。但是它是我正在使用的型号……
== 无法 repaint ==
这个问题只存在于 SonyEricsson K700c。表现为在 keyPressed() 中调用 repaint() 进行屏幕重画没有任何反映。
解决办法是,在 keyReleased() 中补一个 repaint()……
== UTF8 ==
还是 SonyEricsson K700c 的问题。问题存在于 new String(byte[], charset) 上。也就是说,当获得了某个 byte[],并希望用 UTF8 作为字符集将其转换为字符串的时候,使用上述方法在 SonyEricsson K700c 上会出现丢失字符的现象。这个现象很诡异,以至于我目前没有搞清楚什么情况下会丢失字符(我甚至专门写了个测试程序在真机上跑,得出的结论是丢失字符的原因可能会很复杂,简单的拿被丢掉字符附近的一个子串来测没有任何问题)。
幸亏还是有解决办法的。不用 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 的次数继续增加……不过这个时候需要自己手工解决覆盖冲突……
== 无法安静下来的 3220 ==
不知道这个问题是不是在 S40 平台上都有,手里 S40 又支持 MIDI 的手机实在是太少了……
3220 的一个很明显的特征就是声音大。以至调用了 VolumeControl.setLevel(0) 之后还是有声音,和 Sun 官方的 Spec 完全不符……没办法,只能在需要静音的时候,再补一个 VolumeControl.setMute(true)。
== 永不 ready ==
这是一段手机 java 获取网络数据的常用代码:while(InputStream.ready()) { InputStream.read() }。
但是经测试,在 Nokia 3230 上,这个 ready 永远返回 false……没办法,如果不改上述代码的话,就自己实现一个继承类吧。
评论