本文转自解正宇朋友的《手机Java之怪现象》，个人感觉对我等初学者帮助非常大，故此转贴，由于不知道原文所出网址，这里表示歉意。

下面记载的都是手机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只把参数传递给新函数，问题就消失了……
                                                                                  == 超慢的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() }。
但是经测试，在Nokia3230上，这个ready永远返回false……没办法，如果不改上述代码的话，就自己实现一个继承类吧。