對(duì)于Android開(kāi)發(fā)者來(lái)說(shuō)雖然使用了可以自動(dòng)管理內(nèi)存的Java語(yǔ)言，但是對(duì)于內(nèi)存管理不當(dāng)，可能你的應(yīng)用不斷出現(xiàn)類似INFO/dalvikvm-heap(10798): Grow heap (frag case) to 6.437MB for 1114126-byte allocation，而出現(xiàn)的
Grow heap 后面的值不斷增加，接下來(lái)輕微則Android系統(tǒng)開(kāi)始結(jié)束后臺(tái)任務(wù)來(lái)增加不斷增加的堆內(nèi)存問(wèn)題，最后可能直接出現(xiàn)OOM，同時(shí)有時(shí)候GC還可能出現(xiàn)GC freed 0 objects / 0 bytes in 75ms這樣的問(wèn)題，對(duì)于Java的內(nèi)存管理我們近期已經(jīng)說(shuō)到了，就上面這些問(wèn)題Android123給大家做一個(gè)簡(jiǎn)單的分析。

1. 這里Grow heap (frag case) to 6.437MB for 1114126-byte allocation表示你一直在分配一個(gè)較大的對(duì)象，占用的堆內(nèi)存達(dá)到了6.4MB。

2. 為什么會(huì)出現(xiàn)這樣的問(wèn)題，經(jīng)過(guò)詢問(wèn)表示是因?yàn)榉峙淞艘粋€(gè)byte[]數(shù)組，需要以Blob方式寫入SQLite數(shù)據(jù)庫(kù)，而造成的這么大的單個(gè)對(duì)象出現(xiàn)，這里Android開(kāi)發(fā)網(wǎng)提醒大家，這是很危險(xiǎn)的操作，對(duì)于不同固件和低RAM配置的設(shè)備隨時(shí)都有OOM的危險(xiǎn)，如果你真的需要往SQLite存儲(chǔ)二進(jìn)制，這里可以采用分段的方式，將某個(gè)對(duì)象拆分為1MB或更小，分更多的段來(lái)存放，中間加一層拆分?jǐn)?shù)據(jù)緩存層來(lái)解決比較好。

3. 同時(shí)每次構(gòu)造單個(gè)較大對(duì)象前，可以通知gc準(zhǔn)備收集，比如在執(zhí)行需要耗操作前執(zhí)行System.gc(); 防止OutOfMemoryError的發(fā)生，對(duì)于Java的內(nèi)存溢出問(wèn)題，今后我們會(huì)通過(guò)各種案例來(lái)講解。

最新評(píng)論