阅读 2621

[译]内存泄露的八种花样

这是很久以前发布在简书平台上的一篇有关内存泄漏的译文。
这篇文章提及的8种内存泄漏的场景,现在来看依旧很经典。为了避免内存泄漏,开发过程中需要谨慎谨慎再谨慎。同时,保持良好的开发习惯也至关重要。

具有垃圾回收特性的语言(如Java)的优点在于,它使得开发者不需要显式的对内存的分配和回收进行管理。这个特性降低引发段错误引发应用崩溃的风险,避免没有释放的内存长期占据堆内存,从而编写出更加安全的代码。可惜这并不是银弹,在Java里还是有其他方式导致内存泄露,这意味着我们的Android App依然存在浪费不必要的内存,最终由于内存不足(OOM)导致Crash的可能性。原文链接

传统的内存泄露方式是:在所有相关的引用离开作用域后,没有释放之前申请的内存空间。逻辑上的内存泄露,是没有释放不再需要的对象的引用的结果。如果一个对象的强引用依然存在,垃圾回收器就不能把这个对象从内存里回收。在Android开发里,Context上下文的泄露就通常就属于这种泄露。因为Context对象如Activity通常引用了一大堆内存,如View的层级和其他资源。如果泄露了Context对象,通常意味着它所引用的所有对象也跟着泄露。Android应用运行在内存受限的设备上,如果有多处地方泄露的话,应用很容易耗光所有的可用内存。

如果对象没有明确的生命周期,那么检测逻辑上的内存泄露更像是一个主观的问题。幸运的是,Activity拥有明确定义的生命周期,因此我们能明确的知道一个Activity实例是否已经泄露。Activity的onDestroy()方法在Activity的生命周期的最后被调用,意味着它在编程意图上或Android系统调度上需要进行一些内存的回收。如果这个方法调用完毕后,Activity实例依旧能从堆的根通过强引用链被访问到,垃圾回收器也就无法将它标记为可从内存回收——尽管从原本的意图是将它从内存中删除。因此,我们可以将一个在生命周期结束后依旧存在的Activity对象标记为被泄露。

Activity是一个很重的对象,因此你不应该选择干预Android框架对它们的调度处理。然而,依旧有方法不经意的导致Activity泄露。在Android上,所有导致内存泄露的陷阱都离不开两个基础场景。第一个内存泄露的类别是进程级别的全局共享静态变量,它们的存在状态不取决于应用的状态,同时还持有指向Activity的引用链。另一个内存泄露类别是因为线程的运行时间比Activity的生命周期还长,忽视了清除一个指向Activity的强引用链。下面我们来看下几种可能会遇到的内存泄露的情况。

1. 静态Activity

最容易泄露Activity的方式莫过于定义一个类,类的内部通过静态变量的方式持有Activity,然后在运行中,将Activity实例赋值给这个变量。如果这个静态变量的引用在Activity的生命周期结束前没有置空的话,Activity实例就泄露了。因为被静态变量持有的对象,它将会被保持在内存中,在App的运行过程中一直存在。如果有一个静态变量持有了Activity的引用,那么这个Activity就无法被垃圾回收器回收。完整代码

void setStaticActivity() {
  activity = this;
}

View saButton = findViewById(R.id.sa_button);
saButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticActivity();
    nextActivity();
  }
});复制代码

Activity内存泄露
Activity内存泄露

2. 静态View

另一个类似的场景:如果一个Activity需要经常被访问,那么我们可能会选择使用单例模式,保持一个实例在内存里,以便它可以被快速的使用到。然而,若前所述,干预Activity的生命周期并将它保持在内存里是一件很危险也没有必要的事情,应该尽可能的避免这么做。

但如果我们有一个View对象,需要花费很大的代价去创建它,而它在Activity的不同的生命周期里保持不变,那么我们能不能把在这个实例存在静态变量里,再讲他附加到View的层级结构里去?让我们来看下。完整代码当我们的Activity被回收的时候,大部分的内存可以被回收。

void setStaticView() {
  view = findViewById(R.id.sv_button);
}

View svButton = findViewById(R.id.sv_button);
svButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
    setStaticView();
    nextActivity();
  }
});复制代码

静态View内存泄露
静态View内存泄露

等下!看到没。你知道一个attach了的view内部会持有一个指向Context的引用,换句话说,那就是我们的Activity。通过吧一个View设为静态变量,我们创建了一个能长期持有Activity的引用链,导致Activity被泄露了。千万不要把attach的view设为静态变量,如果实在必须这么做,至少保证在Activity的生命周期结束前把它从View的层级结构里detach)掉。

3. 内部类

除了这,让我们在我们的Activity类里在定义一个类,也就是内部类。为了提高代码的可读性和健壮性,封装程序逻辑,我们可能会这么做。如果我们创建了一个这样的内部类的实例,并通过静态变量持有了它,会怎样呢?你应该能猜到这又是一个内存泄露的点。

void createInnerClass() {
    class InnerClass {
    }
    inner = new InnerClass();
}

View icButton = findViewById(R.id.ic_button);
icButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createInnerClass();
        nextActivity();
    }
});复制代码

内部类导致的内存泄露
内部类导致的内存泄露

不幸的是,由于内部类可以直接访问到它的外部类的变量,这个特性意味着内部类会隐式的持有一个对它的外部类的引用,这间接导致了我们不小心又泄露了Activity。

4. 匿名类

同样的,匿名类也持有一个指向它申明的地方所在的类的引用。如果你在Activity内定义和实例化一个AsyncTask匿名类,那也可能发生内存泄露

void startAsyncTask() {
    new AsyncTask<Void, Void, Void>() {
        @Override protected Void doInBackground(Void... params) {
            while(true);
        }
    }.execute();
}

super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
View aicButton = findViewById(R.id.at_button);
aicButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        startAsyncTask();
        nextActivity();
    }
});复制代码

AsyncTask的内存泄露
AsyncTask的内存泄露

5. Handler

同样的原则也适用于后台任务:定义一个匿名的Runnable,然后将它加入Handler的处理队列里。这个Runnable对象会隐含的持有一个指向它定义的时候所在的Activity的引用,然后它会作为一个消息对象加入到Handler的消息队列里去。在Activity生命周期结束之后,只要这个消息还没被Activity处理,那就有一条引用链指向我们的Activity对象,使得Activity对象无法被回收,进而泄露。

void createHandler() {
    new Handler() {
        @Override public void handleMessage(Message message) {
            super.handleMessage(message);
        }
    }.postDelayed(new Runnable() {
        @Override public void run() {
            while(true);
        }
    }, Long.MAX_VALUE >> 1);
}


View hButton = findViewById(R.id.h_button);
hButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        createHandler();
        nextActivity();
    }
});复制代码

Handler导致的内存泄露
Handler导致的内存泄露

6. 线程

类似的问题我们可以在线程定时任务(TimerTask)里发现。

void spawnThread() {
    new Thread() {
        @Override public void run() {
            while(true);
        }
    }.start();
}

View tButton = findViewById(R.id.t_button);
tButton.setOnClickListener(new View.OnClickListener() {
  @Override public void onClick(View v) {
      spawnThread();
      nextActivity();
  }
});复制代码

线程使用不当导致内存泄露
线程使用不当导致内存泄露

7. 定时任务

只要它们是通过匿名类的方式定义和实例化的,即便是工作在另外的线程,依旧会在Activity被destroy之后,存在一条指向Activity的引用链,导致Activity泄露。

void scheduleTimer() {
    new Timer().schedule(new TimerTask() {
        @Override
        public void run() {
            while(true);
        }
    }, Long.MAX_VALUE >> 1);
}

View ttButton = findViewById(R.id.tt_button);
ttButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        scheduleTimer();
        nextActivity();
    }
});复制代码

TimerTask导致的内存泄露
TimerTask导致的内存泄露

8. 系统服务

最后,还有一些系统服务可以通过上下文Context对象上的getSystemService)方法获取到。这些服务运行在他们各自的进程里,协助应用执行某种类型的的后台任务,或者和设备的硬件进行交互。如果Context对象需要系统服务内的某个事件发生的时候通知到这个Context,那么它需要把自身作为一个监听器注册给系统服务。系统服务也由此持有了一个对Activity对象的应用。如果我们在Activity的生命周期结束的时候忘了去反注册这个监听器,就会发生泄露。

void registerListener() {
       SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
       Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
       sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}

View smButton = findViewById(R.id.sm_button);
smButton.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View v) {
        registerListener();
        nextActivity();
    }
});复制代码

传感器管理器导致的内存泄露
传感器管理器导致的内存泄露


我们已经见识到了一系列内存泄露,也知道他们是多么容易不小心就泄露一堆的内存。记住,尽管最坏的可能性也就是导致你的应用因为内存不足而崩溃,也不一定会一直这样。但是它会吃掉你应用内的一大部分不必要的内存。在这个时候,你的应用将会缺少内存来生成别的对象,进而导致垃圾回收器频繁的执行,以便释放内存给新的对象使用。垃圾回收是一个非常昂贵(耗时)的操作,还会产生用户可感知的卡顿。因此,需要对可能存在的内存泄露保持警惕,并时常对内存泄露进行测试。