1、出現這個問題的原因是由於Bitmap decode 引發的，我們知道，Android程序內存一般限制在16M，當然也有24M的，而android程序內存被分為2部分：native和dalvik：dalvik就是我們平常說的java堆，我們創建的對象是在這裡面分配的，而bitmap是直接在native上分配的，對於內存的限制是native+dalvik不能超過最大限制。
用以下命令可以查看程序的內存使用情況：
dumpsys meminfo 程序的包名或者進程id
多數時候，發生OOM 都是在做一些跟圖片相關的操作，以下提出一些建議盡量可以減少這種情況的發生：
decode bitmap 的時候，盡量配置下Options，例如：inSameSize
Bitmap使用完以後，調用 bitmap.recycle()來釋放內存
如果應用是基於圖片的應用，盡量采用LazyLoad和DymanicRecycle
decode bitmap 的時候，將decode代碼 try catch 出來，catch oom error，避免程序crash，可以在catch裡面做一些釋放內存操作
2、關於Android的Native內存和Dalvik內存
1)、Dalvik內存：
每一個Android應用在底層都會對應一個獨立的Dalvik虛擬機實例，其代碼在虛擬機的解釋下得以執行。
很多人認為Dalvik虛擬機是一個Java虛擬機，因為Android的編程語言恰恰就是Java語言。但是這種說法並不准確，因為 Dalvik虛擬機並不是按照Java虛擬機的規范來實現的，兩者並不兼容；
同時還要兩個明顯的不同：
(1)、Java虛擬機運行的是Java字節碼，而Dalvik虛擬機運行的則是其專有的文件格式DEX（Dalvik Executable）。
(2)、在Java SE程序中的Java類會被編譯成一個或者多個字節碼文件（.class）然後打包到JAR文件，而後Java虛擬機會從相應的CLASS文件和JAR文件中獲取相應的字節碼；Android應用雖然也是使用Java語言進行編程，但是在編譯成CLASS文件後，還會通過一個工具（dx）將應用所有的 CLASS文件轉換成一個DEX文件，而後Dalvik虛擬機會從其中讀取指令和數據。
2)、Dalvik虛擬機的簡介：
Dalvik虛擬機主要是完成對象生命周期的管理，堆棧的管理，線程管理，安全和異常的管理，以及垃圾回收等等重要功能。
Dalvik虛擬機的主要特征Dalvik虛擬機非常適合在移動終端上使用，相對於在桌面系統和服務器系統運行的虛擬機而言，它不需要很快的CPU速度和大量的內存空間。
Dalvik虛擬機有如下幾個主要特征：
(1)、專有的DEX文件格式
DEX是Dalvik虛擬機專用的文件格式，而問什麼棄用已有的字節碼文件（CLASS文件）而采用新的格式呢?一個應用中會定義很多類，編譯完成後即會有很多相應的CLASS文件，CLASS文件間會有不少冗余的信息；而DEX文件格式會把所有的 CLASS文件內容整合到一個文件中。這樣，除了減少整體的文件尺寸，I/O操作，也提高了類的查找速度。
(2)、增加了新的操作碼的支
(3)、文件結構盡量簡潔，使用等長的指令，借以提高解析速度
(4)、盡量擴大只讀結構的大小，借以提高跨進程的數據共享