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)、尽量扩大只读结构的大小，借以提高跨进程的数据共享