基于Android開發(fā)應(yīng)用時(shí)，可能會挺時(shí)常出現(xiàn)Out Of Memory 異常.
在Android中，一個(gè)Process 只能使用16M內(nèi)存，要是超過了這個(gè)限定就會跳出這個(gè)異常。這樣就要求我們要時(shí)刻想著開釋資源。Java的回收工作是交給GC的，如何讓GC能實(shí)時(shí)的回收已經(jīng)不是用的對象，這個(gè)里面有許多技巧，各人可以google一下。
因?yàn)榭們?nèi)存的施用超過16M而引起OOM的情況，非常簡單，我就不繼續(xù)展開說。值當(dāng)注意的是Bitmap在不用時(shí)，肯定是要recycle，不然OOM是非常容易出現(xiàn)的。
本文想跟各人一起討論的是另外一種情況：明明還有許多內(nèi)存，但是發(fā)生OOM了。
這類情況時(shí)常出現(xiàn)在生成Bitmap的時(shí)候。有興趣的可以試一下，在一個(gè)函數(shù)里生成一個(gè)13m 的int數(shù)組。
再該函數(shù)結(jié)束后，按理說這個(gè)int數(shù)組應(yīng)該已經(jīng)被開釋了，或者說可以開釋，這個(gè)13M的空間應(yīng)該可以空出來，
這個(gè)時(shí)候要是你繼續(xù)生白手起家的百萬富翁成一個(gè)10M的int數(shù)組是沒有問題的，反而生成一個(gè)4M的Bitmap就會跳出OOM。這個(gè)就奇怪了，為啥子10M的int夠空間，反而4M的Bitmap不敷呢？
這個(gè)問題困擾好久，在網(wǎng)上，國外各大論壇搜刮了好久，一般關(guān)于OOM的解釋和解決方法都是，如何讓GC盡快回收的代碼風(fēng)格之類，并沒有現(xiàn)實(shí)的支出上面所說的情況的根源。
直到昨天在一個(gè)老外的blog上終于看到了這方面的解釋，我理解后歸納如下：
在Android中：
1.一個(gè)進(jìn)程的內(nèi)存可以由2個(gè)部門組成：java 施用內(nèi)存 ，C 施用內(nèi)存 ，這兩個(gè)內(nèi)存的和必需小于16M，不然就會出現(xiàn)各人熟悉的OOM，這個(gè)就是熬頭種OOM的情況。
2.越發(fā)奇怪的是這個(gè)：一朝內(nèi)存分配給Java后，以后這塊內(nèi)存縱然開釋后，也只能給Java的施用，這個(gè)估計(jì)跟java虛擬機(jī)里把內(nèi)存分成好幾塊進(jìn)行緩存的原因有關(guān)，反正C就別想用到這塊的內(nèi)存了，所以要是Java突然占用了一個(gè)大塊內(nèi)存，縱然很快開釋了：
C能施用的內(nèi)存 = 16M - Java某一瞬間占在校大學(xué)生創(chuàng)業(yè)點(diǎn)子用的最大內(nèi)存。
而Bitmap的生成是路程經(jīng)過過程malloc進(jìn)行內(nèi)存分配的，占用的是C的內(nèi)存，這個(gè)也就說明了，上面所說的的4MBitmap無法生成的原因，因?yàn)樵?3M被Java用過后，剩下C能用的只有3M了。
http://blog.csdn.net/ghg8699/article/details/6586853
posted on 2011-07-03 13:30
小果子 閱讀(565)
評論(0) 編輯 收藏 引用 所屬分類:
學(xué)習(xí)筆記 、
Android & Ios