简述Android OOM

什么是OOM

移动端内存有限，手机给每个应用分配大小有限（Google 源生OS分配的内存为16M或者24M，但是不同厂家的ROM会修改）。当你使用的内存空间接近阀值，实例化新对象，需要分配新的内存空间是。就会报Out of Memory。

产生OOM的主要情况

1.同时加载大量大内存对象。主要体现在加载大量Bitmap（如帧动画、RecyclerView），内存一下冲破阀值，产生OOM。

2.内存泄露。内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。当内存泄露到一定的量，接近阀值的时候，再去new新对象时就会OOM。

OOM的监测

查找内存泄漏可以使用Android Studio 自带的Android Profiler工具（Android Studio3.0之后不仅可以监测内存，还可以监测CPU和network），也可以使用Square产品的LeadCanary（帖一个使用说明地址http://www.jianshu.com/p/7db231163168）。

ps:看过一个面试问题。OOM能不能try/catch ? try/catch可以避免这次报错，但是没有真正处理内存问题，还是可能再下一分配内存的位置触发。

OOM的解决方式

加载大量图片

1. Bitmap压缩。BitmapFactory，可以修改质量。比如把ARGB.8888改成RGB.565，bitmap占用内存会缩小一半（但是去掉了透明度，有些图片没法直接转。Glide就默认设置的是RGB.565）。Options.inSampleSize可以压缩图片比例。

2. 缓存。LruCache是常用的第三方框架的图片缓存处理方式。LruCache使用一个LinkedHashMap简单的实现内存的缓存，没有软引用，都是强引用。如果添加的数据大于设置的最大值，就删除最先缓存的数据来调整内存。

3. 软引用&弱引用。当一个对象只有软引用的时候，如果内存不足就会回收。当一个对象只有弱引用的时候，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

4.替换.png图片。用较小的图片替换.png，比如jpg或者svg等。

内存泄露

1.静态变量导致内存泄露。如一个静态变量持有当前Activity对象（但是很少有人会这么干吧）。

2.单例模式导致的内存泄露。单例模式的特点是它的生命周期与Application一致。所以单例模式实例化对象时，要用Application.context。

3.非静态内部类和匿名内部类导致的内存泄露。非静态内部类和匿名内部类隐式持有外部类的引用。Handler经常会不注意的时候写成匿名内部类，就造成内存泄露。

4.资源未关闭导致的内存泄露。资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，不使用的时候，应该及时关闭它们，否则会造成内存泄漏。

5.属性动画导致的内存泄露。属性动画中的无限循环动画，如果没有在onDestroy中停止，尽管界面上看不到动画效果，但是Activity还是被View持有，会导致内存泄露。

6.集合容器导致内存泄露。当不需要对象时，并没有把它的引用从集合中清理掉，也是一种内存泄露。

一些相关的细节

1.StringBuffer、StringBuilder和String一样，也用来代表字符串。String类是不可变类，任何对String的改变都会引发新的String对象的生成；StringBuffer、StringBuilder则是可变类，任何对它所指代的字符串的改变都不会产生新的对象。StringBuffer考虑了线程安全，StringBuilder没有。但是单线程StringBuilder效率更高。

2.内存抖动是由于短时间内有大量对象进出新生代区导致的，它伴随着频繁的GC。如在view的OnDraw方法中实例化对象，或者在循环中实例化不必要的对象。内存抖动可能会导致UI线程被频繁阻塞，画面卡顿。

总结

OOM是同时加载大量大内存图片或者gc无法及时回收对象，达到内存阀值之后的报错。需要通过写代码时注意和后期监测来避免。