J2me性能優(yōu)化，避免內(nèi)存溢出小結(jié)

最近在做一個(gè)手機(jī)瀏覽器的客戶端，最初以為一個(gè)瀏覽器的客戶端不用考慮太多的內(nèi)存使用，結(jié)果做完才發(fā)現(xiàn)在高端的手機(jī)上運(yùn)行沒(méi)有任何問(wèn)題，在低端的手機(jī)上不是響應(yīng)速度過(guò)慢，就是內(nèi)存溢出。所以就開(kāi)始對(duì)代碼進(jìn)行優(yōu)化，在這個(gè)過(guò)程總結(jié)一些自己的經(jīng)驗(yàn)，希望對(duì)有困惑的朋友有所幫助，有好的辦法也希望大家共同探討，zxhwolfe@hotmail.com

以下內(nèi)容有些是自己實(shí)踐所得，有些是參考高人經(jīng)驗(yàn)或書(shū)本上的經(jīng)驗(yàn)，如有不正確請(qǐng)立即指正；如果侵犯了他人版權(quán)請(qǐng)高臺(tái)貴手，借鑒您的經(jīng)驗(yàn)不是用于商業(yè)，只是希望大家共同進(jìn)步請(qǐng)不要追究呵呵。

在寫(xiě)程序初期由于是面向midp2.0的手機(jī)而且不是游戲的開(kāi)發(fā)，所以沒(méi)有對(duì)性能方面做太多的考慮，大膽的使用了很多vector數(shù)組（使用起來(lái)方便：））等等，而且程序?qū)懙囊彩请S心所欲，似乎不是在手機(jī)上開(kāi)發(fā)j2me的東西。結(jié)果讓我大跌眼鏡，沒(méi)辦法只能重新優(yōu)化，這期間可想而知浪費(fèi)了很多時(shí)間，也使開(kāi)發(fā)效率降低到了最低。說(shuō)到這，只有一句話奉勸大家，不管你是開(kāi)發(fā)什么樣手機(jī)程序，一定要把性能放在第一位，不要重蹈我的覆轍。

我的幾個(gè)vector存放的是鏈接的內(nèi)容，文本框的內(nèi)容，圖片的內(nèi)容和普通文本的內(nèi)容，每個(gè)vector中包含的其他信息還有它所占的行數(shù)，它的位置和它的標(biāo)志。我用線程控制paint（只要目的是實(shí)現(xiàn)持續(xù)按鍵的機(jī)制），這樣的話，每次重繪都要把所有內(nèi)容重新畫(huà)到屏幕上，而且還要對(duì)當(dāng)前焦點(diǎn)進(jìn)行重繪。在重繪的過(guò)程中每一次都要遍歷一遍幾乎所有的vector然后重繪，這樣肯定是浪費(fèi)資源。結(jié)果也一樣，在稍微低端一點(diǎn)手機(jī)上響應(yīng)明顯的慢。優(yōu)化這樣程序，我首先想到的就是把vector用別的方法替換掉，正常的性能使用是字符串-〉一維數(shù)組-〉二維數(shù)組->vector。一維數(shù)組肯定是替代不了我的vector了，那只能是使用二維數(shù)組了。費(fèi)了好大勁把vector轉(zhuǎn)換位二維數(shù)組，發(fā)現(xiàn)性能上并沒(méi)有提升多少。大概只節(jié)省了20k左右的內(nèi)存，只能再想別的辦法。這里簡(jiǎn)單說(shuō)下在手機(jī)上獲得當(dāng)前內(nèi)存和剩余內(nèi)存的方式：

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);

把這些東西畫(huà)到你的畫(huà)布上，在真機(jī)上運(yùn)行的時(shí)候方便你查看內(nèi)存的使用率。（每種機(jī)器的內(nèi)存最大值是不同的）。

而且可以查看內(nèi)存峰值。當(dāng)然你也可以使用wtk自帶的內(nèi)存和方法查看器來(lái)判斷。相關(guān)內(nèi)容參考我的另外2篇文章：

J2ME性能優(yōu)化之--方法和內(nèi)存的評(píng)測(cè)：

/Article/Class2/200603/1650.html

J2ME性能優(yōu)化之—優(yōu)化方法探討：

/Article/Class2/200603/1658.html

既然轉(zhuǎn)換vector不能解決問(wèn)題，那就繼續(xù)優(yōu)化。內(nèi)存的主要使用看來(lái)是在每次重畫(huà)的時(shí)候產(chǎn)生的，這樣就要減少每次重畫(huà)的內(nèi)容，我采取的方式是把所有固定要重畫(huà)的東西用雙緩沖的方式畫(huà)到一張圖片上，這樣只有初始化的時(shí)候才去遍歷數(shù)組，經(jīng)過(guò)一次的遍歷把所有內(nèi)容畫(huà)到一張圖片上，然后每一次的重畫(huà)都是在重畫(huà)一張圖片。經(jīng)過(guò)這樣的處理性能上有了很大的提升。高興還為時(shí)尚早，nokia的低端機(jī)器沒(méi)有問(wèn)題了，結(jié)果在moto的機(jī)器上出了問(wèn)題，根本就不能初始化，也就是說(shuō)創(chuàng)建那張圖片的時(shí)候就應(yīng)用程序錯(cuò)誤了。繼續(xù)查找原因，結(jié)果發(fā)現(xiàn)是因?yàn)閙oto的機(jī)器不支持創(chuàng)建一張那么大圖片。也就是說(shuō)你創(chuàng)建一張大圖的時(shí)候，在moto的機(jī)器上根本就不能申請(qǐng)到內(nèi)存。找到原因后，把大圖分割為兩個(gè)比較小的圖，ok沒(méi)有問(wèn)題了。當(dāng)然至于moto支持創(chuàng)建多大的圖片可能每種機(jī)器不同吧，只能在需要的時(shí)候自己測(cè)試了。對(duì)于瀏覽器，一張分割為兩張需要做些代碼的處理。實(shí)際上為了性能的更加優(yōu)化可以把一張大圖分割為多張小圖，每張小圖的大小可以根據(jù)屏幕的幾倍大小確定也可以根據(jù)機(jī)型固定。初始化的時(shí)候也可以先初始化一部分圖。因人而異。

至此，程序的主要瓶頸已經(jīng)找到，并且解決。正應(yīng)了一句話，程序是花80%的時(shí)間在執(zhí)行20%的代碼。也就是說(shuō)我們要把主要精力放在那20%的代碼的優(yōu)化上，但實(shí)際中我發(fā)現(xiàn)對(duì)另外80%代碼的優(yōu)化也很重要，主要是一些編程細(xì)節(jié)上的處理。在細(xì)節(jié)的代碼書(shū)寫(xiě)上多注意些也有利于程序性能的提升。關(guān)于細(xì)節(jié)上覺(jué)得以下幾個(gè)方面對(duì)程序性能的提升很有幫助。

首先系統(tǒng)垃圾回收的利用：關(guān)于堆內(nèi)存（heap）與棧內(nèi)存（stack）我們知道，heap存放的是對(duì)象實(shí)例與變量；而stack存放的是靜態(tài)方法。堆內(nèi)存在JVM啟動(dòng)的時(shí)候被創(chuàng)建，堆內(nèi)存中所存儲(chǔ)的對(duì)象可以被JVM自動(dòng)回收。在這里，要手動(dòng)把不用對(duì)象置為null，特別是較大的對(duì)象，如果不用一定要記得置為空。比如說(shuō)較大的數(shù)組，vector或者是image對(duì)象。（切忌）在這里，瀏覽器中頁(yè)面圖片的讀取我是采用的是后臺(tái)讀取，即先顯示文字部分，而后后臺(tái)讀取頁(yè)面中的圖片，讀取完成后再一起重新顯示。重新顯示的時(shí)候要重新構(gòu)建那個(gè)雙緩沖圖片，而我當(dāng)時(shí)就忘記了把原來(lái)創(chuàng)建的那個(gè)雙緩沖圖片置為null了，走了很多彎路才解決問(wèn)題。所以要切忌至少把大的對(duì)象置空，不要指望垃圾回收。

其次是static的使用：靜態(tài)變量在程序運(yùn)行期間內(nèi)存空間對(duì)所有該類(lèi)的對(duì)象實(shí)例而言是共享的，即只在內(nèi)存中保存一份拷貝，這樣節(jié)約了不比要的內(nèi)存開(kāi)銷(xiāo)。但是static生命周期較長(zhǎng)，而且不容易被垃圾回收機(jī)制所回收，所以要合理運(yùn)用，不要適得其反。建議在全部具備下列條件的情況下盡量使用靜態(tài)變量：

1），變量所包含的對(duì)象體積較大，占用內(nèi)存較多。

2），變量所包含的對(duì)象生命周期較長(zhǎng)。

3），變量所包含的對(duì)象數(shù)據(jù)穩(wěn)定。

4），該類(lèi)的對(duì)象實(shí)例有對(duì)該變量所包含的對(duì)象的共享需求。

在我的程序中對(duì)靜態(tài)變量的優(yōu)化后，使程序占用內(nèi)存量至少提升了5k-10k。所以也不容忽視。

還有就是String類(lèi)相關(guān)的東西：1。字符串累加的時(shí)候一定要用StringBuffer的append方法，不要使用+操作符連接兩個(gè)字符串。差別很大。而且在循環(huán)或某些重復(fù)執(zhí)行的動(dòng)作中不要去創(chuàng)建String對(duì)象，因?yàn)镾tring對(duì)象是要用StringBuffer對(duì)象來(lái)處理的，一個(gè)String對(duì)象應(yīng)該是產(chǎn)生了3個(gè)對(duì)象（大概是這樣：））。

2，字符串length()方法來(lái)取得字符串長(zhǎng)度的時(shí)候不要把length放到循環(huán)中，可以在循環(huán)外面對(duì)其取值。(包括vector的size方法)。特別是循環(huán)次數(shù)多的時(shí)候，盡量把length放到循環(huán)外面。

intsize=xmlVector.size();

for(inti=2;i

。。。

}

在程序中我曾經(jīng)誤寫(xiě)了這樣一句：if(i=5){...}，編譯器沒(méi)有報(bào)錯(cuò)，而且結(jié)果好像是把i的值改變了，沒(méi)有記清，大家有興趣可以測(cè)驗(yàn)下。書(shū)寫(xiě)上盡量認(rèn)真，否則查找bug的時(shí)候可能會(huì)折騰死人的。

關(guān)于優(yōu)化方面也就能想起這些來(lái)了，如果還有對(duì)大家有用的東西我再補(bǔ)充吧，希望大家多提寶貴意見(jiàn)。共同進(jìn)步嘛。