Android内存泄漏（3）

Android内存泄漏产生的6大原因：

1.资源对象没关闭造成的内存泄漏

描述：

资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如 SQLiteCursor(在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

示例代码：

Cursor cursor = getContentResolver().query(uri...); if (cursor.moveToNext()) { ... ... }

修正示例代码：

Cursor cursor = null; try { cursor = getContentResolver().query(uri...); if (cursor != null &&cursor.moveToNext()) { ... ... } } finally { if (cursor != null) { try { cursor.close(); } catch (Exception e) { //ignore this } } }

2.构造Adapter时，没有使用缓存的convertView

描述：

以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：

public View getView(int position, ViewconvertView, ViewGroup parent)

来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出，如果我们不去使用 convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。 ListView回收list item的view对象的过程可以查看:

android.widget.AbsListView.java –> voidaddScrapView(View scrap) 方法。

示例代码：

public View getView(int position, ViewconvertView, ViewGroup parent) { View view = new Xxx(...); ... ... return view; }

修正示例代码：

public View getView(int position, ViewconvertView, ViewGroup parent) { View view = null; if (convertView != null) { view = convertView; populate(view, getItem(position)); ... } else { view = new Xxx(...); ... } return view; }

3.Bitmap对象不在使用时调用recycle()释放内存

描述：

有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：

/** •Free up the memory associated with thisbitmap's pixels, and mark the •bitmap as "dead", meaning itwill throw an exception if getPixels() or •setPixels() is called, and will drawnothing. This operation cannot be •reversed, so it should only be called ifyou are sure there are no •further uses for the bitmap. This is anadvanced call, and normally need •not be called, since the normal GCprocess will free up this memory when •there are no more references to thisbitmap. */

4.试着使用关于application的context来替代和activity相关的context

这是一个很隐晦的内存泄漏的情况。有一种简单的方法来避免context相关的内存泄漏。最显著地一个是避免context逃出他自己的范围之外。使用Application context。这个context的生存周期和你的应用的生存周期一样长，而不是取决于activity的生存周期。如果你想保持一个长期生存的对象，并且这个对象需要一个context,记得使用application对象。你可以通过调用 Context.getApplicationContext() or Activity.getApplication()来获得。更多的请看这篇文章如何避免

Android内存泄漏。

5.注册没取消造成的内存泄漏

一些Android程序可能引用我们的Anroid程序的对象(比如注册机制)。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。调用registerReceiver后未调用unregisterReceiver。

比如:假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。

虽然有些系统程序，它本身好像是可以自动取消注册的(当然不及时)，但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

6.集合中对象没清理造成的内存泄漏

我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。

关于内存泄漏的调试：

(1).内存监测工具 DDMS --> Heap
 无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用 Heap监测应用进程使用内存情况的步骤如下：
1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；
2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“MassStorage”；
3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；
4. 点击选中想要监测的进程，比如system_process进程；
5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；
6. 点击Heap视图中的“Cause GC”按钮；
7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。
 说明：
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；
b) 当内存使用信息第一次显示以后，无须再不断的点击“CauseGC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；
c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。
  如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做dataobject，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：
a) 不断的操作当前应用，同时注意观察data object的Total Size值；
b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；
c) 反之如果代码中存在没有释放对象引用的情况，则dataobject的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，
  直到到达一个上限后导致进程OOM被kill掉。

 

(2).内存分析工具 MAT(Memory Analyzer Tool) 

并不是所有的内存泄漏都可以用观察heap size的方法检测出来，因为有的程序只是泄漏了几个对象，而且泄漏的对象个数不会随着程序的运行而增加，这种内存泄漏不会直接导致OOM，但是无用对象无法回收，无疑是对内存的浪费，会影响到程序的性能，我们需要使用MAT工具才能发现这种比较隐蔽的内存泄漏。
使用MAT之前有2个概念是要掌握的：Shallowheap和Retained heap。Shallow heap表示对象本身所占内存大小，一个内存大小100bytes的对象Shallow heap就是100bytes。Retained heap表示通过回收这一个对象总共能回收的内存，比方说一个100bytes的对象还直接或者间接地持有了另外3个100bytes的对象引用，回收这个对象的时候如果另外3个对象没有其他引用也能被回收掉的时候，Retained heap就是400bytes。

MAT使用Dominator Tree这样一种来自图形理论的概念。

所谓Dominator，就是Flow Graph中从源节点出发到某个节点的的必经节点。那么根据这个概念我们可以从上图左侧的Flow Graph构造出右侧的Dominator Tree。这样一来很容易就看出每个节点的Retained heap了。Shallow heap和Retained heap在MAT中是非常有用的概念，用于内存泄漏的分析。

我们做一个Demo。在工程的MainActivity当中加入如下代码:

[java] view plaincopy

1. publicclassMainActivityextends Activity{  
2.     static Leaky leak=null;  
3.     classLeaky{  
4.         voiddoSomething(){  
5.             System.out.println("Wheee!!!");  
6.         }  
7.     }  
8.     @Override  
9.     publicvoidonCreate(Bundle savedInstanceState){  
10.         super.onCreate(savedInstanceState);  
11.         if(leak==null){  
12.             leak =new Leaky();  
13.         }  
14.         ...  

[java] view plain copy

 

1. publicclassMainActivityextends Activity{  
2.     static Leaky leak=null;  
3.     classLeaky{  
4.         voiddoSomething(){  
5.             System.out.println("Wheee!!!");  
6.         }  
7.     }  
8.     @Override  
9.     publicvoidonCreate(Bundle savedInstanceState){  
10.         super.onCreate(savedInstanceState);  
11.         if(leak==null){  
12.             leak =new Leaky();  
13.         }  
14.         ...  

上面这段代码，对Java熟悉的同学都应该了解非静态内部类对象默认持有外部类对象引用，而leak作为静态变量在非空判断下只产生了一个对象，因此当旋转屏幕时生成新的Activity的时候旧的Activity的引用依然被持有，如下图： 

通过观察旋转屏幕前后Log中GC的信息也能看出heap的data object分配往上涨了一点，并且在GC执行完heap的分配稳定之后并没有降下来，这就是内存泄漏的迹象。

我们通过MAT来进行分析。先下载MAT，可以作为Eclipse插件下载，也可以作为RCP应用下载，本质上没有区别。DDMS中选中应用对应的进程名，点击Dump HPROF file的按钮，等一小段时间生成HPROF文件，如果是Eclipse插件的话，Eclipse会为这个HPROF自动转化成标准的HPROF并自动打开MAT分析界面。如果是作为RCP应用的话，需要用sdk目录tools中的hprof-conv工具来进行转化，也就是上文提及的命令hprof-convorig.hprof converted.hprof，这种方式保存HPROF文件的位置选择更为自主，你也可以修改Eclipse的设置让Eclipse提示保存而不是自动打开，在Preferences -> Android -> DDMS中的HPROFAction由Open in Eclipse改为Save todisk。打开MAT，选择转化好的HPROF文件，可以看到Overview的界面如下图：

 

 

中间的饼状图就是根据我们上文所说的Retained heap的概念得到的内存中一些Retained Size最大的对象。点击饼状图能看到这些对象类型，但对内存泄漏的分析还远远不够。再看下方Action中有Dominator Tree和Histogram的选项，这一般来说是最有用的工具。还记得我们上文说过的DominatorTree的概念吗，这就是我们用来跟踪内存泄漏的方式。点开Dominator Tree，会看到以Retained heap排序的一系列对象，如下图：

Resources类型对象由于一般是系统用于加载资源的，所以Retained heap较大是个比较正常的情况。但我们注意到下面的Bitmap类型对象的Retained heap也很大，很有可能是由于内存泄漏造成的。所以我们右键点击这行，选择Path To GC Roots ->exclude weak references，可以看到下图的情形：

 

Bitmap最终被leak引用到，这应该是一种不正常的现象，内存泄漏很可能就在这里了。MAT不会告诉哪里是内存泄漏，需要你自行分析，由于这是Demo，是我们特意造成的内存泄漏，因此比较容易就能看出来，真实的应用场景可能需要你仔细的进行分析。

根据我们上文介绍的Dominator的概念，leak对象是该Bitmap对象的Dominator，应该出现在Dominator Tree视图里面，但实际上却没有。这是由于MAT并没有对weak references做区别对待，这也是我们选择exclude weakreferences的原因。如果我们Path To GC Roots ->with all references，我们可以看到下图的情形：

 

 

可以看到还有另外一个对象在引用着这个Bitmap对象，了解weak references的同学应该知道GC是如何处理weak references，因此在内存泄漏分析的时候我们可以把weak references排除掉。

 

有些同学可能希望根据某种类型的对象个数来分析内存泄漏。我们在Overview视图中选择Actions -> Histogram，可以看到类似下图的情形：

 

上图展示了内存中各种类型的对象个数和Shallow heap，我们看到byte[]占用Shallow heap最多，那是因为Honeycomb之后Bitmap Pixel Data的内存分配在Dalvik heap中。右键选中byte[]数组，选择List Objects -> with incomingreferences，可以看到byte[]具体的对象列表：

我们发现第二个byte[]的Retained heap较大，内存泄漏的可能性较大，因此右键选中这行，Path To GC Roots -> exclude weak references，同样可以看到上文所提到的情况，我们的Bitmap对象被leak所引用到，这里存在着内存泄漏。

在Histogram视图中第一行<Regex>中输入com.example.android.hcgallery，过滤出我们自己应用中的类型，如下图：

我们发现本应该只有一个MainActivity现在却有两个，显然不正常。右键选择List Objects-> with incoming references，可以看到这两个具体的MainActivity对象。右键选中Retained heap较大的MainActivity，Path To GC Roots -> exclude weak references，再一次可疑对象又指向了leak对象。

以上是MAT一些基本的用法，如果你感兴趣，可以自行深入的去了解MAT的其他功能