J2ME應用程序內存優化的幾種途徑
開發J2ME應用程序時，out momory內存溢出這種痛苦經常經常出現，所以J2ME應用程序內存的優化是非常必要而必須的，這里向大家簡單描述一下，相信本文介紹一定會讓你有所收獲。
J2ME應用程序內存優化
開發J2ME應用程序時，out momory內存溢出這種痛苦經常經常出現。要知道在手機上用內存必須勒緊褲腰帶，手機是以K來計算的。寫手機程序讓人回到了8086時代。J2ME應用程序內存的優化是非常必要而必須的。
一．代碼優化
內存會溢出肯定和代碼逃不了關系,垃圾回收器是java的一大優點,顯然這個特性為代碼編寫者省了不少事，但這個特性卻帶來了不少隱患。
舉個例子在游戲當中經常有不同場景的切換，如從游戲邏輯退到主菜單邏輯,對游戲邏輯對象的態度,很多人會選擇忘記內存的釋放，就等著垃圾回收器自己來善后。但是實際上垃圾回收器并非實時的,它不像C++的Delete語句馬上釋放不用的內存。當從游戲邏輯切換到主菜單邏輯這時兩個對象同時存在很可能這時內存就不夠用了。
實際上垃圾回收器在j2me上并不怎么好用，在j2me上所有垃圾手工釋放才比較直接有效,除簡單類型以外所有對象都必須顯式地置空例如 imgs=null; 實際上java提供了一個不錯的工具用來查找內存溢出,java.lang.Runtime.freeMemory() 。它可以返回當前的剩余內存數，將它適當的安放在代碼中可以有效的監測內存使用狀況。
有一部份的j2me程序員寫代碼存在不良習慣。
例1：
- //a 不為空
- a=new menu();
這里面包含兩個問題：
1. 該段代碼是先創建對象然后再進行賦值操作的，也就是說在這期間有兩個對象同時存在這就很可能會產生溢出。
2. 這樣做也會妨礙垃圾回收器的工作
較好的寫法如下:
- a=null;
- System.gc(); // 回收a以前引用的對象
- a=new menu();
雖然麻煩了點但在j2me中還是必要的。
例2：
drawString(”游戲時間:” + time ,50,50,Graphics.LEFT|Graphics.TOP);
“游戲時間:” + time 很***在paint()方法當中每次都被刷一遍顯示在屏幕上。該語句每次運行時會重新分配內存來存儲 ”游戲時間:” + time 而顯示完以后又必須由垃圾回收器釋放，用了雙倍時間,并且容易發生內存溢出。依此類推在重復執行的方法里應盡量避免重復定義對象。與paint()方法類似在循環里也有類似的情況存在。
例3：
把所有對象的初始化放在構造函數里,大多數人通常的做法是把當前所要用到的資源通通一次初始化完畢。
很大一部份的內存溢出都是發生在構造函數中。內存使用的高峰期都是在構造函數中所以避開這個高峰能有效的防止溢出。
比較好的做法是***次使用時初始化。如下所示
- if (img==null){
- //初始化
- }
現在做游戲都需要地圖數組，聲音數組，還有一些其它資源。
這些資源可以放在代碼中也可以放在文件當中,但是建議將這些資源放在文件中需要時在loading進來。這些資源如果放在代碼中則會占用不小的代碼段空間，而代碼一般是程序一運行就裝載到內存當中。
除上面列舉的方法外還有其他的小方法, 比如關閉沒用的rms ，關閉沒用的網絡連接，關閉沒用的流。正確地停止線程。良好的程序架構減少代碼偶合性也是一個不錯的方法。#p#
二．圖片優化
下面我們來看一下J2ME應用程序內存優化的圖片優化的概念。j2me的內存殺手無疑非圖片莫屬,一張3k的圖片可以占用20多k的內存。防止內存溢出最直接的辦法就是從圖片入手。圖片壓縮: 多數人馬上會想到這個辦法。不錯這個辦法是最有效的。在網上有許多圖片壓縮工具,這里就不詳細說明了。
假如你有多張規格一樣的圖片，那么建議你把它做成一張長條圖片。有兩個原因：
1>這樣節省存儲空間和內存空間。10張圖片的內容放在一張當中和10張小圖片相比，文件大小減少了不少。
2>10張圖片需要10個image 對象需要進行10次io操作浪費時間還浪費內存。當把所有圖片都存成一張，內存又容易溢出了… 圖片太大了不要把不同界面的圖片整合在一起否則經常會得不償失，這就需要在實踐中不斷調整了。
作圖時也有一些細節需要注意,顏色數量，分辯率，圖像模式（***是索引顏色),畫布大小都會影響到圖片大小。J2ME應用程序內存優化如何使用工具進行優化呢。
三．工具優化
混淆器是用來保護代碼的以加大反編譯的難度,實際上用它來優化程序也是不錯的選擇。
其實有兩點好處：
1> 壓縮程序大小: 一個60k的程序經常可以壓掉10多k。10k的空間對于低端手機來說可不是個小數
2> 節省內存空間: 代碼減小了內存里的代碼段自然就短了。
【編輯推薦】
