Android----内存溢出、内存优化、内存泄漏

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