電子發燒友App
J2me性能優化，避免內存溢出小結
在寫程序初期由于是面向midp2.0的手機而且不是游戲的開發，所以沒有對性能方面做太多的考慮，大膽的使用了很多vector數組（使用起來方便：））等等，而且程序寫的也是隨心所欲，似乎不是在手機上開發j2me的東西。結果讓我大跌眼鏡，沒辦法只能重新優化，這期間可想而知浪費了很多時間，也使開發效率降低到了最低。說到這，只有一句話奉勸大家，不管你是開發什么樣手機程序，一定要把性能放在第一位，不要重蹈我的覆轍。
我的幾個vector存放的是鏈接的內容，文本框的內容，圖片的內容和普通文本的內容，每個vector中包含的其他信息還有它所占的行數，它的位置和它的標志。我用線程控制paint（只要目的是實現持續按鍵的機制），這樣的話，每次重繪都要把所有內容重新畫到屏幕上，而且還要對當前焦點進行重繪。在重繪的過程中每一次都要遍歷一遍幾乎所有的vector然后重繪，這樣肯定是浪費資源。結果也一樣，在稍微低端一點手機上響應明顯的慢。優化這樣程序，我首先想到的就是把vector用別的方法替換掉，正常的性能使用是字符串-〉一維數組-〉二維數組-》vector。一維數組肯定是替代不了我的vector了，那只能是使用二維數組了。費了好大勁把vector轉換位二維數組，發現性能上并沒有提升多少。大概只節省了20k左右的內存，只能再想別的辦法。這里簡單說下在手機上獲得當前內存和剩余內存的方式：
longtempMin=1000000；
longtemp=Runtime.getRuntime（）.freeMemory（）;
if（tempMin》temp）{
tempMin=temp;
}
g.drawString（total=+Runtime.getRuntime（）.totalMemory（），10，10，0）;
g.drawString（frees=+temp，10，10+lineHeight，0）;
g.drawString（hiegh=+tempMin，10，10+2*lineHeight，0）;
把這些東西畫到你的畫布上，在真機上運行的時候方便你查看內存的使用率。（每種機器的內存最大值是不同的）。
而且可以查看內存峰值。當然你也可以使用wtk自帶的內存和方法查看器來判斷。
既然轉換vector不能解決問題，那就繼續優化。內存的主要使用看來是在每次重畫的時候產生的，這樣就要減少每次重畫的內容，我采取的方式是把所有固定要重畫的東西用雙緩沖的方式畫到一張圖片上，這樣只有初始化的時候才去遍歷數組，經過一次的遍歷把所有內容畫到一張圖片上，然后每一次的重畫都是在重畫一張圖片。經過這樣的處理性能上有了很大的提升。高興還為時尚早，nokia的低端機器沒有問題了，結果在moto的機器上出了問題，根本就不能初始化，也就是說創建那張圖片的時候就應用程序錯誤了。繼續查找原因，結果發現是因為moto的機器不支持創建一張那么大圖片。也就是說你創建一張大圖的時候，在moto的機器上根本就不能申請到內存。找到原因后，把大圖分割為兩個比較小的圖，ok沒有問題了。當然至于moto支持創建多大的圖片可能每種機器不同吧，只能在需要的時候自己測試了。對于瀏覽器，一張分割為兩張需要做些代碼的處理。實際上為了性能的更加優化可以把一張大圖分割為多張小圖，每張小圖的大小可以根據屏幕的幾倍大小確定也可以根據機型固定。初始化的時候也可以先初始化一部分圖。因人而異。
至此，程序的主要瓶頸已經找到，并且解決。正應了一句話，程序是花80%的時間在執行20%的代碼。也就是說我們要把主要精力放在那20%的代碼的優化上，但實際中我發現對另外80%代碼的優化也很重要，主要是一些編程細節上的處理。在細節的代碼書寫上多注意些也有利于程序性能的提升。關于細節上覺得以下幾個方面對程序性能的提升很有幫助。
首先系統垃圾回收的利用：關于堆內存（heap）與棧內存（stack）我們知道，heap存放的是對象實例與變量；而stack存放的是靜態方法。堆內存在JVM啟動的時候被創建，堆內存中所存儲的對象可以被JVM自動回收。在這里，要手動把不用對象置為null，特別是較大的對象，如果不用一定要記得置為空。比如說較大的數組，vector或者是image對象。（切忌）在這里，瀏覽器中頁面圖片的讀取我是采用的是后臺讀取，即先顯示文字部分，而后后臺讀取頁面中的圖片，讀取完成后再一起重新顯示。重新顯示的時候要重新構建那個雙緩沖圖片，而我當時就忘記了把原來創建的那個雙緩沖圖片置為null了，走了很多彎路才解決問題。所以要切忌至少把大的對象置空，不要指望垃圾回收。
其次是static的使用：靜態變量在程序運行期間內存空間對所有該類的對象實例而言是共享的，即只在內存中保存一份拷貝，這樣節約了不比要的內存開銷。但是static生命周期較長，而且不容易被垃圾回收機制所回收，所以要合理運用，不要適得其反。建議在全部具備下列條件的情況下盡量使用靜態變量：
1），變量所包含的對象體積較大，占用內存較多。
2），變量所包含的對象生命周期較長。
3），變量所包含的對象數據穩定。
4），該類的對象實例有對該變量所包含的對象的共享需求。
在我的程序中對靜態變量的優化后，使程序占用內存量至少提升了5k-10k。所以也不容忽視。
還有就是String類相關的東西：1。字符串累加的時候一定要用StringBuffer的append方法，不要使用+操作符連接兩個字符串。差別很大。而且在循環或某些重復執行的動作中不要去創建String對象，因為String對象是要用StringBuffer對象來處理的，一個String對象應該是產生了3個對象（大概是這樣：））。
2，字符串length（）方法來取得字符串長度的時候不要把length放到循環中，可以在循環外面對其取值。（包括vector的size方法）。特別是循環次數多的時候，盡量把length放到循環外面。
intsize=xmlVector.size（）;
for（inti=2;i
。。。
}
在程序中我曾經誤寫了這樣一句：if（i=5）{。。。}，編譯器沒有報錯，而且結果好像是把i的值改變了，沒有記清，大家有興趣可以測驗下。書寫上盡量認真，否則查找bug的時候可能會折騰死人的。
對代碼進行優化的最簡單辦法就是首先不要調用這些代碼。這并不是說要刪除這些代碼，也許可以用其他辦法來調用它們（后者事實減少對它的調用）。游戲的主循環 是游戲運行的最主要做的事情，應該更多地考慮是否可以不用或減少對屬于這個區域內的代碼的調用。在前一片文章中介紹了方法和內存評測工具的使用，但它們只 能幫助我們找出究竟是哪段代碼降低了程序的運行速度，下面的內容是參考了其他資料整理出來的優化代碼的方法。
代碼優化的技術大致分為兩個主要方面：高級優化，從使用的整體算法和結構出發進行的優化；低級優化，集中于孤立的代碼片斷（通常為方法中的代碼）的優化。下面分別討論兩方面的優化：
一， 高級優化
1， 感覺到就是真實
對于電影來說，我們通過攝像頭看到的都是完美的，而在拍攝現場我們看到的卻是木頭，泡沫和膠帶。所以對于電影來說，感覺到就是真實。
游戲也一樣，只需要處理游戲需要的東西。在游戲開發的各個方面這都是實用的。把精力集中在使游戲有趣和完美運行的問題上，始終只做需要做的而丟棄其他的部分。
2， 不要創建對象
減少對象創建的總數量和頻率，結果能夠大大地提高游戲的性能。還必須小心在不經意的情況下產生 String對象。
例如 ：graphics.drawString（ 0，0，”Score：” +score ）;
這一句代碼會在每次被調用的時候產生一個新的 String對象，在這里就是每一楨畫面顯示時都會產生新的 String對象。因此最好是只是在分數改變的時候才構造這個 String。
3， 繪制屏幕
通常，在對游戲完成大量的優化工作以后，收獲的將是一個大量時間耗費在屏幕繪圖上的游戲。這是因為一個游戲的主要時耗大都集中在繪制圖像的工作上（或其他的一些基本的繪圖調用）。因此，如果一開始就可以避免繪制工作，那將是對游戲的很好的優化。
還有就是要減少屏幕繪制，循環檢測屏幕圖像是否在某個部分發生了改變，如果沒有，就不要對那部分的屏幕進行更新。另一個方法就是增加繪制圖像的尺寸來減少單獨的繪制調用的次數。
4， 算法
最好的，也是使用最多的高級優化是對游戲的算法方面。
二，低級優化
1， 提前繪制復雜圖像
我們已經知道，使用 LCDUI繪制圖像是很慢的，因此最好是能夠避免這種繪制。其中的一個方法就是用一個預生成圖像來減少復雜圖像的繪制。進一步來講，舉例：將所有的游戲狀態信息整合到一個面板中（得分，生命數，能量值等），然后對這些信息進行一次性同時更新。
2， 保持類和內存之間的平衡
產生新的類會增加 JAR包文件的大小，因此應該盡量避免。有的時候增加了額外類的開銷可能節省了額外的內存開銷，這也是值得的。
3， 復雜值的預計算
節省運算的一個好方法就是對數值進行預運算，從而無需再調用大開銷的計算方法。一個很好的例子就是：主窗口畫布的高度和寬度就是很好的緩存對象。例如：可以調用 getHeight方法和 getWidth方法一次，然后將它們的結果緩存起來，而不是在每一次繪圖中都調用這兩種方法。
4， 使用數組
在任何時候，只要可能，都應該使用數組而不是 Vector，因為數組的運行速度更快。通常面臨的唯一問題是，如果最初分配的數組空間不夠大，將需要對數組的大小進行擴充。這可以做到，但它需要對整個數組進行重建。例如：
Public final static int［ ］ expandArray（int ［］ oldArray， int expandBy）
{
int ［ ］ newArray = new int ［oldArray.length + expandBy］;
System.arraycopy（oldArray， 0， newArray， 0， oldArray.length）;
Return newArray;
}
任何時候，都應該盡量使用一維數組。訪問二維數組變量的速度只有訪問一維數組變量的一半。當然，仍然可以訪問二維數組的對象，只是需要加入一點點計算。例如，與其使用這條語句：
world［y］［x］ = 0；
不如下面這條語句運行的快：
world［y*tilesWide + x］ = 0；
這條語句通過行列的位置將數值轉換成一維值，實現了對數組同一元素的訪問。
5， 不要使用數組
盡管數組的訪問比 Vector快，但仍然比直接訪問變量要慢，因此如果可能就應該刪除對數組的訪問，或者為一些常用方法中的數組尋求其他能提高性能的辦法。
6， 使用快速方法
并不是所有 Java調用的方法在性能上都是相同的，方法聲明方式的不同對性能會會產生很多的影響。可以使用的最快的方法類型是靜態方法，因此應該盡可能多地將代碼置于靜態調用方法中。運行速度僅次于靜態方法的是聲明為 final的方法。運行最慢的兩種方法是在接口中定義的方法和用關鍵字 synchronized聲明的方法，必須盡可能地避免使用這些類型的方法。
7， 其他優化
1）異常處理非常緩慢，不要為一半的游戲邏輯使用異常，只用它們來報告真正的錯誤狀態。
2）使用 switch表達式比使用 if條件語句塊的速度要快。
3）盡可能避免使用 String對象進行運算，使用 StringBuffer。
4）內嵌類的運行很慢，盡可能避免使用。
5）在完成一個引用的使用后將它設為 null。
6）不要浪費時間來將一個對象初始化為 null或 0， java虛擬機會替我們完成這樣的初始化
7）多思考新方法，這會使我們的大腦運轉的更快。
8）如果可能，盡量使用 static，它們運行都很快。它同時適用于方法和域，這條規則就是，如果它可以是靜態的，那么就把它聲明為靜態的。
9）避免類型轉換。
10）程序優化的時候要有所取舍，要多捉摸了。大家有什么好的建議？一起來壯大吧。
共同探討： zxhwolfe@hotmail.com
附：關于j2me程序的調試
使用eclipseME+WTK2.1進行J2ME應用程序調試（debug）-- 引用mingjava的帖子。
選擇windows-》preferences-》java-》debug 不要選擇suspend execution的前面兩個選項，在debuger timeout選項中 第一個時間至少設置為15000ms 這樣就可以調試了。
《script src=“http://partner.googleadservices.com/gampad/google_service.js” type=“text/javascript”》《/script》 《script type=“text/javascript”》《！-- try { GS_googleAddAdSenseService（“ca-pub-4210569241504288”）; GS_googleEnableAllServices（）; } catch （e） { } // --》《/script》 《script src=“http://partner.googleadservices.com/gampad/google_ads.js”》《/script》 《script type=“text/javascript”》《！-- try { GA_googleAddSlot（“ca-pub-4210569241504288”， “cnblogs_commentbox_up”）; GA_googleAddSlot（“ca-pub-4210569241504288”， “cnblogs_blogpost_bottom”）; } catch （e） { } // --》《/script》 《script type=“text/javascript”》《！-- try { GA_googleFetchAds（）; } catch （e） { } // --》《/script》
工商網監
評論