J2me性能優化，避免內存溢出小結

最近在做一個手機瀏覽器的客戶端，最初以為一個瀏覽器的客戶端不用考慮太多的內存使用，結果做完才發現在高端的手機上運行沒有任何問題，在低端的手機上不是響應速度過慢，就是內存溢出。所以就開始對代碼進行優化，在這個過程總結一些自己的經驗，希望對有困惑的朋友有所幫助，有好的辦法也希望大家共同探討，zxhwolfe@hotmail.com

以下內容有些是自己實踐所得，有些是參考高人經驗或書本上的經驗，如有不正確請立即指正；如果侵犯了他人版權請高臺貴手，借鑒您的經驗不是用于商業，只是希望大家共同進步請不要追究呵呵。

在寫程序初期由于是面向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自帶的內存和方法查看器來判斷。相關內容參考我的另外2篇文章：

J2ME性能優化之--方法和內存的評測：

/Article/Class2/200603/1650.html

J2ME性能優化之—優化方法探討：

/Article/Class2/200603/1658.html

既然轉換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的時候可能會折騰死人的。

關于優化方面也就能想起這些來了，如果還有對大家有用的東西我再補充吧，希望大家多提寶貴意見。共同進步嘛。