J2ME 机型开发bug收集

 

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

Author: 一滴蔚蓝色 | Date: 2010-08-31 | View: 293 | 开发技术 - 程序设计 | 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 ：支持 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() } 。


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