n7610系列
手机屏幕：176*204
大量使用2.0的翻转方法很容易死机（最好用诺基亚自带的翻转方法）；
————————————————-
n78(n73 系列)
据我们老板的推测，打包的时候要注意NAME的奇偶个数。（偶数个字符有时候安装不了）
常见机型：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是副本，所以应该用
手机屏幕：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的功能。
手机屏幕：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互为相反数，可以归为同一个版本，取键值的判断其绝对值。
手机屏幕：176*220
游戏屏幕：176*204
非全屏屏幕：176*182
JAVA联网：CMWAP需要代理
字体大小：内置三种字体
MIDP：2.0
CLDC：1.1
JAVA单个容量限制：无限制，小于手机本身内存
JAVA堆栈容量：1.5M
特别1：支持标准 3D API
特别2：支持蓝牙
手机屏幕：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加载代码是分段加载，尽量避免写超长的方法，否则可能会有延迟。
手机屏幕：128*128
游戏屏幕：128*128（FullCanvas）
非全屏屏幕：128*???
JAVA联网：CMWAP直接联
字体大小：三种字体大小，最小字体12*12，一行约10个中文字
MIDP：1.0
CLDC：1.0
JAVA单个容量限制：64KB
JAVA堆栈容量：不明
特别1：按键会有延迟，中断后原线程还会在后台继续运行直到调用repaint，内存开销不当会死机
手机屏幕：128*128
游戏屏幕：128*128（FullCanvas 或 setfullscreenmode(ture)）
非全屏屏幕：128*???
JAVA联网：CMWAP直接联
字体大小：三种字体大小，最小字体12*12，一行约10个中文字
MIDP：2.0
CLDC：1.0
JAVA单个容量限制：110~128KB不等
JAVA堆栈容量：不明
手机屏幕：128*128
游戏屏幕：208*208（这里指分辨率）
JAVA联网：CMWAP直接联
字体大小：不明，可参考S40
MIDP：2.0
CLDC：1.0
JAVA单个容量限制：不明
JAVA堆栈容量：不明
手机屏幕：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搭配完全不能设置裁减框声音播放有问题，建
手机屏幕：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来实现
手机屏幕：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包压缩后的大小)，否则无法加载
手机屏幕：128*160
游戏屏幕：128*144
非全屏屏幕：128*128（估计）
JAVA联网：CMWAP需要代理
字体大小：不明， 一行约8个中文字，内置一种字体
MIDP：2.0
CLDC：1.0
JAVA单个容量限制：200K
JAVA堆栈容量：512K
手机屏幕：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堆栈容量：不明
== 早期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的做法，自己实现剪切和旋转，或者像我一样懒，直接要求美工把旋转之后的图片全都做出来……
== 诡异的内存容量 ==
按照官方Spec，Java在Nokia3125上的可用内存（即Java Heap
Size）为512k。但是实际测试的结果是，Nokia3125只有412k左右的实际内存，相差整整100k。不过好在Nokia3125并不是种市
场保有量很高的型号。但是它是我正在使用的型号……
== 无法repaint ==
这个问题只存在于SonyEricssonK700c。表现为在keyPressed()中调用repaint()进行屏幕重画没有任何反映。
解决办法是，在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的次数继续增加……不过这个时候需要自己手工解决覆盖冲突……
== 无法安静下来的3220 ==
不知道这个问题是不是在S40平台上都有，手里S40又支持MIDI的手机实在是太少了……
3220的一个很明显的特征就是声音大。以至调用了VolumeControl.setLevel(0)之后还是有声音，和Sun官方的Spec完全不
符……没办法，只能在需要静音的时候，再补一个VolumeControl.setMute(true)。
== 永不ready ==
这是一段手机java获取网络数据的常用代码：while(InputStream.ready()) { InputStream.read() }。