版权声明：本文为博主原创文章，转载请注明原帖地址，谢谢 https://blog.csdn.net/AooMiao/article/details/68957330
内存溢出（OOM）:内存使用量大于JVM分配内存大小
- 加载对象过大
- 相对资源过多，内存来不及释放
- 发生内存泄漏
内存优化:
- 重写Activity（或Fragment 、Service、Application、ContentProvider）的OnTrimMemory()方法，此方法的调用时刻都是系统内存不足的时候，并且根据传进Int参数，判定是内存快不足的哪种时刻，根据情景释放内存
- TRIM_MEMORY_COMPLETE：内存不足，并且该进程在后台进程列表最后一个，马上就要被清理
- TRIM_MEMORY_MODERATE：内存不足，并且该进程在后台进程列表的中部。
- TRIM_MEMORY_BACKGROUND：内存不足，并且该进程是后台进程。
- TRIM_MEMORY_UI_HIDDEN：内存不足，并且该进程的UI已经不可见了(界面不可以可以释放UI内存)
- 节制使用Service，因为android系统不太倾向于回收开启Service的进程，可以使用Service的子类IntentService，里面的执行逻辑都在子线程执行，并且执行完后还会帮我们关闭Service
- 创建对象时能使用基本数据类型就使用基本数据类型，基本数据类型>对象数据类型，单线程使用字符串可以用StringBuilder
- ListView的adapter使用缓存contvertView和内部类ViewHolder，可以避免创建不必要的对象，占用内存
- 对于常量可以使用static final关键字，加快运行速度
内存泄漏：拥有长期生命周期的对象持有短期生命周期对象的引用
- 数据库游标Cursor没关闭
- 广播接收器使用完没有注销
- 输入输出流没有关闭
- Bitmap使用后没有调用recycle()释放资源
- Content泄漏：单例设计模式
- 静态集合类：HashMap、Vector，使用完要记得释放对象
- Handler泄漏：因为内部类潜在持有外部类的引用，若在handler执行一个延迟的逻辑，在延迟期间外部类不能被GC回收，造成泄漏
- 非静态内部类被异步线程所持有，和handler类似
解决：尽量使用静态内部类，这样就不会持有外部类的引用了，对长生命周期的对象使用软引用或弱引用