J2ME開發經驗：J2ME應用程式記憶體優化三招

一．代碼優化

記憶體會溢出肯定和代碼逃不了關系,99.99%學java的人都知道垃圾回收器是

java的一大優點并據此來嘲笑C++。顯然這個特性為代碼編寫者省了不少事，但這個特性卻帶來了不少隐患。舉個例子在遊戲當中經常有不同場景的切換，如

從遊戲邏輯退到主菜單邏輯,對遊戲邏輯對象的态度很多人會選擇忘記等待垃圾回收器來收屍。乍看之下似乎并無不妥垃圾回收器會來善後。實際上垃圾回收器并非

實時的,它不像C++的Delete語句馬上釋放不用的記憶體。當從遊戲邏輯切換到主菜單邏輯這時兩個對象同時存在很可能這時記憶體就不夠用了。讀到這裡很多

人會發現實際上垃圾回收器在j2me上并不怎麼好用，從一個角度上來講在j2me上所有垃圾必須由手工釋放,除簡單類型以外所有對象都必須顯式地置空例如

imgs=null;實際上java提供了一個不錯的工具用來查找記憶體溢出,java.lang.Runtime.freeMemory()。它可以傳回

目前的剩餘記憶體數，将它适當的安放在代碼中可以有效的監測記憶體使用狀況。很大一部份的j2me程式員之前都是從事pc軟體開發工作，充裕的記憶體掩蓋了許多

寫代碼的不良習慣。如下所示：

//a不為空

a=newLogic();

很多人可能對此有異議，他們會認為新的對象會把舊的對象沖掉并且釋放記憶體。這裡面包含兩個問題：1.該段代碼是先建立對象然後再進行指派操作的，也就是說在這期間有兩個對象同時存在這就很可能會産生溢出。2.這樣做也會妨礙垃圾回收器的工作

較好的寫法如下：

a=null;

雖然麻煩了點但在j2me中還是必要的。接着看下例。

(到這網站看看:[url]http://www.javabiz.cn[/url],也有類似資料供你參考。)

drawString("遊戲時間:"+time,50,50,Graphics.LEFT|Graphics.TOP);

"遊戲時間:"+time很完美在paint()方法當中每次都被刷一遍顯示在螢幕

上。危機往往隐藏在美麗的外表，該語句會引起新的記憶體重新配置設定來存儲"遊戲時間:"+time而顯示完以後又必須由垃圾回收器釋放，用了雙倍時間,并且容

易發生記憶體溢出。依此類推在重複執行的方法裡應盡量避免重複定義對象。與paint()方法類似在循環裡也有類似的情況存在。

把所有對象的初始化放在構造函數裡想必是再正當不過了,大多數人通常的做法是把目前邏輯所要用到的資源通通初始化完畢。

很大一部份的記憶體溢出都是發生在構造函數中。記憶體使用的高峰期都是在構造函數中是以避開這個高峰能有效的防止溢出。建議最好的辦法是第一次使用時初始化。如下所示

if(img==null){

//初始化

}

現在做遊戲很多時候都需要地圖數組，聲音數組，還有一些其它資源這些資源很多可以放在代碼中也有的可以放在檔案當中。

強烈建議将這些資源放在檔案中需要時在load進來。這些資源檔案如果放在代碼中則會占用不小的代碼段空間，而代碼一般是程式一運作就裝載到記憶體當中。

除上面列舉的方法外還有一些大家所熟知的順便一提,比如關閉沒用的rms，關閉沒用的網絡連接配接，關閉沒用的流。正确地停止線程。良好的程式架構減少代碼偶合性也是一個不錯的方法，無論在代碼調式，記憶體釋放都可以做到非常清析。

二．圖檔優化

j2me的記憶體殺手無疑非圖檔莫屬,一張3k的圖檔可以占用20多k的記憶體不信大家把load前後的記憶體剩餘列印出來對比看看。是以防止記憶體溢出最直接的辦法就是從圖檔入手。

1．圖檔壓縮:多數人馬上會想到這個辦法。不錯這個辦法是最有效的。在photoshop裡圖檔制作完成後不要選擇"存儲為"，而是選擇"存儲為web所用格式"可以根據裡面的選項進行壓縮，特别是顔色這一項越小越好不過相應的圖像會有所失真。不要認為這樣就完了。

實際上該圖檔還可以再次壓縮，在網上有許多類似的工具。推薦一款可以壓縮png格式的軟體xat.comImageOptimizer效果不錯。經常都有70%的壓縮率且圖像不會失真。

假如你有多張規格一樣的圖檔，那麼建議你把它做成一張長條圖檔。有兩個原因：

1、這樣節省存儲空間和記憶體空間。大家可做個試驗将10張圖檔的内容放在一張當中對比看看檔案大小有沒有變化。

2、10張圖檔需要10個p_w_picpath對象需要進行10次io操作浪費時間不說還浪費記憶體。當筆者發現這個好處時興奮地把所有圖檔都存成一張，吱地一聲記憶體又溢出了...原因想必大家也知道!！圖檔太大了不要把不同界面的圖檔整合在一起否則經常會得不償失。

作圖時還有一些細節需要注意,顔色數量，分辯率，圖像模式（最好是索引顔色),畫布大小都會影響到圖檔大小。

三．工具優化

誰都知道混淆器是用來保護代碼的以加大反編譯的難度(個人認為這是在嘲笑程式員的智商）。實際上用它來優化程式也是不錯的選擇，至少有兩點好處：

1、壓縮程式大小。一個60k的程式經常可以壓掉10k左右。10k的空間對于寫低端手機的程式員簡直是雪中送碳，多少超過64k限制的遊戲都受過它的恩惠；

2、節省記憶體空間。用腳去想也想得出來代碼少了記憶體裡的代碼段自然就短了。

到這網站看看:[url]http://www.javabiz.cn[/url],也有類似資料供你參考。