手机Java之怪现象

来源:不详 责任编辑:栏目编辑 发表时间:2013-07-01 22:31 点击:
ok,我承认题目是用来吸引眼球的。但是,不能不承认的是,这篇文章会很有用,很有用……尽管目前可能只是对我有用……因为我记性不够好……

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

== 早期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只把参数传递给新函数,问题就消失了……

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

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

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

== 无法repaint ==
这个问题只存在于SonyEricssonK700c。表现为在keyPressed()中调用repaint()进行屏幕重画没有任何反映。

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

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

幸亏还是有解决办法的。不用new String就完了,而要用更加麻烦的办法,比如像我一样,用ByteArrayInputStream,外面套InputStreamReader(bais, "UTF8"),然后用StringBuffer一个一个char读进来,最后再toString()……
JAVA手机网[www.cnjm.net]
== 不可靠的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)。

== 永
    发表评论
    请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
    用户名: 验证码:点击我更换图片
    最新评论 更多>>

    推荐热点

    • Java编程语言的八大优点
    • JVM对象生命周期详细介绍
    • Java平台上的CRM系统
    • Java 算数测试小程序
    • Java环境 使用Resin在NT环境下配置JSP环境
    • Command(命令模式)
    • Java 一个简单的画图程序
    • Java 日历的小程序
    • Java 数组的复制
    网站首页 - 友情链接 - 网站地图 - TAG标签 - RSS订阅 - 内容搜索
    Copyright © 2008-2015 计算机技术学习交流网. 版权所有

    豫ICP备11007008号-1