J2ME BUG 收集

本文列举了多种手机Java开发过程中遇到的奇怪问题及解决方案,包括内存泄漏、键盘响应事件异常、drawRegion性能低下等问题,涉及Nokia、Motorola、SonyEricsson等品牌的不同机型。
摘要由CSDN通过智能技术生成
2009年07月21日 星期二 16:01

------------------------------------------------

n7610系列


手机屏幕:176*204

大量使用2.0的翻转方法很容易死机(最好用诺基亚自带的翻转方法);

 

-------------------------------------------------

n78(n73 系列)

据我们老板的推测,打包的时候要注意NAME的奇偶个数。(偶数个字符有时候安装不了)

 

MOTO 小C系列
常见机型:C650
手机屏幕:128*128
游戏屏幕:128*116
非全屏屏幕:128*100
JAVA联网:CMWAP需要代理
字体大小:17*17,一行约7个中文字,内置一种字体,任何字体选项均为默认字体
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:标准100K(实际无限制,小于手机本身内存)
JAVA堆栈容量:800K
特别1:支持MOTO FUNLIGHT API
特别2:支持MOTO 3D API
特别3:开启摄像头、内部文件访问权限等需要授权
特别4:C650机型:setMediaTime该机型不支持,playerUpdate传过来的player是副本,所以应该用
equal而不是==。

--------------------------------------------------------------------------------
MOTO C550/C370/E380系列
手机屏幕:96*65
游戏屏幕:96*64
非全屏屏幕:96*64
JAVA联网:CMWAP需要代理
字体大小:不明,可参考MOTO C
MIDP:1.0
CLDC:1.0
JAVA单个容量限制:100K标准(实际不明)
JAVA堆栈容量:512K
特别1:支持MOTO GAME API,可实现相当于MIDP2.0的功能。
--------------------------------------------------------------------------------
MOTO E398、V600系列
手机屏幕:176*220
游戏屏幕:176*204
非全屏屏幕:176*182
JAVA联网:CMWAP需要代理
字体大小:17*17 一行约10个中文字,内置一种字体,任何字体选项均为默认字体。
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:无限制,小于手机本身内存
JAVA堆栈容量:800K
特别1:E398支持MOTO FUNLIGHT API
特别2:支持MOTO 3D API
特别3:开启摄像头、内部文件访问权限等需要授权
特别4:V300系列,键值正好与E398互为相反数,可以归为同一个版本,取键值的判断其绝对值。
--------------------------------------------------------------------------------
MOTO C975/C980/V980系列
手机屏幕:176*220
游戏屏幕:176*204
非全屏屏幕:176*182
JAVA联网:CMWAP需要代理
字体大小:内置三种字体
MIDP:2.0
CLDC:1.1
JAVA单个容量限制:无限制,小于手机本身内存
JAVA堆栈容量:1.5M
特别1:支持标准 3D API
特别2:支持蓝牙
--------------------------------------------------------------------------------
MOTO E680系列
手机屏幕:240*320
游戏屏幕:240*320
JAVA联网:CMWAP需要代理、直联
字体大小:内置三种字体
MIDP:2.0
CLDC:1.1
JAVA单个容量限制:无限制,小于手机本身内存
JAVA堆栈容量:1.5M(预想)
特别1:支持标准 3D API
特别2:支持蓝牙
特别3:E680上5个空格占一个字符宽度
特别4:E680加载代码是分段加载,尽量避免写超长的方法,否则可能会有延迟。
--------------------------------------------------------------------------------
NOKIA S40 V1
手机屏幕:128*128
游戏屏幕:128*128(FullCanvas)
非全屏屏幕:128*???
JAVA联网:CMWAP直接联
字体大小:三种字体大小,最小字体12*12,一行约10个中文字
MIDP:1.0
CLDC:1.0
JAVA单个容量限制:64KB
JAVA堆栈容量:不明
特别1:按键会有延迟,中断后原线程还会在后台继续运行直到调用repaint,内存开销不当会死机
----------------------------------------------------------------------------------
NOKIA S40 V2
手机屏幕:128*128
游戏屏幕:128*128(FullCanvas 或 setfullscreenmode(ture))
非全屏屏幕:128*???
JAVA联网:CMWAP直接联
字体大小:三种字体大小,最小字体12*12,一行约10个中文字
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:110~128KB不等
JAVA堆栈容量:不明
-------------------------------------------------------------------------------------
NOKIA 6230i
手机屏幕:128*128
游戏屏幕:208*208(这里指分辨率)
JAVA联网:CMWAP直接联
字体大小:不明,可参考S40
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:不明
JAVA堆栈容量:不明
--------------------------------------------------------------------------------------
NOKIA S60 MIDP1.0
手机屏幕:176*208
游戏屏幕:176*208(FullCanvas)
非全屏屏幕:176*144
JAVA联网:CMWAP直接联
字体大小:不明,一行可显示约12-13个中文字
MIDP:1.0 (但是可增加多媒体播放API)
CLDC:1.0
JAVA单个容量限制:不明
JAVA堆栈容量:不明
特别1:3650机型:setClip和drawRegion搭配不能正确设置裁减框。
特别2:3650机型:频繁I/O操作会死机,应尽量在游戏初始化时将数据一次读入。
特别3:N-Gage机型:在背景缓冲上setClip和drawRegion搭配完全不能设置裁减框声音播放有问题,建
特别4:N-Gage机型:声音播放有问题,建议在I/O操作等跟系统底层有关调用之后再播放声音

---------------------------------------------------------------------------------------
NOKIA S60 MIDP2.0
手机屏幕:176*208
游戏屏幕:176*208(FullCanvas 或 setfullscreenmode(ture))
非全屏屏幕:176*144
JAVA联网:CMWAP直接联
字体大小:不明,一行可显示约12-13个中文字
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:不明
JAVA堆栈容量:不明
特别1:6600机型:调用readFully不能按指定字节数读取,readByte代替。
特别2:6600机型:setClip和drawRegion搭配在欧版6600上不能正确设置裁减框,导致绘图错误
特别3:7610机型:drawRegion在这个机型上会拖慢速度,建议使用Nokia UI API上的drawImage。
特别4:7610机型:绘图函数调用不当会当机。
特别5:6681机型:频繁I/O操作会死机,应尽量在游戏初始化时将数据一次读入。
特别6:6681机型:使用2.0的drawRegion会造成内存泄露,尽量减少使用翻转,尤其是画地图时应尽量使用1.0的drawImage来实现

----------------------------------------------------------------------------------------
索爱K700C
手机屏幕:176*220
游戏屏幕:176*220(setfullscreenmode(true))
游戏屏幕:176*208(com.nokia.mid.ui.FullCanvas)
非全屏屏幕:176*176(setfullscreenmode(false))
JAVA联网:CMWAP需要代理
字体大小:不明,一行中文字数约10个,内置一种字体,任何字体选项均为默认字体。
MIDP:2.0
CLDC:1.1
JAVA单个容量限制:???
JAVA堆栈容量:512K(实际使用中感觉不止)
特别1:支持NOKIA UI API,但是drawpixels(),getpixels()这2个表现差劲不能使用
特别2:支持标准3D API
特别3:单个类文件不能超过70K(JAR包压缩后的大小),否则无法加载
------------------------------------------------------------------------------------
波导S689
手机屏幕:128*160
游戏屏幕:128*144
非全屏屏幕:128*128(估计)
JAVA联网:CMWAP需要代理
字体大小:不明, 一行约8个中文字,内置一种字体
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:200K
JAVA堆栈容量:512K
------------------------------------------------------------------------------
阿尔卡特 OT556/557
手机屏幕:128*160
游戏屏幕:128*160
非全屏屏幕:128*129
JAVA联网:CMWAP需要代理
字体大小:14*14,一行中文字个数约8个,内置一种字体font(0,0,0)
MIDP:2.0
CLDC:1.0
JAVA单个容量限制:256k
JAVA堆栈容量:512K
----------------------------------------------------------------------------------

三星X108/X608
手机屏幕:128*128
游戏屏幕:128*128(全屏补丁实现)
非全屏屏幕:128*110
JAVA联网:CMWAP需要代理
字体大小:不明,一行中文字个数不明,内置一种字体font(0,0,0)
MIDP:1.0
CLDC:1.0
JAVA单个容量限制:???
JAVA堆栈容量:不明

 

手机Java之怪现象
2008-01-08 21:09

下面记载的都是手机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() }。

转载于:https://my.oschina.net/elinac/blog/698030

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值