在Android中，一个Process 只能使用16M内存，要是超过了这个限定就会跳出这个异常。这样就要求我们要时刻想着开释资源。Java的回收工作是交给GC的，如何让GC能实时的回收已经不被用的对象，这个里面有许多技巧，各人可以google一下。
因为总内存的施用超过16M而引起OOM的情况，非常简单，我就不继续展开说。值当注意的是Bitmap在不用时，肯定是要recycle，不然OOM是非常容易出现的。
本文想跟大家一起讨论的是另外一种情况：明明还有许多内存，但是发生OOM了。
这类情况时常出现在生成Bitmap的时候。有兴趣的可以试一下，在一个函数里生成一个13M的int数组。
再该函数结束后，按理说这个int数组应该已经被开释了，或者说可以开释，这个13M的空间应该可以空出来，
这个时候要是你继续生成一个10M的int数组是没有问题的，反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了，为啥子10M的int数组够空间，反而4M的Bitmap不够呢？
这个问题困扰好久，在网上，国外各大论坛搜刮了好久，一般关于OOM的解释和解决方法都是，如何让GC尽快回收的代码风格之类，并没有找出上面所说的情况的根源。
直到昨天在一个老外的blog上终于看到了这方面的解释，我理解后归纳如下：
在Android中：
1.一个进程的内存可以由2个部分组成：java 施用内存 ，C 施用内存 ，这两个内存的和必需小于16M，不然就会出现大家熟悉的OOM。
2.越发奇怪的是这个：一朝内存分配给Java后，以后这块内存纵然开释后，也只能给Java的施用，这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关，反正C就别想用到这块的内存了，所以要是Java突然占用了一个大块内存，纵然很快开释了：
C能施用的内存 = 16M - Java某一瞬间占用的最大内存。
而Bitmap的生成是通过malloc进行内存分配的，占用的是C的内存，这个也就说明了，上面所说的的4MBitmap无法生成的原因，因为在13M被Java用过后，剩下C能用的只有3M了。
因为总内存的施用超过16M而引起OOM的情况，非常简单，我就不继续展开说。值当注意的是Bitmap在不用时，肯定是要recycle，不然OOM是非常容易出现的。
本文想跟大家一起讨论的是另外一种情况：明明还有许多内存，但是发生OOM了。
这类情况时常出现在生成Bitmap的时候。有兴趣的可以试一下，在一个函数里生成一个13M的int数组。
再该函数结束后，按理说这个int数组应该已经被开释了，或者说可以开释，这个13M的空间应该可以空出来，
这个时候要是你继续生成一个10M的int数组是没有问题的，反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了，为啥子10M的int数组够空间，反而4M的Bitmap不够呢？
这个问题困扰好久，在网上，国外各大论坛搜刮了好久，一般关于OOM的解释和解决方法都是，如何让GC尽快回收的代码风格之类，并没有找出上面所说的情况的根源。
直到昨天在一个老外的blog上终于看到了这方面的解释，我理解后归纳如下：
在Android中：
1.一个进程的内存可以由2个部分组成：java 施用内存 ，C 施用内存 ，这两个内存的和必需小于16M，不然就会出现大家熟悉的OOM。
2.越发奇怪的是这个：一朝内存分配给Java后，以后这块内存纵然开释后，也只能给Java的施用，这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关，反正C就别想用到这块的内存了，所以要是Java突然占用了一个大块内存，纵然很快开释了：
C能施用的内存 = 16M - Java某一瞬间占用的最大内存。
而Bitmap的生成是通过malloc进行内存分配的，占用的是C的内存，这个也就说明了，上面所说的的4MBitmap无法生成的原因，因为在13M被Java用过后，剩下C能用的只有3M了。
