通过一个实例简单介绍下内存泄漏（或OOM）的分析方法（之一）
背景简介
平台化的广告牌中有个简单的广告播放，由2页组成。
- Fragment1
- Fragment2
首页的功能是刷脸，通过算法识别人脸的账号（如果有），或者其他特征信息（如性别，年龄等），识别结束后，跳转到第二页进行一些定向的广告推荐。在第二页停留一段时间后再跳转回首页，周而复始。
功能简单，但是遇到的一个问题就是，在一次次的轮转中，内存不断变大，很快导致OOM，应用程序崩溃。
定性分析
第一步是简单确认下发生了内存泄漏：
关于Java，Native，Stack、Code各代表什么含义，请自行搜索“Java内存模型”，推荐直接看《Java虚拟机（第二版）》
很明显表明内存泄漏了。
详细分析
这里需要使用Studio自带的Android
Device Monitor和MAT（Memory
Analyzer Tool），这只是其中一个组合，其他很多工具可以用，只介绍一个，抛砖引玉。
在Android Studio中打开菜单/Tools/Android/Android
之后用到的2个重要按钮是Dump
Hprof是个heap
dump文件，包含当时内存里面的信息镜像。
什么是GC请自行搜索“Java垃圾回收”，同样推荐直接看《Java虚拟机（第二版）》。
之后就是要选取一些合适的dump时机，好做对比分析。比如这个而例子中，我们预期在页面2跳回页面1时，占用的内存应该和每次跳回页面1相同或至少相似，否则就应有泄露。
所以我们选区了2个时机，第一个是1-2-1（第一次跳回首页时），手动触发一次GC，然后dump
hprof。
第二个时机时再跳一次第二页，然后返回首页，即1-2-1-2-1。同样手动GC一下，然后dump。
手动GC的目的在于清理一下本可以回收而当时可能还没回收的内存，排除干扰项。
有了2次的hprof镜像，下一步是用MAT（Eclipse
Memory Analyzer Tool）分析。
其实也可以直接用Studio分析，用的不熟，就不写了。
这里注意下，生成的hprof格式可能和MAT不兼容，因此需要用hprof-conv 转换一下，这个工具开发环境自带，比如在目录：C:\User\xxx\AppData\Local\Android\Sdk\platform-tools\（就是和adb同一目录）。
打开后执行
hprof-conv.exe <转换前.hprof> <转换后.hprof>
同时打开两个hprof后，点击上图中红框的按钮，给两个hprof都生成Histogram（图表）。
然后在下面的导航栏中把他们加入比较筐：
两个都加完这样，
点击上图右上角的感叹号，
解释：
Objects：实例个数
Shallow Heap
：所占内存大小
Retained Heap
：释放后能回收多少内存
上图，看最主要的，第一个byte[]，两次dump差了17M。其他区别不大。重点看这个。
通过右键菜单可以查看GC
Root路径，这个不知道什么意思的话同样自行搜索“Java
GC”或者推荐直接看《Java虚拟机（第二版）》。可以根据实际情况过滤掉弱引用和软引用，排除一些干扰。
最终，找到怀疑点，然后通过引用链排查到具体的类，再去代码确认。
如下图，
Retained Heap: Retained heap of X is the sum of shallow sizes of all objects in the retained set of X, i.e. memory kept alive by X.
意为回收该对象能释放多少内存，左边一列Ref. Shallow Heap指对象所占内存，因此我们要找的是Ref. Shallow Heap很大，而Retained Heap很小的对象，再根据对象的内容和引用关系进一步确认是否是泄露点。
不一定所有符合Ref. Shallow Heap很大、Retained Heap很小的都是泄露，要根据具体情况确认。
在这个例子中，红框所圈出的对象byte[]指图片对象，最内层的bannerDefaultImage和imageViews可以初步确认为泄露点。当再去代码中确认细节时发现，imageViews为banner一第三方库中的List，持有视图列表的强引用，当banner本身不被释放时，所有被它持有的View都不能被回收。
