Android内存泄漏的简单检查与分析方法

导语

内存泄漏问题大约是Android开发者最烦恼的问题之一了，项目中连续遇到几个内存泄漏问题，这里简单总结下检查分析内存泄漏的一些工具与方法。

一、什么是内存泄漏？

大家都知道，java是有垃圾回收机制的，这使得java程序员比C++程序员轻松了许多，存储申请了，不用心心念念要加一句释放，java虚拟机会派出一些回收线程兢兢业业不定时地回收那些不再被需要的内存空间（注意回收的不是对象本身，而是对象占据的内存空间）。

Q1：什么叫不再被需要的内存空间？

**答：**Java没有指针，全凭引用来和对象进行关联，通过引用来操作对象。如果一个对象没有与任何引用关联，那么这个对象也就不太可能被使用到了，回收器便是把这些“无任何引用的对象”作为目标，回收了它们占据的内存空间。

Q2：如何分辨为对象无引用？

**答：**2种方法

1. 引用计数法直接计数，简单高效，Python便是采用该方法。但是如果出现 两个对象相互引用，即使它们都无法被外界访问到，计数器不为0它们也始终不会被回收。为了解决该问题，java采用的是b方法。

2. 可达性分析法这个方法设置了一系列的“GC Roots”对象作为索引起点，如果一个对象 与起点对象之间均无可达路径，那么这个不可达的对象就会成为回收对象。这种方法处理 两个对象相互引用的问题，如果两个对象均没有外部引用，会被判断为不可达对象进而被回收（如下图）。

Q3：有了回收机制，放心大胆用不会有内存泄漏？

**答：**答案当然是No！

虽然垃圾回收器会帮我们干掉大部分无用的内存空间，但是对于还保持着引用，但逻辑上已经不会再用到的对象，垃圾回收器不会回收它们。这些对象积累在内存中，直到程序结束，就是我们所说的“内存泄漏”。

当然了，用户对单次的内存泄漏并没有什么感知，但当泄漏积累到内存都被消耗完，就会导致卡顿，崩溃。

内存泄漏的类型

常见的几种内存泄漏的情况

1. static变量引用Activity的Context写应用的时候有时候会用到单例，一般单例用static变量保存，生命周期是整个应用程序，而访问系统资源又需要Context，单例常常会需要保存Context如果传入Activity的Context会导致Activity间接的被static变量持有，无法回收导致内存泄漏。能用Application Context代替的，尽量用Application Context。
2. 匿名内部类匿名的内部类会持有外部类的引用，导致外部类不能被回收。比如，在Activity里面启线程，然后线程访问了Activity的一些成员变量，如果这个线程是长时间运行的（尤其是后台运行的），会导致这个Activity不被回收。类似的还有用Handler去post Runnable。Activity onStop/onDestroy的时候，能取消的延迟任务记得取消
3. 注册的回调/监听函数其实和匿名内部类差不多的原理，很多时候会注册一个回调函数到底层的Service，比如在做蓝牙扫描的时候，会注册监听，接收结果刷新Activity。或者其他类似的异步操作。这些内部的非静态的回调对象都会持有Activity的引用，导致Activity无法回收。Activity onStop/onDestroy的时候，取消注册/监听函数

二、发现内存泄漏

内存泄漏不可小视，在Android开发中，比如说一个Activity页面会占用许多资源开销，如果页面发生泄漏，关闭以后页面没有能被系统回收，对应用程序的伤害是很大的。

Q1：在Android开发测试中一般如何发现内存泄漏的发生呢？

答：

方法1：反复操作观察内存变化

内存泄漏常见变现为程序使用时间越长，内存占用越多。那我们通过反复操作应用，比如反复点开/关闭页面，观察内存变化状况是否一点点上涨，可以粗略地判断是否有内存泄漏

1.通过 DDMS 中的 heap 工具，可以查看应用内存的使用情况

2.Android studio也可以方便查看

方法2：通过代码检测Activity泄漏

基本思路：

1）debug版本可以起一个长期工作的线程LeakThread在后台专门做泄漏检测

2）向Application注册一个 页面生命周期 的监听：application.registerActivityLifecycleCallbacks

3）在监听类中对 onActivityDestoryed(Activity activity) 的事件回调做处理：

如果一个Activity走到onDestroy，那么这个Activity对象就是需要被回收的目标。

我们声明一个检测对象的弱引用ref = new WeakReference<Object>(activity)。

**PS：**与强引用和软引用相比，弱引用不会被回收器当做一个“有效”的引用，不会影响其引用对象的释放。实际上，垃圾回收器会毫不犹豫地回收只有弱引用的对象~

4）在 LeakThread中我们每隔一段时间检测一下ref.get() 是否为空，为空说明activity已被释放。不为空可以手动触一次发gc；如果超过一段时间，比如50s，页面对象还未被清理，我们可以推断内存泄漏的发生.

5）当内存泄漏发生时，提示给开发者，并自动dump出.prof文件。

因为代码检测不是这里的重点，代码就不贴了，只记思路。

方法3： Android性能调优利器StrictMode

三、分析内存泄漏（DDMS dump + MAT分析）

发现可能出现内存泄漏时，我们需要对.prof文件进行分析，方能快速定位到是哪个倒霉家伙导致了内存泄漏

3.1、如何dump出.prof文件？（可参照前文图片）

1. 打开DDMS ，Eclipse 可以切到DDMS视图，Android studio可以从Tools-Android-Android device monitor进入DDMS

2. 找到app的进程，在进程上方点击“update heap”按钮，可以先主动出发一次GC，待内存占用数据稍微稳定下来后 点击“Dump HProf File”，便可以导出.prof文件

3.2：导出.prof文件后如何分析？

Android studio可以直接打开prof文件。点开Analyzer Tasks的面板，点击右上角的开始按钮。

分析完成后，发生内存泄漏的页面对象会出现在Analysis Results面板-Leak Activityes的目录下。

如图，原来泄漏发生是LoadingRoomActivity的锅！

3.3 进一步分析泄漏的原因，你会需要一个好用的内存分析工具：MAT

在官网可以下载到它：

http://www.eclipse.org/mat/downloads.php

虽然MAT不会准确告诉你你的代码哪泄漏了，但是它会给你发现哪泄露的数据和线索。

3.3.1 打开.hprof前可能遇到的问题：

在MAT中打开.prof页面，你可能会遇到一点小挫折：

如上图，可能会弹出 ‘Parsing heap dump from xxx has encountered a proplem’ 的错误弹窗

这是因为文件版本和编辑器能支持的版本有冲突的原因。

解决方案如下：

Sdk安装目录下platform-tools里有一个hprof-conv工具可以解决该问题。在cmd控制台执行：

hprof-conv input.hprof output.hprof

重新再MAT打开output.hprof 就可以打开了~

值得一提的是，如果你dump出的文件太大的话，也有可能发现打不开的现象，这时候，打开安装MAT目录下的MemoryAnalyzer.ini 把-XmX改大些重启即可。但是也不要改得比你机器的可用内存还大，不能太贪心哈哈~

3.3.2 打开.phrof文件后的分析

通过MAT打开.phrof文件后，会弹出Overview 和 Leak Suspects 2个标签页。

Leak Suspects标签页可见如下图：

Leak Suspects视图展示了app内存占用的比例，浅色是空闲的内存，其他是内存占用的空间。每块内存对应的问题也都列在下面。点开每个Problem Suspect下的details，可以看到有哪些类的实例占用了内存和占用大小等信息~

此时我们已经有了怀疑的目标，为了更清晰地查看，我们可以回到Overview页面，打开Histogram页面：

在打开的Histogram标签页中，我们填入检测对象，在列出的匹配项中过滤掉对象的非强引用。

到这里我们就可以看到，是哪个坏蛋hold住了你的对象了。MAT能够给到的支持也就到这里，接下来，还是需要你根据这些线索到代码中寻找判别和修正了~``