Android内存泄露案例分析

一款优秀的Android应用，不只要有完善的功能，也要有良好的体验，而性能是影响体验的一个重要因素。内存泄露是Android开发中常见的性能问题。这篇文章，经过咱们曾经遇到的一个真实的案例，来说述一个内存泄露问题，从发现到分析定位，再到最终解决的全过程。

这里把整个过程分为四个阶段：

• 第一阶段，现场勘查，分析Bug现象，找出有用线索；
• 第二阶段，初步推断，根据以前的线索，推断可能致使Bug的缘由，而且进一步验证推断是否正确；
• 第三阶段，探究根源，找出致使Bug的真正缘由；
• 第四阶段，解决方案，研究如何解决问题。

现场勘查

以前咱们开发过一款应用，交给QA测试以后，发现有时候界面会卡顿，动画不流畅。通过他反复测试找到了规律，当连续屡次打开应用时，问题就会出现。咱们根据这个方式重现Bug时，又发现Logcat中频繁输出GC日志（如图一所示）。 

 

图一

这里先简单介绍一下GC，也就是垃圾回收机制，Android经过提供垃圾回收机制来管理内存，当内存不足时会触发垃圾回收，回收没用的对象，释放内存。咱们经过两张图（图2、三）来看一下垃圾回收的过程。

这里GC Roots表示垃圾回收器对象，每一个节点表示内存中的对象，箭头表示对象之间的引用关系，能被GC Roots直接或者间接引用到的对象ABCD，表示正在使用的对象，不能被引用到的EFG是无用对象，垃圾回收时就会被回收掉。当系统触发一次垃圾回收时，对象EFG就会被回收。

以上就是垃圾回收的过程。在现场勘查这一阶段，咱们找到两条很是有用的线索：

• 线索一：连续屡次打开应用以后，界面卡顿，动画不流畅；
• 线索二：操做过程当中，LogCat频繁输出GC日志。

初步推断

如今到第二阶段，根据前一阶段找到的线索，当连续屡次打开应用，界面卡顿，同时Logcat不断输出GC日志，初步推测咱们的应用中存在内存泄漏。首先咱们先看一下什么是内存泄露呢？咱们经过两张张图来演示，如图四和五。

  

这张图跟刚才演示GC过程的图很像，这时候再触发GC时，EG会被回收，F对于应用来讲虽然无用了，却没法被回收，最后致使了内存泄漏。

所以，极可能每次打开应用时，都会产生像F这样的对象致使，内存占用愈来愈高，系统频繁触发GC。

验证推断

接下来就要去验证，这里咱们利用DDMS工具。

DDMS是虚拟机调试监控服务，它能帮助咱们测试设备截屏，设置虚拟地理坐标，针对特定的进程查看它的堆信息等等。

如何利用它来验证咱们的推断呢？首先要load出应用的内存快照，这里分为4步，第一步，选中咱们要查看的应用，第二步点击Update Heap按钮，这时候DDMS就会通知应用准备收集内存信息，第三步选择Heap标签，heap标签页可以展现出内存的全部信息。第四步点击Cause GC，这时候就会把内存快照load出来。这样DDMS就把内存快照load出来了。具体操做如图六。 

 

图六

Load出内存信息以后，就来分析咱们应用中是否存在内存泄漏，分析内存泄漏的关键的数据之一，就是Total Size。

重复打开应用时，若是不存在内存泄漏的话，Total Size只会在必定范围内波动。若是咱们的推断正确，连续打开应用，Total Size会持续增长。接着咱们就来测试分析，连续打开应用，如图七。

 

图七

这里展现了第一二三，以及第十次打开时Total size的截图，Total Size一直在增大，其中1-byte array增大最为明显，1-byte array表示的是byte[]，或者boolean[]类型的数组。因此咱们可以得出结论：打开应用时，确实存在内存泄漏。

探究根源

确认了问题，接下来就要探究问题的根源。每个应用运行过程当中，都会持有上万甚至百万个对象，咱们就要分析这些对象在内存中的状态，看哪些对象对应用来讲已经没用了，可是还在占用着内存。

这个过程咱们用到了MAT。MAT是一款功能丰富，运行速度很是快的堆内存分析工具。它可以快速的分析堆中的全部对象，计算出每一个对象占有的内存大小。它的功能很是强大，分析完内存以后，它还可以帮找出可能致使内存泄漏的对象，列出占用内存比较大的对象，它提供查询java容器对象使用率的等功能，这些功能对于咱们分析应用的内存都很是有帮助。

它既有独立的安装程序，也有针对eclipse的插件，咱们根据本身的需求下载相应的程序。咱们使用的时候也很是简单，能够利用刚才介绍的DDMS工具，把内存快照导出到.hprof文件中，而后MAT直接打开这个hprof文件就好了。独立安装程序的下载地址： http://www.eclipse.org/mat/。

根据前面的测试，咱们通过几回操做就致使1-byte array的Total Size从20M增大到70M，平均每次增长5M左右，这个size是比较大的，所以推断有内存占用比较大的对象致使的内存泄露。结合MAT的Dominator Tree功能，咱们来着手分析，Dominator Tree能列出内存中全部对象，以及他们占用内存的大小。

 

图八

这里是Dominator Tree的一张截图，先介绍两个名词第一个Shallow Heap，表示对象自己的内存大小，包括对象的头以及成员变量等，第二个Retained Heap表示：一个对象自己以及它持有的全部对象的内存总和，也就是GC时，回收一个对象所释放的全部内存空间。从这张图中能够看到，Retained Heap最大的时Resources对象，可是Resource是System Class对象，也就是系统管理的对象，也不会是引发咱们内存泄漏的缘由，咱们不用去分析它。

第二大的就是Bitmap对象。从前面的介绍咱们已经知道，若是一个对象能被GC Roots直接或者间接引用，它就不能被回收，那咱们就来看一下Bitmap到GC Roots的引用路径，看Bitmap时被哪一个对象持有的。选中Bitmap，右键选择，Path To GC Roots，再选择execlude weak references，由于弱引用是不能阻止垃圾回收的，因此咱们直接排除弱引用。

下面图九就是Bitmap到GC Roots的引用路径。其中LoadPicThread对象前面有个小红点，这个小红点就表示这个对象是被GC Roots直接持有的。

 

图九

因此整个引用路径就是GC Roots引用着Thread，Thread引用着咱们的Activity，而Activity中包含了Bitmap对象。

这时候当前界面已经退出了，可是Thread 仍持有着Activity 的引用，致使Activity 和它引用的内存例如Bitmap不能被回收。这时候问题的真相基本浮出水面了。

为了进一步确认咱们的结果，咱们从另外一个角度进行验证，看内存中是否多个被Thread持有的，不能回收的Activity的对象？借助MAT的Histogram功能，它能列出内存中的全部类，以及每一个类的实例个数。

 

图十

如图十，MAT提供了正则搜索的功能，能够根据类名搜索，咱们这里搜索获得的结果是11个Activity对象，因此进一步验证成功。就是由于咱们建立的那个Thread持有着Acitivy的对象，致使关闭以后Activiy不能回收。

代码分析

根据以上的分析，咱们找到了引起内存泄露的代码。

[java]  view plain copy

1. class TestActivity{  
2.     protected void onCreate(Bundle savedInstanceState) {  
3.         LoadPicThread loadPicThread = new LoadPicThread();  
4.         loadPicThread.start();  
5.     }  
6.     private class LoadPicThread extends Thread {      
7.         @Override  
8.         public void run() {  
9.             super.run();  
10.             while(true) {  
11.                 …load data…  
12.                 try {  
13.                     Thread.sleep(1000*60*5);  
14.                 } catch (InterruptedException e) {  
15.                     e.printStackTrace();  
16.                 }  
17.             }  
18.         }  
19.     }  
20. }  

LoadPicThread是TestActivity的一个内部类，它隐式的持有着TestActivity的实例，LoadPicThread会每5分钟去服务器请求一次数据，这个Thread一直都不会结束，并且每次打开界面时都会建立一个这样的Thread。因此咱们这里致使内存泄漏的根本缘由就是长生命周期对象（Thread）持有短生命周期对象（Activity）的引用，致使Activiy退出以后，不能被回收。

解决方案

最后到解决问题阶段，找到问题以后怎么解决呢？咱们想到了两种解决方案。

第一，将Thread从Activity移除，能够放到后台服务中，这样Activity与Thread之间就不会相互依赖，若是Thread要作的事情跟Activity业务逻辑不是很紧密，例如在一些数据缓存的操做，这时候就能够用这种方案。

第二，当Activity结束时，中止Thead，让Thread与Activity的生命周期保持一致，通常能够在onDestory方法中，给Thread发送一个结束信号。

总结

以上是就是咱们从发现到解决内存泄漏的整个过程。其实在Android开发过程当中，不少错误的代码，引起内存泄露。例如，不当的使用Context；构造Adapter时，没有使用缓存的convertView等等。

最后总结一下：

第一，做为Android开发人员，只有深入理解Android经常使用组件的工做机制，以及应用中各个对象的生命周期，才能尽可能避免写出致使内存泄露的代码；

第二，当程序出现问题时，首先要找到触发它的场景，就像这个案例中，咱们根据QA提供的重现方式，通过反复测试和观察，最终定位到问题。而在咱们平常开发中，可能遇到更加复杂的问题，在面对复杂的状况下，只有找到触发问题的关键场景，咱们才能快速的定位问题，并加以解决。

第三，强大的工具是帮助咱们分析和定位问题的利器，例如前面用到的DDMS和MAT工具，他们可以让咱们可以深刻到应用的内部进行探索和研究，从而快速的分析到问题的根源。因此开发人员应该学会运用这些强大的工具，来分析解决各类疑难问题。

DDMS抓取的hprof文件不能直接在MAT中打开, 因此须要转换一下:

hprof-conv在D:\Soft\TVMaosoft\adt-bundle-windows-x86_64-20140702\sdk\platform-tools 下

命令

C:\Users\gaoshuai>hprof-conv  C:\Users\gaoshuai\Desktop\com.kookong.tv.hprof a.

hprof