Android 分析OOM工具介绍

如图1所示, 步骤

** 1, 2, 3** 为打开Android Monitor并切换标签到monitor的过程

4, 5, 6 对应的图标和文字含义分别是

MAT 工具识别，并解析hprof文件,

有两种方式可以获得hprof文件

MAT并不能直接打开这两个hprof, 必须通过hprof-conv来转换一次

如图3所示，选中(过滤出MainActivity), 然后通过Objects可以看出它有8个实例

接着选中 com.example.wowo.MainActivity 然后右键选择

Merge shortest paths to GC Roots ->exclude week references

因为弱引用是会被回收的，所以排除掉更加容易发现OOM.

什么是OOM out-of-memory？

Android下的APP运行在VM中(Dalvik or ART), 一个APP需要的内存是有限，这个值在不同的平台, 不同的手机上是不同的，当APP需要的内存超过了内存上限，就会引起OOM.

下面给出一个最基本的Android APP显示HelloWorld的例子.

这时如果不停的旋转屏幕, 这时通过观察Android Monitor里的Free和allocated的memory会发现 allocated 的memory会不断增加，而Free的memory会不断减小

这时通过图1中步聚5 dump java heap, 然后filter到MainActivity, 会发现MainActivity有多个实例

接着再通过MAT来分析， 图4所示

发现有很多FinalizerReference， 应该是与GC有关，由于旋转屏幕会导致MainActivity销毁并重新创建实例，而JVM在创建MainActivity实例时还有free的memory, 所以并没有触发GC，即原来的MainActivity的实例并没有被回收，所以多次旋转后，在free memory还有的情况下就会保存多个MainActivity的实例造成内存泄露的假象。当free memory 不够时，这时会触发GC, 会回收之前销毁的MainActivity的实例。

所以在查看OOM问题时，当allocated内存不断增大时，应该人为先触发GC(点击图1的4)。

如果allocated的内存没有下降，说明当前并没有可回收的实例占据内存了。

而在该例中，如果点击了initiate GC后，allocated的内存立即减少了。

Android Monitor看到MainActivity也就只有一个实例了。

Android内存优化一:java垃圾回收机制

Android内存优化二:内存泄漏

Android内存优化三:内存泄漏检测与监控

Android内存优化四：OOM

Android内存优化五：Bitmap优化

Memory Profiler 是 Profiler 中的其中一个版块，Profiler 是 Android Studio 为我们提供的性能分析工具，使用 Profiler 能分析应用的 CPU、内存、网络以及电量的使用情况。

进入了 Memory Profiler 界面。

点击 Record 按钮后，Profiler 会为我们记录一段时间内的内存分配情况。

在内存分配面板中，通过拖动时间线来查看一段时间内的内存分配情况

通过搜索类或者报名的方式查看对象的使用情况

使用Memory Profiler 分析内存可以查看官网： 使用内存性能分析器查看应用的内存使用情况

对于内存泄漏问题，Memory Profiler 只能提供一个简单的分析，不能够确认具体发生问题的地方。

而 MAT 就可以帮我们做到这一点，它是一款功能强大的 Java 堆内存分析工具，可以用于查找内存泄漏以及查看内存消耗情况。

as 生成hprof文件无法被mat识别，需要进行转换

使用hprof-conv进行转换，hprof-conv位于sdk\platform-tools

ps：as导出hprof前最好先gc几次，可排除一些干扰

Histogram 可以列出内存中的对象，对象的个数以及大小； Dominator Tree 可以列出那个线程，以及线程下面的那些对象占用的空间； Top consumers 通过图形列出最大的object； Leak Suspects 通过MA自动分析泄漏的原因。

Shallow Heap就是对象本身占用内存的大小，不包含其引用的对象内存，实际分析中作用不大。常规对象（非数组）的ShallowSize由其成员变量的数量和类型决定。数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定。对象成员都是些引用，真正的内存都在堆上，看起来是一堆原生的byte[], char[], int[]，对象本身的内存都很小。

Retained Heap值的计算方式是将Retained Set（当该对象被回收时那些将被GC回收的对象集合）中的所有对象大小叠加。或者说，因为X被释放，导致其它所有被释放对象（包括被递归释放的）所占的heap大小。

Path To GC Roots ->exclude all phantim/weak/soft etc. references：查看这个对象的GC Root，不包含虚、弱引用、软引用，剩下的就是强引用。从GC上说，除了强引用外，其他的引用在JVM需要的情况下是都可以 被GC掉的，如果一个对象始终无法被GC，就是因为强引用的存在，从而导致在GC的过程中一直得不到回收，因此就内存泄漏了。

List objects ->with incoming references：查看这个对象持有的外部对象引用

List objects ->with outcoming references：查看这个对象被哪些外部对象引用

使用对象查询语言可以快速定位发生泄漏的Activity及Fragment

使用 MAT 来分析内存问题，效率比较低，为了能迅速发现内存泄漏，Square 公司基于 MAT 开源了 LeakCanary ，LeakCanary 是一个内存泄漏检测框架。

集成LeakCanary后，可以在桌面看到 LeakCanary 用于分析内存泄漏的应用。

当发生泄漏，会为我们生成一个泄漏信息概览页，可以看到泄漏引用链的详情。

LeakCanary 会解析 hprof 文件，并且找出导致 GC 无法回收实例的引用链，这也就是泄漏踪迹（Leak Trace）。

泄漏踪迹也叫最短强引用路径，这个路径是 GC Roots 到实例的路径。

LeakCanary 存在几个问题，不同用于线上监控功能

线上监控需要做的，就是解决以上几个问题。

各大厂都有开发线上监控方案，比如快手的 KOOM ，美团的 Probe ，字节的 Liko

快手自研OOM解决方案KOOM今日宣布开源

总结一下几点：

通过无性能损耗的 内存阈值监控 来触发镜像采集。将对象是否泄漏的判断延迟到了解析时

利用系统内核COW( Copy-on-write ，写时复制)机制，每次dump内存镜像前先暂停虚拟机，然后fork子进程来执行dump *** 作，父进程在fork成功后立刻恢复虚拟机运行，整个过程对于父进程来讲总耗时只有几毫秒，对用户完全没有影响。

内存泄漏无疑会严重影响用户体验，一些本应该废弃的资源和对象无法被释放，导致手机内存的浪费，app使用的卡顿，那么如何排查内存泄漏呢？

当然，首先我门有google的官方文档可以参考：

大部分博客的方法也来自于此。总的来说，就是使用android studio 的monitor memory功能监测app主进程占用的内存，触发GC *** 作，而后观察内存的占用情况，如果在使用的过程中内存不断增加，没有回落， 很有可能 发生了内存泄漏，这时候就需要导出内存分配的具体详情进行深入分析了。

但是事实上，通过观察这个内存曲线的曾场来或者是观察allocate tracker中的allocate data数值的增长来检测是否有内存泄漏问题，真的很玄，因为往往内存泄漏发生了，但是GC仍然可以通过回收其他对象的方式腾出空间，导致这个数据的变化基本看不出来，甚至是减小的，所以我觉得这种方式， 就像是让你用手掌去感知婴儿的体温，去检测确定这个婴儿有没有发烧一样，非常不靠谱不准确。

那么，重点来了，我的方法，简单直观，保准你一学就会！

先说一个terminal指令： 

这条指令是用来查询这个进程所占用的内存的具体详情的，通过这条指令可以看到当前app在手机中占用的具体的堆内存大小，view的数量， activity的数量 ，等等。如下图：

其中activity数目是非常关键的一个信息，可以帮助我们快速地检测出内存泄漏。我们可以反复地进入退出需要测试的目标activity，如果在反复进入退出之后，用terminal执行上面的语句查询当前的内存情况，如果发现activity数量一直在增长，那么内存泄露一定是发生了！

内存泄漏已经发生，如何定位原因呢？

如下图，在android studio中开始memory monitor，点击init GC，反复进入退出发生了内存泄漏的activity，这时候点击生成内存文件，这之后android studio会自动打开生成的.hprof文件。选中该文件转化成标准的hrof文件。

用MAT工具打开生成的.hprof文件，点击如下所示的图标，可以看到内存中的对象列表。

考虑到大内存的泄漏都是因为Activity被destroy之后却仍然被其他对象持有而造成的，因此首先解决棘手问题，直接搜索Activity，如下。发现有Activity的实例个数是3，跟实际不符，明显这个activity导致内存泄漏了，按照如图的方式找到它的引用，也就是导致内存泄漏的幕后凶手！

可以看到这个例子中的内存泄漏是由一个HandlerThread引发的，那么找到这个问题的位置，在合适的地方（如ondestroy）将这个handler thread释放即可。

如下图所示： 在android studio中打开生成的hprof文件，在右侧边栏会出现的Analyzer Tasks工具，点击执行图标，即可出现检测分析的结果，得到哪些activity被泄漏了，这些被泄漏的activity被谁引用了。

可以看到内存泄漏由AsyncHandler引起，需要在activity生命周期结束的时候进行释放。

方法2不用安装MAT工具，更加便捷哦～

 有问题可以留言，谢谢您的阅读～～

---