Android内存泄漏的故障排除和定位的一部分

像标题一样，经过一段时间，我正在从事的项目遇到了挑战，Umeng经常报告OOM. 没有捷径，只有一个字: 检查.

本文针对使用eclipse或Android Studiodump hprof文件并且可以使用MAT来简单分析内存使用情况的Android开发人员. 那些没有使用过MAT的人，请自己使用百度的基本用法. 本文是关于实战的. OOM无处可去的情况.

我以前做过内存分析，当时我仍在使用eclipse. 我使用的工具无非就是转储当前内存情况，然后进行MAT分析. 但是，对于初学者，请使用最短的GC路径. 现在此方法不生效. 示例转储文件的屏幕截图如下:

LeakSuspects如图所示: MAT帮助您猜测的内存泄漏位置是位图. 单击以红色圈出的图标进入内存排名列表. 您可以使用shallowHeap进行排名. 您可以看到最常用的是byte []，即位图. 费用很高，而且仍然不可能找到内存泄漏，因此需要进一步调查.

实际上，这一次您需要查看的不仅是ShallowHeap的大小，还包括对象以查看其中有多少个对象. 此时，您可以使用一种技术. 根据内存泄漏的特征，反复关闭猜测的内存泄漏的活动. 这时，您可以在AndroidStudio的监视器中看到内存将在关闭过程中累积并增加. 关闭“活动”并回收所有内存，这表明应用程序存在内存泄漏.

因此您可以进行比较. 打开一次Activity，然后多次打开Activity，两次转储hprof，比较两个hprof文件的Objects的大小，可以猜出发生泄漏的位置，本文使用多次打开的情况下，转储前请记住CauseCabr. ~~但是我们今天要谈论的仍然落后.

以下操作是可以快速定位内存泄漏和内存泄漏位置的最简单的操作，如下图所示，单击OQL（外部链接介绍: ），这是两个最常用的语句:

从android.app.Activity实例中选择*

从android.support.v4.app.Fragment实例中选择*

查询当前现有的Activity和Fragment，这很重要~~~您可以在下图中看到内存泄漏Activity

在内存泄漏条目上右键单击“ GCRoot的路径”，将显示以下条目. 您可以通过单击查看所需的信息. 它可能是由静态变量保存的，也可能是一些. 观察者并没有被删除，好运！

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-297971-1.html