淺談J2ME內(nèi)存占用及優(yōu)化方法

1、 占用量,在載入一張很大的圖片后它的內(nèi) 存線在只出現(xiàn)了微微的波動(dòng)后又停留在原 位。 在平時(shí)的開發(fā)過程當(dāng)中使用 7210模擬 器自帶的內(nèi)存監(jiān)視器,模擬的準(zhǔn)確率較 高,但唯一的缺點(diǎn)是內(nèi)存太少,只有可憐 200K。在使用 3220的模擬器監(jiān)視內(nèi)存, 內(nèi)存會(huì)稍微擴(kuò)大。Runtime 類方法:在開發(fā)過程當(dāng)中,我們會(huì)經(jīng)常用這個(gè) 語句System.out.println(Runtime. getRuntime(.freeMemory(;它能夠顯示當(dāng) 前剩余內(nèi)存。在早期的 S40模擬器上使用 這一方法,可以尋找到內(nèi)存峰值。了解了分析內(nèi)存的方法,來看看內(nèi)存 占用的罪魁禍?zhǔn)?程序和資源。程序 :類會(huì)被編譯成cla

2、ss字節(jié)碼文件 隨 MIDlet 的啟動(dòng)加載進(jìn)內(nèi)存, 而且是一次 性全部加入。也就是說 MIDlet 里類個(gè)數(shù)越 多、單個(gè)類程序越長(zhǎng)、類內(nèi)字符串常量及 數(shù)據(jù)越多, 編譯后的class文件就越大, 載 入 后 占 用 的 內(nèi) 存 也 越 多 。 我 們 可 以 在 MIDlet 類的構(gòu)造函數(shù)里用 Runtime 方法來 查看 MIDlet 啟動(dòng)后整個(gè)程序占用內(nèi)存量。資 源 :圖片:是占用內(nèi)存的大戶,尤其是 手機(jī)游戲圖片資源眾多。對(duì)圖片資源在內(nèi) 存中占用量的計(jì)算成為 J2ME 游戲開發(fā)者 的經(jīng)常性工作,那么如何計(jì)算圖片在內(nèi)存 中的占用量呢?內(nèi)存占用量 =寬*高*像素字節(jié)數(shù), 其 中像素字節(jié)數(shù)因機(jī)型

3、而異。例如一張 64*64的圖片在 7210上的內(nèi) 存占用量 =64*64*1.5=6144(字節(jié)=6K、在 S60上的內(nèi)存占用量=64*64*2=8192(字節(jié) =8K。像素字節(jié)數(shù)因機(jī)型而異,例如 7210是 4096色機(jī)型,也就是說用 12位來表示 一個(gè)像素,所以乘上 1.5,而 S60是 65536色的機(jī)型,用 16位來表示一個(gè)像素,所 以乘上 2。聲音:聲音也是比較耗用內(nèi)存的資 源,聲音中音軌所占的 byte 會(huì)轉(zhuǎn)化成字節(jié) 流被載入到內(nèi)存中。因而減少音軌所占 byte 即可減少內(nèi)存耗用量。淺談 J2ME 內(nèi)存 占用及優(yōu)化方法宮兵大連職工大學(xué)116021隨著移動(dòng)通信的突飛猛進(jìn),移動(dòng)開發(fā)

4、這個(gè)新鮮的字眼慢慢成為開發(fā)者關(guān)注的熱 點(diǎn)。在網(wǎng)上進(jìn)行的最近一份調(diào)查顯示,有 24.34%的受訪者涉足嵌入式 /移動(dòng)設(shè)備應(yīng) 用開發(fā),這個(gè)數(shù)字可能略高于實(shí)際的比 例,但也足可說明嵌入式 /移動(dòng)設(shè)備應(yīng)用 開發(fā)是一塊誘人的新鮮奶酪。J2ME 是 SUN 公司針對(duì)嵌入式、消費(fèi) 類電子產(chǎn)品推出的開發(fā)平臺(tái),與 J2SE 和 J2EE 共同組成 Java 技術(shù)的三個(gè)重要的分 支。J2ME 實(shí)際上是一系列規(guī)范的集合,由 J C P 組 織 制 定 相 關(guān) 的 JavaSpecificationRequest (JSR 并發(fā)布, 各個(gè)廠商會(huì)按照規(guī)范在自己的產(chǎn)品上進(jìn)行 實(shí)現(xiàn),但是必須要通過 TCK 測(cè)試,這樣確 保

5、兼容性。一、內(nèi)存占用容性做過 J2ME 的人,特別是做手機(jī)游戲 的,肯定會(huì)對(duì) OutOfMemoryError 這個(gè)異 常深惡痛絕, 尤其是在早期的S40這樣的機(jī) 型上,甚至對(duì)這個(gè)異常都產(chǎn)生了恐懼。首先分析一下內(nèi)存占用的方法,一般 有 兩 種 :模擬器自帶工具和 Runtime 類方法:模擬器自帶工具:W T K 自身帶有了 一個(gè) MemoryMonitor,而且在許多資料上 都有介紹其使用方法,但在實(shí)際的開發(fā)過 程中并沒有被普遍應(yīng)用。其主要的原因在 于,首先運(yùn)行 WTK 中的 MemoryMonitor 時(shí),會(huì)導(dǎo)致整個(gè)程序的運(yùn)行速度大大降 低,這對(duì)游戲開發(fā)者來說是無法忍受的。 經(jīng) 過 多 次

6、 的 試 驗(yàn) 證 明 發(fā) 現(xiàn) 原 來 MemoryMonitor 根本無法顯示正確的內(nèi)存二、內(nèi)存優(yōu)化內(nèi)存優(yōu)化可以歸結(jié)為以下幾種方法。 代碼優(yōu)化,圖片優(yōu)化,第三方工具優(yōu)化。2.1代碼優(yōu)化內(nèi)存會(huì)溢出肯定和代碼逃不了關(guān)系, 絕大部分使用java進(jìn)行開發(fā)的人都知道垃 圾回收器是 java 的一大優(yōu)點(diǎn)。 顯然這個(gè)特 性為代碼編寫者省了不少事,但這個(gè)特性 卻帶來了不少隱患。舉個(gè)例子,在游戲當(dāng) 中經(jīng)常有不同場(chǎng)景的切換,如從游戲邏輯 退到主菜單邏輯,對(duì)游戲邏輯對(duì)象的態(tài)度 很多開發(fā)者會(huì)選擇等待垃圾回收器來自動(dòng) 回收。 乍看之下似乎并無不妥, 垃圾回收器 會(huì)來善后。 實(shí)際上垃圾回收器并非實(shí)時(shí)的, 它不像 C+的

7、Delete 語句馬上釋放不用的 內(nèi)存。 當(dāng)從游戲邏輯切換到主菜單邏輯, 這 時(shí)兩個(gè)對(duì)象同時(shí)存在,很可能這時(shí)內(nèi)存就 不夠用了。讀到這里很多人會(huì)發(fā)現(xiàn)實(shí)際上 垃圾回收器在 j2me 上并不是特別好用, 從 一個(gè)角度上來講在j2me上除簡(jiǎn)單類型以外 很 多 垃 圾 必 須 由 手 工 釋 放 , 例 如 imgs=null ; 實(shí)際上java提供了一個(gè)不錯(cuò)的 工具用來查找內(nèi)存溢出,j a v a . l a n g . Runtime.freeMemory(。 它可以返回當(dāng)前的 剩余內(nèi)存數(shù),將它適當(dāng)?shù)匕卜旁诖a中可 以有效地監(jiān)測(cè)內(nèi)存使用狀況。很大一部份的j2me程序員之前都是從 事 pc 軟件開發(fā)工

8、作, 充裕的內(nèi)存掩蓋了許 多寫代碼的不良習(xí)慣。如下所示:/a 不為空 a=newLogic(;很多人可能對(duì)此有異議,他們會(huì)認(rèn)為 新的對(duì)象會(huì)把舊的對(duì)象沖掉并且釋放內(nèi)存。 這里面包含兩個(gè)問題 :(1 .該段代碼是先創(chuàng) 建對(duì)象然后再進(jìn)行賦值操作的,也就是說 在這期間有兩個(gè)對(duì)象同時(shí)存在,這就很可 能會(huì)產(chǎn)生溢出。 (2 .這樣做也會(huì)妨礙垃圾回 收器的工作。較好的寫法如下:a=null;a=newLogic(;雖然麻煩了點(diǎn), 但在 j2me 中還是必要 的。接著看下例drawString(游戲時(shí)間:+time,50, 50,Graphics.LEFT|Graphics.TOP;游戲時(shí)間:+time在pai

9、nt(方法當(dāng)中 每次都被刷一遍顯示在屏幕上。但是,該 語句會(huì)引起新的內(nèi)存重新分配來存儲(chǔ) 游 戲時(shí)間:+time而顯示完以后又必須由垃圾 回收器釋放,用了雙倍時(shí)間, 并且容易發(fā)F E /G E 等數(shù)據(jù)業(yè)務(wù)的接入、傳送或處理。3.2ATM 組網(wǎng)技術(shù) 用 A T M 交換機(jī)組建 3G 傳輸網(wǎng),符合 W C D M A R 99/R 4的 A T M 傳輸特性,并可通過信元交換完成帶寬統(tǒng)計(jì)復(fù)用功能,提 高傳輸效率。但是由于 3G 設(shè)備和 A T M 交換機(jī)都有 A T M 交換功 能,整網(wǎng)解決方案存在著功能重疊;另外,A T M 設(shè)備不是傳輸 平臺(tái),其組網(wǎng)保護(hù)能力及 T D M 業(yè)務(wù)的支持能力較弱。因

10、此不建 議使用 A T M 設(shè)備來組建 3G 傳輸網(wǎng)。3.3IP組網(wǎng)技術(shù)目前IP網(wǎng)絡(luò)對(duì)業(yè)務(wù)質(zhì)量還無法提供電信級(jí)的保證。 IP網(wǎng)絡(luò)的 自愈能力雖然強(qiáng),但依賴路由協(xié)議的收斂速度慢,無法滿足各類 應(yīng)用要求。3G 的全 IP 組網(wǎng)目前還非常不成熟,在 3GPP 規(guī)范的 制定過程中,已經(jīng)推遲到 R5甚至以后的版本中。因此建設(shè)純粹 基于 IP 的網(wǎng)絡(luò)將不能很好地為 3G 網(wǎng)絡(luò)服務(wù),目前建設(shè) IP 網(wǎng)絡(luò)不 是理想的選擇。3.4MSTP 組網(wǎng)技術(shù)基于 S D H 的 M S T P 多業(yè)務(wù)平臺(tái)很好地融合了 S D H 、A T M IP 技術(shù),能夠提供多種業(yè)務(wù)接口和處理能力,可以根據(jù)網(wǎng)絡(luò)的發(fā) 展來動(dòng)態(tài)調(diào)整 A T M 、I P 、T D M 網(wǎng)絡(luò)的容量,實(shí)現(xiàn)高效的傳送。 從 W C D M A 的發(fā)展情況來看,目前的商用化的版本 R 99、R 4網(wǎng) 絡(luò)采用 ATM 協(xié)議體系,將來向全網(wǎng) IP 模式逐步演進(jìn),屆時(shí),