Android应用程序内存泄漏的原因及规避方法

 引言
　　Android应用程序中内存使用的问题经常容易被忽视，在传统的编程语言中（例如C语言），回收内存的任务是由程序本身来完成的，程序可以显式分配和释放变量所占用的内存。Android［1］应用程序采用Java编程语言编写，而Java区别于其他语言的一个重要优点就是它通过垃圾收集器（Garbage Collection，GC） 自动管理内存的回收，Java程序员只需通过内存分配操作创建对象，而无须关心对象占用的空间是如何被收回的。因此很多程序员认为在Java中不必担心内存泄漏的问题，然而实际并非如此，Java中仍然存在着内存泄漏。Android应用程序运行在嵌入式系统中，而嵌入式系统中内存的总量非常有限，因此如何合理地规避“内存泄露”问题也就显得十分关键。
　　1　造成Android应用程序内存泄漏的原因
　　1.1　引用没释放造成的内存泄露
　　（1） 注册没有取消造成的内存泄漏
　　这种Android的内存泄露比纯Java的内存泄漏还要严重，因为其他一些Android程序可能引用系统的Android程序的对象（比如注册机制）。即使Android程序已经结束了，但是别的应用程序仍然还有对Android程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。
　　（2） 集合中对象没有关闭造成的内存泄漏
　　通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，慢慢地这个集合就会越来越大。如果这个集合是静态的话，那情况就会更严重。
　　1.2　资源对象没有关闭造成的内存泄漏
　　资源对象比如Cursor、File文件等往往都用了一些缓冲，在不使用的时候应该及时关闭它们，以便它们的缓冲及时回收内存。这些缓冲不仅存在于Java虚拟机内，还存在于Java虚拟机外，如果仅仅是把它的引用设置为空，而不关闭它们，那么往往会造成内存泄漏。
　　一些不良代码造成的内存压力原因如下：
　　◆ Bitmap没有调用recycle（ ）；
　　◆ 构造Adapter时，没有使用缓存的convertView；
　　◆ ThreadLocal使用不当；
　　◆ 其他。
　　2　内存泄漏的检测及定位
　　2.1　内存泄漏的检测
　　Android应用程序是基于虚拟机的，其内存管理都是由Dalvik［2］代为管理，GC的回收不是及时的。一个正常的应用程序在其运行稳定后其内存的占用量是基本稳定的，不应该是无限制的增长。同样，对任何一个类的对象的使用个数也有一个相对稳定的上限，不应该是持续增长的。当我们持续地观察某个应用程序运行过程中使用内存的大小和各实例的个数时，如果内存的大小持续增长，则说明系统存在内存泄漏的问题；如果特定类的实例对象个数随时间而增长，则说明这个类的实例可能存在泄漏情况。比如一个Activity被关掉之后，其内存的引用对象会在下次GC回收［3］的时候通过回收算法计算，如果这部分内存已经属于可回收的对象，那么这些垃圾对象会被一并回收，内存未泄漏趋势图如图1所示。
　　
　　图1　内存未泄漏趋势图
　　内存泄漏趋势图如图2所示。在重复打开关闭某个应用程序的时候，内存一直在向上爬升，也就是说每次关闭这个Activity的时候，有些应该释放的内存并没有被释放掉。由此我们可以确定这个应用程序存在着内存泄漏的问题。