本文轉自解正宇朋友的《手機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……沒辦法，如果不改上述代碼的話，就自己實現一個繼承類吧。