1 內(nèi)容介紹
隨著現(xiàn)在的手機品牌越來越多，本來J2ME的手機性能相對于智能機來說就差，加上現(xiàn)在流行的MTK，這樣導致手機的CPU，內(nèi)存就更少的了。這篇文章就是怎么樣解決這些小內(nèi)存，CPU，RMS都嚴重受限的參考文檔。
預期讀者
本文主要適合那些有經(jīng)驗的J2ME程序員在優(yōu)化軟件，或者是需要考慮軟件兼容性時的參考文檔。
2 優(yōu)化筆記
J2me程序由于其非凡的運行環(huán)境限制，所以優(yōu)化就顯得比較重要，以下是我在學習j2me編程所收集的一些技巧和自己的心得。
1.顯示圖象時確定好你的fps，先做幾次小實驗，這樣能讓你在顯示效果和運行速度上有比較好的平衡。
2.GamaCanvas.getGraphics()每次都會產(chǎn)生一個全新的對象，但是對這些對象的操作都是對同一個graphics，所以還是只取一次供后面使用。
3.讓多個對象使用同樣的監(jiān)聽器，比如讓主MIDlet類實現(xiàn)CommandListener和ItemStateListener接口。
4.考慮使用手機開發(fā)商提供的一些sdk，沒人會比他們更了解他們手機，所以有些時候能顯著提高速度，特別是是圖片，視頻使用方面。
這里推薦使用的模擬器是Nokia S40，Moto SDK 6.11 這些模擬器在模擬的過程中幾乎與真機一樣。相當?shù)臏蚀_。
5.使用監(jiān)視工具分析MIDlet的瓶頸，wtk和各個公司提供的開發(fā)包里都會有，可以找到程序的弱點。假如是在手機上，用timer測試你認為有可以的地方。
在這里，開發(fā)Http，Socket網(wǎng)絡的時候，打開相關的監(jiān)視器，這樣可以知道你的程序到底發(fā)送了些什么數(shù)據(jù)
6.使用System.gc()，在無線程阻塞的情況下可以有效的緩解內(nèi)存壓力，但是有些公司不是太推薦使用(如nokia).sun的說法也是越低端的機子執(zhí)行的越慢，總之，慎用吧。
7.用固定的數(shù)組代替使用Vector。使用System.copyArray等native方法，這樣比你自己寫的效率要高
8.圖片的優(yōu)化�？紤]使用設備的規(guī)格，可能高分辨率的圖片不一定顯示的出來。一般建議使用128色就可以了。
9.不用的對象賦值為null，為更快的回收。特別是字符串，Vector，Hashtable等類變量。如果你的class，寫了很多的 Hashtable，Vector，Object[]的變量的話，建議你構(gòu)建一個clear的方法，并在方法里面把那些容器變量先干掉，然后再把 class賦值為null。
10.用混淆器處理你的類文件，防止反編譯，還有一個好的副作用就是它減小class文件的大小，因為混淆器往往用較短的字符串代替原來的變量或方法名。
11.若數(shù)據(jù)太大，可以將數(shù)據(jù)編碼為字符串，運行時解碼，或把數(shù)據(jù)存為二進制文件并與程序打包，用類裝載器的getResourceAsStream方法在運行時存取。
12.使用現(xiàn)有的類，比如你使用了GameCanvas，就不用自己生成off-screen，另外像CLDC的profile沒有構(gòu)造集合類，所以我們可以用內(nèi)建的Hashtable和Vector類來實現(xiàn)。
13.用優(yōu)化軟件jPresto(http://www.s5systems.com/jPresto.htm)---沒用過，不過暫且寫上吧。
假如對文件大小，內(nèi)存限制非常嚴格，這時候就只能用一些非常規(guī)的方法了，可能這些方法背離了OO思想，但是多數(shù)情況下，它是起到了非常積極的作用的(但是也可能)，假如你更在意于程序的維護和擴展方面，我建議你還是跳過吧 -_-
14.把所有資源文件做成一個數(shù)據(jù)文件。然后在程序中寫一個算法，進行解碼
15.把所有的小圖片文件做成一個文件，在運行時再"切割"開。
很多張小icon的時候，可以通過合并工具把這些icon合并成一種大的png圖片，然后在程序中對這些圖片進行切割。用Image.createImage(src, x,y,w,h)進行切割。
16.使用有限的面向?qū)ο�，因為純粹的OO往往意味著更多的虛方法，更多的層次關系，更多的class
17.生成盡可能少的class，class都有一定的系統(tǒng)開銷。 18.class中生成盡可能少的方法。速度比較：同步方法<接口方法<實例方法 19.用final static限定方法可以獲得小幅的速度提高。
20.對數(shù)據(jù)成員用public限定，來代替get和set方法，不過要注重安全性。
其他歸類
*只優(yōu)化需要的代碼
*只在有價值的地方優(yōu)化
*用profiler來找要優(yōu)化的地方
*在具體的設備上profiler無能為力，在硬件上使用System timer
*在于用低級技術(shù)之前，總是先研究你的代碼并且試著改進算法
*繪圖是慢的，所以盡量節(jié)儉地使用圖形調(diào)用
*在可以減少繪制區(qū)域的地方使用setClip()
*盡可能的把東西放到循環(huán)之外
*拼命地預先計算和暫存
*字符串帶來垃圾，垃圾不好，所以使用StringBuffers來代替
*什么都不假設
*可能就使用static final方法，避免synchronized修飾符
*傳遞盡可能少的參數(shù)到經(jīng)常調(diào)用的方法
*如果可能，完全地去掉函數(shù)調(diào)用
*解開循環(huán)
*對2的冪的乘除運算用位移運算代替
*你可以使用位運算符代替取模運算來實現(xiàn)循環(huán)
*試著用零來代替和其他數(shù)的比較
*數(shù)組訪問比C要慢，所以暫存數(shù)組元素
*消去公共的子表達式
*局部變量要比引用變量快
*如果可以callSerially()就不要wait()
*在switch()中使用小的變量作選項
*檢查定點數(shù)學庫并且優(yōu)化它
*拆開嵌套的FP調(diào)用來減少類型轉(zhuǎn)換
*除法比乘法慢，所以用乘于倒數(shù)來代替除法
*用使用過和測試過的算法
*為了保護可移植性，小心地使用私有高性能API。
J2ME優(yōu)化可能使你的程序在不同的模擬器，不同的設備下有不同的運行效果，所以 優(yōu)化一定要建立在開發(fā)設備的規(guī)格上。
以上所列舉的方法不一定在所有midp設備上都起作用，也不一定都適合每一個程序，總之，應該根據(jù)自身的情況。
3 注意事項
1.內(nèi)存的管理
2.圖片資源的管理
3.圖片資源的管理
4.字符串的管理
5.Vector，Hashtabe等管理
4 參考資料
ITPUT的移動開發(fā)技術(shù) 頻道 http://publish.itpub.net/lists/7826/0
隨著現(xiàn)在的手機品牌越來越多，本來J2ME的手機性能相對于智能機來說就差，加上現(xiàn)在流行的MTK，這樣導致手機的CPU，內(nèi)存就更少的了。這篇文章就是怎么樣解決這些小內(nèi)存，CPU，RMS都嚴重受限的參考文檔。
預期讀者
本文主要適合那些有經(jīng)驗的J2ME程序員在優(yōu)化軟件，或者是需要考慮軟件兼容性時的參考文檔。
2 優(yōu)化筆記
J2me程序由于其非凡的運行環(huán)境限制，所以優(yōu)化就顯得比較重要，以下是我在學習j2me編程所收集的一些技巧和自己的心得。
1.顯示圖象時確定好你的fps，先做幾次小實驗，這樣能讓你在顯示效果和運行速度上有比較好的平衡。
2.GamaCanvas.getGraphics()每次都會產(chǎn)生一個全新的對象，但是對這些對象的操作都是對同一個graphics，所以還是只取一次供后面使用。
3.讓多個對象使用同樣的監(jiān)聽器，比如讓主MIDlet類實現(xiàn)CommandListener和ItemStateListener接口。
4.考慮使用手機開發(fā)商提供的一些sdk，沒人會比他們更了解他們手機，所以有些時候能顯著提高速度，特別是是圖片，視頻使用方面。
這里推薦使用的模擬器是Nokia S40，Moto SDK 6.11 這些模擬器在模擬的過程中幾乎與真機一樣。相當?shù)臏蚀_。
5.使用監(jiān)視工具分析MIDlet的瓶頸，wtk和各個公司提供的開發(fā)包里都會有，可以找到程序的弱點。假如是在手機上，用timer測試你認為有可以的地方。
在這里，開發(fā)Http，Socket網(wǎng)絡的時候，打開相關的監(jiān)視器，這樣可以知道你的程序到底發(fā)送了些什么數(shù)據(jù)
6.使用System.gc()，在無線程阻塞的情況下可以有效的緩解內(nèi)存壓力，但是有些公司不是太推薦使用(如nokia).sun的說法也是越低端的機子執(zhí)行的越慢，總之，慎用吧。
7.用固定的數(shù)組代替使用Vector。使用System.copyArray等native方法，這樣比你自己寫的效率要高
8.圖片的優(yōu)化�？紤]使用設備的規(guī)格，可能高分辨率的圖片不一定顯示的出來。一般建議使用128色就可以了。
9.不用的對象賦值為null，為更快的回收。特別是字符串，Vector，Hashtable等類變量。如果你的class，寫了很多的 Hashtable，Vector，Object[]的變量的話，建議你構(gòu)建一個clear的方法，并在方法里面把那些容器變量先干掉，然后再把 class賦值為null。
10.用混淆器處理你的類文件，防止反編譯，還有一個好的副作用就是它減小class文件的大小，因為混淆器往往用較短的字符串代替原來的變量或方法名。
11.若數(shù)據(jù)太大，可以將數(shù)據(jù)編碼為字符串，運行時解碼，或把數(shù)據(jù)存為二進制文件并與程序打包，用類裝載器的getResourceAsStream方法在運行時存取。
12.使用現(xiàn)有的類，比如你使用了GameCanvas，就不用自己生成off-screen，另外像CLDC的profile沒有構(gòu)造集合類，所以我們可以用內(nèi)建的Hashtable和Vector類來實現(xiàn)。
13.用優(yōu)化軟件jPresto(http://www.s5systems.com/jPresto.htm)---沒用過，不過暫且寫上吧。
假如對文件大小，內(nèi)存限制非常嚴格，這時候就只能用一些非常規(guī)的方法了，可能這些方法背離了OO思想，但是多數(shù)情況下，它是起到了非常積極的作用的(但是也可能)，假如你更在意于程序的維護和擴展方面，我建議你還是跳過吧 -_-
14.把所有資源文件做成一個數(shù)據(jù)文件。然后在程序中寫一個算法，進行解碼
15.把所有的小圖片文件做成一個文件，在運行時再"切割"開。
很多張小icon的時候，可以通過合并工具把這些icon合并成一種大的png圖片，然后在程序中對這些圖片進行切割。用Image.createImage(src, x,y,w,h)進行切割。
16.使用有限的面向?qū)ο�，因為純粹的OO往往意味著更多的虛方法，更多的層次關系，更多的class
17.生成盡可能少的class，class都有一定的系統(tǒng)開銷。 18.class中生成盡可能少的方法。速度比較：同步方法<接口方法<實例方法
20.對數(shù)據(jù)成員用public限定，來代替get和set方法，不過要注重安全性。
其他歸類
*只優(yōu)化需要的代碼
*只在有價值的地方優(yōu)化
*用profiler來找要優(yōu)化的地方
*在具體的設備上profiler無能為力，在硬件上使用System timer
*在于用低級技術(shù)之前，總是先研究你的代碼并且試著改進算法
*繪圖是慢的，所以盡量節(jié)儉地使用圖形調(diào)用
*在可以減少繪制區(qū)域的地方使用setClip()
*盡可能的把東西放到循環(huán)之外
*拼命地預先計算和暫存
*字符串帶來垃圾，垃圾不好，所以使用StringBuffers來代替
*什么都不假設
*可能就使用static final方法，避免synchronized修飾符
*傳遞盡可能少的參數(shù)到經(jīng)常調(diào)用的方法
*如果可能，完全地去掉函數(shù)調(diào)用
*解開循環(huán)
*對2的冪的乘除運算用位移運算代替
*你可以使用位運算符代替取模運算來實現(xiàn)循環(huán)
*試著用零來代替和其他數(shù)的比較
*數(shù)組訪問比C要慢，所以暫存數(shù)組元素
*消去公共的子表達式
*局部變量要比引用變量快
*如果可以callSerially()就不要wait()
*在switch()中使用小的變量作選項
*檢查定點數(shù)學庫并且優(yōu)化它
*拆開嵌套的FP調(diào)用來減少類型轉(zhuǎn)換
*除法比乘法慢，所以用乘于倒數(shù)來代替除法
*用使用過和測試過的算法
*為了保護可移植性，小心地使用私有高性能API。
J2ME優(yōu)化可能使你的程序在不同的模擬器，不同的設備下有不同的運行效果，所以 優(yōu)化一定要建立在開發(fā)設備的規(guī)格上。
以上所列舉的方法不一定在所有midp設備上都起作用，也不一定都適合每一個程序，總之，應該根據(jù)自身的情況。
3 注意事項
1.內(nèi)存的管理
2.圖片資源的管理
3.圖片資源的管理
4.字符串的管理
5.Vector，Hashtabe等管理
4 參考資料
ITPUT的移動開發(fā)技術(shù) 頻道 http://publish.itpub.net/lists/7826/0
