原因：系统为每一个应用程序分配了不同的内存上限，如果超过这个上限被视为内存泄露，从而被kill掉。
比如：
1.加载对象过大 2.相应资源过多，来不及加载。 —
解决办法们
oom这个真的不好权衡，下面这些注意事项好多是相互矛盾的，根据业务，各取所需吧。 而且一味的追求小内存开销，也不好。 毕竟，硬件本身的性能越来越强大，你不用，它也会老化。
一、图片
1.内存中加载图片直接在内存中做处理（如边界压缩）
2.减少Bitmap对象的内存占用
1.加载之前先计算出合适的缩放比例 2.选择合适的解码格式：ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，内存在很大差异。
3.临时Bitmap的及时回收
二、对象
1.动态回收内存
2.内存引用上做一些处理。（eg：软引用）
3.对象的复用
1.复用系统自带的资源:字符串、图片、动画、样式、颜色、简单布局 2.列表（eg:ListView）中对视图的复用 3.实例对象的复用：inBitmap属性可以告知Bitmap解码器使用已经存在的内存区域而不是重新申请一块内存区域 4.避免对象的频繁创建（eg：在onDraw（）、循环中创建对象等） 5.StringBuilder替代””+”“的拼接 6.用Integer.toString代替String.valueOf(int)和 int+””;(因为String会做很多业务上不必要的判断。（其实这应该算是性能问题了哈:）
4.当心对象的复用
比如static对象：因为这玩意和应用进程一样长命
5.注意单例模式中的不合理持有
虽然单例模式有效的避免了对象的多出创建，但缺点也在这里：单例的生命周期和应用保持一致（static），使用不合理很容易出现持有对象的泄漏。
6.注意监听器的及时注销
7.避免使用枚举Enum（好多时候用枚举就图个好看）
8.使用更加轻量的数据结构
考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构。因为HashMap需要一个额外的实例对象来记录Mapping的操作。
9.如果没有必要，就不要用抽象类
因为抽象类这些一般都没有正经的事做。 —
三、页面上
1.优化布局层次,减少内存开销
2.Activity方面的问题
1.Activity对静态变量的持有问题 2.页面回收时记得清空Handler消息队列 3.Activity Context被其他实例持有
3.webview的泄露
Android不同版本对webview产生有很大差异。 常用的办法：为webview新开一个进程，通过AIDL与主进程通信。（在需要的时候对webView进行销毁
四、系统
1.自定义堆内存大小
2.优化Delivk虚拟机的堆内存分配
3.申请大内存large heap
谨慎使用!这可能会影响整个系统的用户体验。
4.Services用完及时停止。
因为这货的优先级一般较高，系统一般不会吧Service所占用的RAM空间腾出来让给其他组件
5.谨慎使用多进程
多进程可以把应用中的部分组件运行在单独的进程当中,系统一般会给多进程分配更多的内存， 但是这会显著增加代码的逻辑复杂度，而且容易成为业界的毒瘤。
6.注意第三方libraries的应用
一般你是不会用到一个libraries的所有功能的，这就存在用内存去养那些你压根就不会用的对象