内存溢出（out of memory）

OOM指当前对象的内存占用已经超出分配内存的大小，这时未处理的异常就会抛出。过多的内存泄露会导致内存溢出，造成程序崩溃

造成内存溢出的原因：

1.内存泄漏导致；2.占用内存比较多的对象

如常见的内存溢出：

bitmap过大（显示像素过高或者图片尺寸远远大于显示空间尺寸时。通常要将bitmap缩放，减少暂占用内存）；

引用没释放（长时间保持某些资源的引用，导致GC(garbage collection垃圾回收)无法回收，该对象占用的内存就无法被使用。如activity被引用，在调用finish()之后却没有释放，第二次打开又重新创建，这样的内存泄露不断发生，就会导致内存的溢出）；

资源对象没关闭(Cursor/file等资源，会在finalize中关闭，但效率过低，易造成内存泄漏；SQLiteCurost当数据量大的时候容易泄漏)；

内存泄漏（memory leak）

有一些对象只有有限的生命周期。当它们的任务完成了之后，将会被GC回收。如果在对象的生命周期本该结束的时候，还被一系列的引用，就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。
如Activity.onDestory()被调用之后，view树和bitmap应该都被GC回收。如果一个正在运行的后台线程继续持有这个activity的引用，那么相关的内存将不会被回收，最终导致out OfMemoryError崩溃。
memory leak最终会导致OOM
内存泄漏的原因：
1.资源对象没关闭、集合类内存泄漏（资源对象没关闭：Cursor/file等资源，会在finalize中关闭，但效率过低，易造成内存泄漏；SQLiteCurost当数据量大的时候容易泄漏），属性动画在activity onDestory()的时候 animator.cancel()来停止动画

2.使用adapter时没有使用系统缓存的converview

3.没有及时调用recycle()释放不再使用的bitmap（释放之后建议bitmap= null;避免GC回收过慢等原因）

4.上下文的context用的是activity或者fragment。因此要使用application的context来代替activity相关的context，否则会在activity、fragment销毁时也不会销毁其内存（不要让生命周期长于activity的对象持有activity的引用）
在以下情况下不可以使用application
a.对话框创建的上下文
b.跳转到其它activity的上下文
c.创建布局layout或view要用到的上下文

5.广播注册没取消造成的内存泄漏

6.handler应该申请为static对象，并且在内部类中保存一个对外部类的弱引用

内存泄漏的分类：

1.常发性内存泄漏：发生内存泄漏的代码会被多次执行，每次执行都会导致一块内存泄漏

2.偶发性内存泄漏：发生内存泄漏的代码只有在特定环境或操作过程中才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性可能会变成常发性。因此测试环境和测试方法对检测内存泄漏尤其重要

3.一次性内存泄漏：发生内存泄漏的代码只会执行一次，或者由于算法上的缺陷，导致总有一块仅且有一块内存发生泄漏。如在类的构造函数中分配内存，在析构函数中却没有释放该内存，导致内存泄漏只会发生一次

4.隐私内存泄漏：程序在运行过程中不停地分配内存。但是在结束的时候才释放内存。严格来说并没有发生内存泄漏，因为程序最终还是释放了所有的内存。但是对于一个服务程序。需要运行几天甚至几个月。不及时释放内存也可能导致最终耗尽所有的内存。称这种内存泄漏为隐私内存泄漏

内存泄漏和内存溢出都不能通过try catch处理

内存泄漏的检测工具：leakcanary
参考来源