一、OOM介绍
1、VM运行时内存分析
JVM执行Java程序的过程中，会使用到各种数据区域，这些区域有各自的用途、创建和销毁时间。JVM包括下列几个运行时数据区域：
1.程序计数器(Program Counter Register)：
此内存区域是唯一一个在VM Spec中没有规定任何OutOfMemoryError情况的区域。2.Java虚拟机栈(Java Virtual Machine Stacks)：
在VM Spec中对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果VM栈可以动态扩展（VM Spec中允许固定长度的VM栈），当扩展时无法申请到足够内存则抛出OutOfMemoryError异常。3.本地方法栈(Native Method Stacks)：
和VM栈一样，这个区域也会抛出StackOverflowError和OutOfMemoryError异常。4.Java堆（Java Heap）
对于绝大多数应用来说，Java堆是虚拟机管理最大的一块内存。Java堆是被所有线程共享的，在虚拟机启动时创建。Java堆的唯一目的就是存放对象实例(以及数组)，绝大部分的对象实例都在这里分配。
Java堆内还有更细致的划分：新生代、老年代，再细致一点的：eden、from survivor、to survivor，甚至更细粒度的本地线程分配缓冲（TLAB）等。
根据VM Spec的要求，Java堆可以处于物理上不连续的内存空间，它逻辑上是连续的即可，就像我们的磁盘空间一样。实现时可以选择实现成固定大小的，也可以是可扩展的，不过当前所有商业的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中无法分配内存，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。5.方法区（Method Area）
- 6.运行时常量池(Runtime Constant Pool)：
运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法在申请到内存时会抛出OutOfMemoryError异常。
2、OOM出现原因
- 已知前提：
Android的应用程序所能申请的最大内存都是有限的 - 定义：
OOM是指APP向系统申请内存的请求超过了应用所能有的最大阀值的内存，系统无法再分配多余的空间，就会造成OOM - 出现原因：
1、持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM
持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM；
2、一次性申请很多内存（比如说一次创建大的数组或者是载入大的文件如图片的时候） - 造成结果：
发生oom错误，进程被强制kill掉，kill掉的进程内存会被系统回收
二、StrictMode介绍
StrictMode：严苛模式，主要用来检测程序中几种违例情况的Android原生开发者工具。 主要分为ThreadPolicy(线程检测策略)跟VmPolicy(虚拟机检测策略)两类检测内容：
1、ThreadPolicy
- detectDiskReads()--主线程读取文件
- detectDiskWrites()--主线程写文件
- detectNetwork()--主线程网络操作
- detectCustomSlowCalls()--自定义耗时操作
2、VmPolicy
- detectLeakedSqlLiteObjects--Sqlite对象泄漏
- detectActivityLeaks--Activity泄漏
- detectLeakedClosableObjects--未关闭的Closable对象泄露
- detectLeakedRegistrationObjects--广播注册后没取消注册
3、集成方式
可以按照不同场景需求选择检测不同违规操作。推荐在Application onCreate()方法中集成：
if (BuildConfig.DEBUG) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()//线程策略（ThreadPolicy）
.detectDiskReads()//检测在UI线程读磁盘操作
.detectDiskWrites()//检测UI线程写磁盘操作
.detectCustomSlowCalls()//发现UI线程调用的哪些方法执行得比较慢
.detectResourceMismatches()//最低版本为API23 发现资源不匹配
.detectNetwork() //检测在UI线程执行网络操作
.penaltyDialog()//一旦检测到弹出Dialog
.penaltyDropBox()//一旦检测到将信息存到DropBox文件夹中 data/system/dropbox
.penaltyLog()//一旦检测到将信息以LogCat的形式打印出来
.permitDiskReads()//允许UI线程在磁盘上读操作
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()//虚拟机策略（VmPolicy）
.detectActivityLeaks()//最低版本API11 用户检查 Activity 的内存泄露情况
.detectCleartextNetwork()//最低版本为API23 检测明文的网络
.detectFileUriExposure()//最低版本为API18 检测file://或者是content://
.detectLeakedClosableObjects()//最低版本API11 资源没有正确关闭时触发
.detectLeakedRegistrationObjects()//最低版本API16 BroadcastReceiver、ServiceConnection是否被释放
.detectLeakedSqlLiteObjects()//最低版本API9 资源没有正确关闭时回触发
.setClassInstanceLimit(TestLeakActivity.class, 2)//设置某个类的同时处于内存中的实例上限，可以协助检查内存泄露
.penaltyLog()
.build());
}
4、集成StrictMode后代码违规表现
由上面StrictMode API可知，检测到违规代码时，我们可以选择以应用崩溃/弹框/日志输出等形式表现出来。一般推荐输出到日志即可。下面简单列举下执行到代码中违规操作时日志表现：
- I/O流未关闭
2019-05-06 19:51:25.523 22941-22951/com.whh.strictmode E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'close' not called
at dalvik.system.CloseGuard.open(CloseGuard.java:180)
at java.io.FileOutputStream.(FileOutputStream.java:222)
at java.io.FileOutputStream.(FileOutputStream.java:169)
at com.whh.strictmode.MainActivity.testReadWrite(MainActivity.java:83)
at com.whh.strictmode.MainActivity.onClick(MainActivity.java:53)
- Activity泄漏
2019-05-06 19:52:48.467 23148-23148/com.whh.strictmode E/WindowManager: android.view.WindowLeaked: Activity com.whh.strictmode.leakactivity.TestLeakActivity has leaked window DecorView@86a60b[] that was originally added here
at android.view.ViewRootImpl.(ViewRootImpl.java:418)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:331)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:93)
at android.app.Dialog.show(Dialog.java:322)
at com.whh.strictmode.leakactivity.TestLeakActivity.onCreate(TestLeakActivity.java:38)
2019-05-06 19:53:18.916 23148-23148/com.whh.strictmode E/StrictMode: class com.whh.strictmode.leakactivity.TestLeakActivity; instances=2; limit=1
android.os.StrictMode$InstanceCountViolation: class com.whh.strictmode.leakactivity.TestLeakActivity; instances=2; limit=1
at android.os.StrictMode.setClassInstanceLimit(StrictMode.java:1)
- Bitmap泄漏
Caused by: java.lang.OutOfMemoryError: Failed to allocate a 51916812 byte allocation with 4188384 free bytes and 24MB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:620)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:660)
at com.whh.strictmode.MainActivity.testBitmap(MainActivity.java:105)
at com.whh.strictmode.MainActivity.onClick(MainActivity.java:53)
三、如何避免OOM
1、I/O流用完及时关闭
推荐用try-with-resource语句--更优雅的关闭资源。
(JDK7及其之后的资源关闭方式)
try-with-resource并不是JVM虚拟机的新增功能，只是JDK实现了一个语法糖，实际实现原理还是try-catch-finally。
以前用try-catch-finally使用I/O流代码如下：
//try-catch外部定义I/O流
InputStream is = null;
OutputStream os = null;
try {
//try括号中I/O赋值
is = new FileInputStream(src);
os = new FileOutputStream(dst);
//...进行一些I/O操作
} catch (Exception e) {
} finally {
//finally中关闭I/O流
try {
if (is != null) {
is.close();
}
} catch (IOException e) {
}
try {
if (os != null) {
os.close();
}
} catch (IOException e) {
}
}
这种方式代码繁杂不说，有时候还容易忘记关闭输入输出流。而换成try-with-resource语句后，代码如下：
try (InputStream is = new FileInputStream(src);
OutputStream os = new FileOutputStream(dst)) {
//...进行一些I/O操作
} catch (Exception e) {
}
这种方式优雅简洁，而且不用担心忘记关闭输入输出流，因为try()括号中的I/O流会自动关闭
2、确保Activity实例引用不会被其他类长期持有
- 1、Activity中非静态内部类会持有Activity实例引用：Java的非静态内部类在构造的时候，会将外部类的引用传递进来，并且作为内部类的一个属性，因此，内部类会隐式地持有其外部类的引用。
所以，定义内部类时一定要注意看当前类是否持有Activity引用或者当前类是否是Activity。 - 2、将Activity当成Context传入其他类，会导致其他类持有Activity实例引用。
所以，一般情况下要用Context时最好用ApplicationContext，必须用ActivityContext时要注意Context引用回收。 - 3、将Activity中View注入其他类时，由于View持有ActivityContext引用，也会导致其他类持有Activity实例引用。
所以，将View注入其他类时，确保该View引用在用完后被回收。 - 4、Activity实现了某些接口，作为观察者被注册到其他类时，也会导致Activity引用被其他类持有。
所以，Activity中注册监听与反注册最好成对出现。 - 5、Activity生命周期内注册广播时，要在对应生命周期中取消广播注册。
3、图片加载
- 1、尽量使用图片加载框架(ImageLoader/Picasso/Glide...)加载图片，因为使用图片加载框架不需要去考虑图片Bitmap回收问题等，而且0图片加载框架基本都支持扩展(比如图片转换等)跟自定义(比如图片缓存大小、位置等)。
- 2、不用框架加载图片时，请用LruCache管理图片缓存列表。
- 3、如果以上两种方式都不用，一定要确保Bitmap使用完后合理回收。
- 4、加载图片时，一定要考虑到图片尺寸压缩/颜色质量，根据需要保证图片缓存的合理大小跟颜色质量。由于Android加载图片基本使用BitmapFactory加载，这里简单介绍下两种图片利用技巧：
//1、利用inSampleSize进行图片采样
BitmapFactory.Options options = new BitmapFactory.Options();
//inSampleSize越大，压缩率越大。inSampleSize==1时表示原图
//当确定图片大小跟需要的图片大小时，可以计算出采样率进行图片压缩
options.inSampleSize = 2;
Bitmap bmp = BitmapFactory.decodeFile(path, options);
//2、利用inSampleSize进行图片采样
BitmapFactory.Options options = new BitmapFactory.Options();
//当对图片透明度需求不高时，可以将图片颜色质量设为RGB_565
options.inPreferredConfig = Config.RGB_565;
Bitmap bmp = BitmapFactory.decodeFile(path, options);
//3、利用inBitmap复用旧的Bitmap的内存,而不用重新分配以及销毁旧Bitmap，进而改善运行效率
BitmapFactory.Options options = new BitmapFactory.Options();
//mOldBitmap是一个旧的Bitmap，必须是mutable的(支持修改).新的bmp直接复用该mOldBitmap的内存空间
//使用条件是mOldBitmap占用的空间必须大于等于新bmp占用的内存空间
options.inBitmap = mOldBitmap;
Bitmap bmp = BitmapFactory.decodeFile(path, options);