本文轉(zhuǎn)自解正宇朋友的《手機(jī)Java之怪現(xiàn)象》，個(gè)人感覺對(duì)我等初學(xué)者幫助非常大，故此轉(zhuǎn)貼，由于不知道原文所出網(wǎng)址，這里表示歉意。

下面記載的都是手機(jī)java實(shí)現(xiàn)中各種奇怪的毛病，bug，或者……特性，是根據(jù)某項(xiàng)目的開發(fā)經(jīng)驗(yàn)總結(jié)出來的。但是涵蓋的手機(jī)型號(hào)還是有限。因此很有可能某些“特性”會(huì)存在于更多的采用了相同JVM（比如平臺(tái)相同、生產(chǎn)廠商）的手機(jī)上。
                                                                                  == 早期S60的內(nèi)存泄漏 ==
這個(gè)bug可以上溯至2003年，甚至更早。表現(xiàn)為java應(yīng)用中如果使用了Class.getResourceAsStream("本地文件")無法釋放其占用的內(nèi)存，是的，沒有任何辦法，無論是調(diào)用獲得的的InputStream實(shí)例的close()或?qū)⑵湓O(shè)為null，甚至顯式強(qiáng)制System.gc()，都沒有效果。結(jié)果就是至少和本地文件同尺寸的內(nèi)存成為了無法回收的垃圾。這個(gè)問題還影響到以Class.getResourceAsStream()為基礎(chǔ)的Image.createImage()（這個(gè)是最要命的，如何能夠不使用圖片資源呢！）。
這個(gè)bug據(jù)說在新的S60上已經(jīng)解決了。但是Nokia3230（4.0526.2ch）、Nokia7610（6.0525.0ch）都存在這個(gè)問題。對(duì)于這些個(gè)有問題的機(jī)型，在java程序中是無法完美解決這個(gè)問題的，只能盡量避免。比如集中、統(tǒng)一載入資源，永不釋放（也就是說，盡量控制泄漏的次數(shù)）。當(dāng)然，這會(huì)對(duì)已有代碼造成很大影響。畢竟手機(jī)java應(yīng)用是內(nèi)存受限系統(tǒng)的典型，大多數(shù)情況下，珍貴的內(nèi)存中只保留需要的資源。
                                                                                  == 鍵盤響應(yīng)事件 ==
在MIDP1中，獲取鍵盤事件只能自己實(shí)現(xiàn)Canvas.keyPressed()。但是MotorolaE398和SonyEricssonK700c的實(shí)現(xiàn)卻很奇怪。表現(xiàn)為左右軟鍵有可能在這個(gè)方法中捕獲不到。而是否能夠成功捕獲，取決于keyPressed()方法中代碼的行數(shù)……
我承認(rèn)我沒徹底搞清楚這其中的玄機(jī)。鬼知道Motorola和SonyEricsson是怎么實(shí)現(xiàn)的JVM。我只知道把keyPressed中的所有代碼提取到另外一個(gè)函數(shù)中，在keyPressed只把參數(shù)傳遞給新函數(shù)，問題就消失了……
                                                                                  == 超慢的drawRegion ==
除了N-Gage QD，幾乎所有的NokiaS60手機(jī)都實(shí)現(xiàn)了MIDP2的支持。MIDP2中，最為重要的幾個(gè)特性之一就是Graphics.drawRegion。這個(gè)API可以方便的將圖片旋轉(zhuǎn)、剪切之后畫到畫布上。
但是，這個(gè)API在Nokia3230、Nokia7610等手機(jī)上的實(shí)際性能表現(xiàn)讓人實(shí)在不敢恭維。于是，這個(gè)最重要的API成了擺設(shè)……沒什么怎么辦，只能急需延用MIDP1的做法，自己實(shí)現(xiàn)剪切和旋轉(zhuǎn)，或者像我一樣懶，直接要求美工把旋轉(zhuǎn)之后的圖片全都做出來……
                                                                                  == 詭異的內(nèi)存容量 ==
按照官方Spec，Java在Nokia3125上的可用內(nèi)存（即Java Heap Size）為512k。但是實(shí)際測(cè)試的結(jié)果是，Nokia3125只有412k左右的實(shí)際內(nèi)存，相差整整100k。不過好在Nokia3125并不是種市場(chǎng)保有量很高的型號(hào)。但是它是我正在使用的型號(hào)……
                                                                                  == 無法repaint ==
這個(gè)問題只存在于SonyEricssonK700c。表現(xiàn)為在keyPressed()中調(diào)用repaint()進(jìn)行屏幕重畫沒有任何反映。
解決辦法是，在keyReleased()中補(bǔ)一個(gè)repaint()……
                                                                                  == UTF8 ==
還是SonyEricssonK700c的問題。問題存在于new String(byte[], charset)上。也就是說，當(dāng)獲得了某個(gè)byte[]，并希望用UTF8作為字符集將其轉(zhuǎn)換為字符串的時(shí)候，使用上述方法在SonyEricssonK700c上會(huì)出現(xiàn)丟失字符的現(xiàn)象。這個(gè)現(xiàn)象很詭異，以至于我目前沒有搞清楚什么情況下會(huì)丟失字符（我甚至專門寫了個(gè)測(cè)試程序在真機(jī)上跑，得出的結(jié)論是丟失字符的原因可能會(huì)很復(fù)雜，簡單的拿被丟掉字符附近的一個(gè)子串來測(cè)沒有任何問題）。
幸虧還是有解決辦法的。不用new String就完了，而要用更加麻煩的辦法，比如像我一樣，用ByteArrayInputStream，外面套InputStreamReader(bais, "UTF8")，然后用StringBuffer一個(gè)一個(gè)char讀進(jìn)來，最后再toString()……
                                                                                  == 不可靠的copyArea ==
這是Motorola機(jī)器上的問題，V3和E398都有。copyArea是Graphics的作整塊屏幕像素copy的常用API（2D動(dòng)態(tài)背景的游戲幾乎是必不可少）。按照Sun官方的Spec，手機(jī)廠商有義務(wù)來保證其API實(shí)現(xiàn)不存在覆蓋沖突問題。但是Motorola顯然做得不夠好。在Motorola手機(jī)上使用這個(gè)API會(huì)隨機(jī)產(chǎn)生貼圖混亂的情況……
解決辦法是自己實(shí)現(xiàn)另外一套機(jī)制。比如使用另外一張至少和屏幕同樣大小的Image作為緩沖，用兩次drawImage來替代copyArea……不過這個(gè)方法顯而易見的缺點(diǎn)是消耗了更多的內(nèi)存（那可是不小于屏幕尺寸的Image啊！）。如果內(nèi)存實(shí)在吃緊，只能退而再求其次，作為緩沖的Image繼續(xù)縮水，drawImage的次數(shù)繼續(xù)增加……不過這個(gè)時(shí)候需要自己手工解決覆蓋沖突……
                                                                                  == 無法安靜下來的3220 ==
不知道這個(gè)問題是不是在S40平臺(tái)上都有，手里S40又支持MIDI的手機(jī)實(shí)在是太少了……
3220的一個(gè)很明顯的特征就是聲音大。以至調(diào)用了VolumeControl.setLevel(0)之后還是有聲音，和Sun官方的Spec完全不符……沒辦法，只能在需要靜音的時(shí)候，再補(bǔ)一個(gè)VolumeControl.setMute(true)。
                                                                                  == 永不ready ==
這是一段手機(jī)java獲取網(wǎng)絡(luò)數(shù)據(jù)的常用代碼：while(InputStream.ready()) { InputStream.read() }。
但是經(jīng)測(cè)試，在Nokia3230上，這個(gè)ready永遠(yuǎn)返回false……沒辦法，如果不改上述代碼的話，就自己實(shí)現(xiàn)一個(gè)繼承類吧。