基於Android開發應用時，可能會時常出現Out Of Memory 異常。在被這個問題困擾的時候先得了解一下原因，重點當然是需要知道如何處理。
1、OOM的具體原因。
①一個進程的內存可以由2個部門組成：java 使用內存 ，C 使用內存 ，這兩個內存的和必需小於16M，不然就會出現各人熟悉的OOM。
②一旦內存分配給Java后，以后這塊內存縱然開釋后，也只能給Java的使用，這個估計跟java虛擬機里把內存分成好幾塊進行緩存的原因有關，反正C就別想用到這塊的內存了，所以要是Java突然占用了一個大塊內存，縱然很快開釋了，C能使用的內存 = 16M - Java某一瞬間占在的最大內存。
③而Bitmap的生成是路程經過過程malloc進行內存分配的，占用的是C的內存。
根據這個原理那么我們就可以有效的避免OOM的出現，具體我們可以做以下一些額外的工作來有效避免OOM。
2、幾點建議。
①對於java中不再使用的資源需要盡快的釋放，即設置成null，不要老是指望垃圾回收器為你工作。如果不設置成null，那么資源回收會受到一定的影響。
②盡量少用static方法和static成員。因為static的方法或成員被外部使用的話，而外部的牽引對象沒有對其進行釋放的話那么整個static的類都不會被釋放，也就造成內存泄漏。
③對於不再使用的bitmap應該手動調用recycle方法，並且設置成null。圖片還要盡量使用軟引用方式，這樣可以加快垃圾回收。
3、一些不恰當的處理。
網上也有些其他的處理方式，但總的來說個人覺得不太恰當。如：
①給圖片設置option，相對於壓縮圖片。個人覺得不可取。很多情況下圖片本來就不夠清晰，經過壓縮之后質量上有很大的問題，這還得看個人的取舍。
②更改app的heapsize大小。個人覺得這也不可取。這根本不是從本質上解決問題，因為OOM可能是你某處導致的內存泄露，這樣做只是推遲了OOM發生，一定程度上降低了OOM發生率（因為可能在還沒有達到heapsize最大值的時候就發生了GC）。android系統他有默認的heapsize的值，至於我們重新設置一個更大的會對整個系統或者其他應用造成什么樣的影響其實都是不可知的，所以還是用默認的。
總結：總的來說在代碼實現的過程中，每個環節都有可能是導致OOM的罪魁禍首，只是在圖片解碼的過程中體現出來了而已。所以在整個編碼過程中應該采用一些比較好的編碼方式，有時需要對程序進行多次優化來減少內存開銷。Java的垃圾回收機制某種程度上給我們帶了方便，但是在嵌入式方面還有一些不足，畢竟嵌入式的資源是非常珍貴的，一旦控制不好就會出現OOM。做代碼優化之前我們也需要深入理解垃圾回收機制，這樣才能有效的控制內存消耗。