Andriod 内存泄露问题的整理

这篇文章是我很久以前写的，感觉写得太官方了，于是我下定决心想要改得更加贴近大家的思维，于是我将把改版后的推荐给大家。
1、内存泄漏：

当出现对Activity、View或drawable等类的对象长期持有无用的引用，就会造成被引用的对象无法在GC时回收，而是长期占用堆空间，此时就会发生内存泄漏。
简单来说，就是保留下来却永远不再使用的对象引用。

2、内存溢出：

如果应用程序在消耗光了所有的可用堆空间(16M到48M），那么再试图在堆上分配新对象时就会引起OOM(Out Of Memory Error)异常，此时应用程序就会崩溃退出。

3、两者的区别：

简单的说，就是内存溢出是占用内存太大，超过了其可以承受的范围；
内存泄漏是回收不及时甚至是没有被回收，而在推空间中产生的许多无用的引用。
于是过多的内存泄漏就会导致内存溢出，从而迫使程序崩溃退出。

4、四种不同类型的引用：

引用名称	Strong Reference(强引用)	Soft Reference (软引用)	Weak Reference (弱引用)	Phantom Reference (虚引用)
引用特点	通常我们编写的代码都是Strong Ref，于此对应的是强可达性，只有去掉强可达，对象才被回收。	对应软可达性，只要有足够的内存，就一直保持对象，直到发现内存吃紧且没有Strong Ref时才回收对象。一般可用来实现缓存，	比Soft Ref更弱，当发现不存在Strong Ref时，立刻回收对象而不必等到内存吃紧的时候	根本不会在内存中保持任何对象，你只能使用Phantom Ref本身。一般用于在进入finalize()方法后进行特殊的清理过程
引用方式		通过java.lang.ref. SoftReference类实现	通过java.lang.ref.WeakReference和java.util.WeakHashMap类实现	通过java.lang.ref.PhantomReference实现

 

 

5、持有Context引用造成的泄漏。

在Android应用程序中，很多操作都用到了Context对象，但是大多数都是用来加载和访问资源的。
这就是为什么所有的显示控件都需要一个Context对象作为构造方法的参数。
在Android应用程序中通常可以使用两种Context对象：Activity和Application。
当类或方法需要Context对象的时候常见的作法是使用第一个作为Context参数。
但这就意味着View对象对整个activity保持引用，因此也就保持对activity内的所有东西的引用，
也就是整个View结构和它所有的资源都无法被及时的回收，而且对activity的长期引用是比较隐蔽的。

当屏幕方向改变时，Android系统默认作法是会销毁当前的Activity，然后创建一个新的Activity，这个新的Activity会显示刚才的状态。
在这样做的过程中，Android系统会重新加载UI用到的资源。
现在假设的应用程序中有一个比较大的bitmap类型的图片，每次旋转时都重新加载图片所用的时间较多。
为了提高屏幕旋转时Activity的创建速度，最简单的方法是用静态变量的方法。

这样的代码执行起来是快速的，但同时是错误的：这样写会一直保持着对Activity的引用。
当一个Drawable对象附属于一个View时，这个View就相当于drawable对象的一个回调（引用）。
在上面的代码片段中，就意味着drawable和TextView存在着引用的关系，
而TextView自己持有了对Activity（Context对象）的引用，这个Activity又引用了相当多的东西。

有两种简单的方法可以避免由引用context对象造成的内存泄露。
首先第一个方法是避免context对象超出它的作用范围。
上面的例子展示了静态引用的情况，但是在类的内部，隐式的引用外部的类同样的危险。
第二种方法是，使用Application对象。这个context对象会随着应用程序的存在而存在，而不依赖于activity的生命周期。
如果你打算对context对象保持一个长期的引用，请记住这个application对象。
通过调用Context.getApplicationContext() 或者 Activity.getApplication().方法，你可以很容易的得到这个对象。
如果在activity中使用静态的类时如果需要引用activity,应该采用WeakReference弱引用来引用Activity。

总结一下避免Context泄漏应该注意的问题： 尽量使用Application这种Context类型， 

注意对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字，Context里如果有线程，一定要在onDestroy()里及时停掉。 

为了防止内存泄露，我们应该注意以下几点：
（1）不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的.
（2）对于生命周期长的对象，可以使用application context。
（3）避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。

6、线程之间通过Handler通信引起的内存泄漏

Android中线程之间进行通信时最常用的作法是通过接收消息的目标线程所持有Handler对象来创建Message对象，然后再向目标线程发送该Message。
在目标线程中Handler在执行handleMessage()时会根据相应Message来执行相应不同功能。
另外一种作法是通过Handler对象向目标线程直接发送Runnable对象来执行该Runnable对象中不同的功能代码。
在通过Handler进行通信时如果不注意，也很有可能引起内存泄漏。

在sendMessage完成之后显示的将msg成员变量置为null，并且在退出整个应用程序之前，将handler置为null。

7、将变量的作用域设置为最小

最小化作用域意味着对垃圾收集器更快的可见。让我们举一个例子。
我们有一个变量定义在方法级,当方法执行完毕后,也就是说,控制跳出方法后,则该变 量将不会被引用。
这也就意味着它已经可以被垃圾回收。但是如果该变量是类级的,这时垃圾回收器就需要等待直到对该类的所有的引用都被移除后才能进行垃圾回收。
优化属性的作用域是必须的。同样这也是封装原则。最小化作用域降低了通过包访问变量并减少了耦合。

8、构造Adapter时，没有使用缓存的convertView。

初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象 缓存起来。
当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。
这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。

由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，
即浪费时间，也造 成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。

9、Bitmap的回收和置空。
Bitmap 对象不在使用时调用 recycle()释放内存，有时我们会手工的操作 Bitmap 对象,
如果一个Bitmap 对象比较占内存, Bitmap对象在不使用时，我们应该先调用recycle()释放内存，然后才它设置为null。
虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。
但是我它应该还是能大大的加速Bitmap的主要内存的释放。

10、资源对象没关闭造成的内存泄露。

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

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

11、各种注册没取消。

这种情况造成的内存泄露这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些Android程序可能引用我们的Anroid程序的对象（比如注册机制）。
即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收
。比如 假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，
则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。
对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。
如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。
虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。

12、集合容器对象没清理造成的内存泄露。

我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，
并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。

13、static关键字的滥用。

当类的成员变量声明成static后，它是属于类的而不是属于对象的，
如果我们将很大的资源对象（Bitmap，context等）声明成static，那么这些资源不会随着对象的回收而回收，
会一直存在，所以在使用static关键字定义成员变量的时候要慎重。

14、WebView对象没有销毁。

当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。

15、GridView的滥用。

GridView和ListView的实现方式不太一样。GridView的View不是即时创建的，而是全部保存在内存中的。
比如一个GridView有100项，虽然我们只能看到10项，但是其实整个100项都是在内存中的。
所以在应用程序退出之前，要讲gridView和adapter全部置为null。

 

 

 

PS:希望大家能喜欢我的总结，虽然有点啰嗦，但是这些都是我在做项目的时候赤裸裸的教训啊，很高兴和大家分享。