内存泄漏的危害:
内存泄漏会导致程序占用内存过高,当达到峰值时会导致OOM(内存溢出),从而导致程序奔溃。
对于Android应用来说,就是你的用户打开一个Activity,使用完之后关闭它,内存泄露;又打开,又关闭,又泄露;几次之后,程序占用内存超过系统限制,FC
内存泄漏的原因:
在java的垃圾回收机制里是通过检测对象是否被引用,当对象没有被引用或者有两个对象互相引用而没有被第三方引用,他们将被从内存中被回收。造成内存泄漏 的就是有的对象无法被回收。比如Handler的错误使用:
Handler导致内存泄漏的错误使用:
初学者的我一直是通过使用内部类的方式创建Handler,我们需要知道 非静态的内部类和匿名内部类都会隐式的持有其外部类的引用,只有静态的内部类才不会持有外部类的引用。所以当我只用内部类创建Handle的时候,Handler会隐式的持有一个外部类的对象(通常是一个Activity)的引用。而Handler通常会伴随着一个耗时的后台线程(比如获取网络图片)一起出现,这个后台线程在任务执行完毕之后,通过消息机制通知Handler,然后Handler把界面更新到界面里。然而,如果用户在网络请求的时候关闭了Activity,正常情况下,Activity不被使用了,他就有可能在GC检查时被回收掉,但又由于这是线程尚未执行完毕,导致该线程持有Handler的引用,而Handler又持有Activity的引用,就导致Activity无法被回收,也就导致了OOM(内存泄漏),直到网络请求结束。另外,如果你执行了Handler的postDelayed()方法,该方法会将你的Handler装入一个Message,并把这条Message推到MessageQueue中,那么在你设定的delay到达之前,会有一条MessageQueue -> Message -> Handler -> Activity的链,导致你的Activity被持有引用而无法被回收。
解决方案
使用Handler导致内存泄露的解决方法
方法一:通过程序逻辑来进行保护。
1.在关闭Activity的时候停掉你的后台线程。线程停掉了,就相当于切断了Handler和外部连接的线,Activity自然会在合适的时候被回收。
2.如果你的Handler是被delay的Message持有了引用,那么使用相应的Handler的removeCallbacks()方法,把消息对象从消息队列移除就行了。
方法二:将Handler声明为静态类。
PS:在Java 中,非静态的内部类和匿名内部类都会隐式地持有其外部类的引用,静态的内部类不会持有外部类的引用。
静态类不持有外部类的对象,所以你的Activity可以随意被回收。由于Handler不再持有外部类对象的引用,导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用(WeakReference)。
代码如下:
static class MyHandler extends Handler
{
WeakReference<Activity> mWeakReference;
public MyHandler(Activity activity)
{
mWeakReference=new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg)
{
final Activity activity=mWeakReference.get();
if(activity!=null)
{
if (msg.what == 1)
{
noteBookAdapter.notifyDataSetChanged();
}
}
}
}
PS:什么是WeakReference?
WeakReference弱引用,与强引用(即我们常说的引用)相对,它的特点是,GC在回收时会忽略掉弱引用,即就算有弱引用指向某对象,但只要该对象没有被强引用指向(实际上多数时候还要求没有软引用,但此处软引用的概念可以忽略),该对象就会在被GC检查到时回收掉。对于上面的代码,用户在关闭Activity之后,就算后台线程还没结束,但由于仅有一条来自Handler的弱引用指向Activity,所以GC仍然会在检查的时候把Activity回收掉。这样,内存泄露的问题就不会出现了。
总结
android中的很多内存泄露都是由于在Activity中使用了非静态内部类导致的,我们在使用非静态内部类一定要格外注意,如果该静态内部类的实例对象的生命周期大于外部对象,那么就有可能导致内存泄露,推荐使用上面介绍的静态类和弱引用的方法解决这种问题。