当前位置: 代码迷 >> J2ME >> J2ME 机型开发bug征集
  详细解决方案

J2ME 机型开发bug征集

热度:8088   发布时间:2013-02-25 21:32:03.0
J2ME 机型开发bug收集

?

转载 http://www.j2megame.org/index.php/content/view/2331/125

Author Author: 一滴蔚蓝色 | Date Date: 2010-08-31 | View Count View: 293 | Section & Category 开发技术 -?程序设计 | Digg Digg: 0

?

?

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:支持MOTOFUNLIGHT API
特别2:支持MOTO3D API
特别3:开启摄像头、内部文件访问权限等需要授权
特别4C650机型: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:支持MOTOGAME 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
特别1E398支持MOTO FUNLIGHT API
特别2:支持MOTO3D API
特别3:开启摄像头、内部文件访问权限等需要授权
特别4V300系列,键值正好与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:支持蓝牙
特别3E6805个空格占一个字符宽度
特别4E680加载代码是分段加载,尽量避免写超长的方法,否则可能会有延迟。
--------------------------------------------------------------------------------
NOKIA S40 V1
手机屏幕:128*128
游戏屏幕:128*128FullCanvas
非全屏屏幕:128*???
JAVA
联网:CMWAP直接联
字体大小:三种字体大小,最小字体12*12,一行约10个中文字
MIDP
1.0
CLDC
1.0
JAVA
单个容量限制:64KB
JAVA
堆栈容量:不明
特别1:按键会有延迟,中断后原线程还会在后台继续运行直到调用repaint,内存开销不当会死机
----------------------------------------------------------------------------------
NOKIA S40 V2
手机屏幕:128*128
游戏屏幕:128*128FullCanvas 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*208FullCanvas
非全屏屏幕:176*144
JAVA
联网:CMWAP直接联
字体大小:不明,一行可显示约12-13个中文字
MIDP
1.0 (但是可增加多媒体播放API
CLDC
1.0
JAVA
单个容量限制:不明
JAVA
堆栈容量:不明
特别13650机型:setClipdrawRegion搭配不能正确设置裁减框。
特别23650机型:频繁I/O操作会死机,应尽量在游戏初始化时将数据一次读入。
特别3N-Gage机型:在背景缓冲上setClipdrawRegion搭配完全不能设置裁减框声音播放有问题,建
特别4N-Gage机型:声音播放有问题,建议在I/O操作等跟系统底层有关调用之后再播放声音

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

----------------------------------------------------------------------------------------
索爱K700C
手机屏幕:176*220
游戏屏幕:176*220setfullscreenmode(true)
游戏屏幕:176*208com.nokia.mid.ui.FullCanvas
非全屏屏幕:176*176setfullscreenmode(false)
JAVA
联网:CMWAP需要代理
字体大小:不明,一行中文字数约10个,内置一种字体,任何字体选项均为默认字体。
MIDP
2.0
CLDC
1.1
JAVA
单个容量限制:???
JAVA
堆栈容量:512K(实际使用中感觉不止)
特别1:支持NOKIAUI API,但是drawpixels(),getpixels()2个表现差劲不能使用
特别2:支持标准3DAPI
特别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上已经解决了。但是Nokia32304.0526.2ch)、Nokia76106.0525.0ch)都存在这个问题。对于这些个有问题的机型,在 java程序中是无法完美解决这个问题的,只能尽量避免。比如集中、统一载入资源,永不释放(也就是说,尽量控制泄漏的次数)。当然,这会对已有代码造成很大影响。毕竟手机java应用是内存受限系统的典型,大多数情况下,珍贵的内存中只保留需要的资源。

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

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

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

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

JAVA
手机网[www.cnjm.net]
==
诡异的内存容量 ==
按照官方SpecJavaNokia3125上的可用内存(即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机器上的问题,V3E398都有。copyAreaGraphics的作整块屏幕像素copy的常用API2D动态背景的游戏几乎是必不可少)。按照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……没办法,如果不改上述代码的话,就自己实现一个继承类吧。