内存溢出(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类似
解决:尽量使用静态内部类,这样就不会持有外部类的引用了,对长生命周期的对象使用软引用或弱引用