Android 内存泄露
最近在开发学习项目中使用LeakCanary进行内存泄露的检测，发现了一些之前没有注意到的地方。为了寻找解决方法，在网上查了不少资料，现总结一下。常见的内存泄露包括一下几种情况。
1. 监听器
当使用系统服务如SensorManager，LocationManager的时候，一般通过cotext.getSystemService获取，它们负责执行某些后台任务，或者为硬件访问提供接口。如果context 对象想要在服务内部的事件发生时被通知，那就需要把自己注册到服务的监听器中。然而，这会让服务持有activity的引用，如果在activity销毁的时候忘记了取消注册，那就会导致activity 内存泄露了。
【解决方法】：
在activity的 onDestroy() 方法中取消注册。
【示例】：
修改前：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}
修改后：
SensorManager sensorManager = null;
Sensor sensor = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}
@Override
protected void onDestroy() {
super.onDestroy();
sensorManager.unregisterListener(this,sensor);
}
2. 静态变量引用context
泄露activity最简单的方法就是在activity 类中定义一个static变量，并且让其指向运行中的activity实例。如果在activity的生命周期结束之前，没有清除这个引用，那他就会产生内存泄露。这是因为activity的类对象是静态的，一旦加载，就会在app运行时一直常驻内存，因此如果类对象不卸载，其静态成员就不会被垃圾回收器回收。也就是说，一个生命周期长的持有一个生命周期短的activity context，导致activity一直被引用无法回收。
这种情况最常见的使用情况就是：
- 单例持有activity的context
- 自定义的某些工具类中的静态方法需要一个context的参数
【解决方法】：
- 生命周期长的不要引用生命周期短的activity context，可以考虑使用
application context替换activity context - 静态变量应该避免引用
activity context
3. 非静态内部类
因为非静态内部类可以增加封装性和可读性，所以使用的地方特别多。但是不幸的是非静态内部类能够访问外部类这一优势就是通过持有外部类的强引用来实现的，而这正是导致内存泄露的原因。
考虑一下这样的使用场景，我们在定义的非静态内部类中做耗时的操作，即内部类的对象的生存时间比外部类的生成时间长。那么当外部类应该被回收时(比如屏幕的旋转)，GC发现它还被其内部类的对象引用，所以就不会将其回收。假如该外部类中含有大量的资源(比如图片)那么就很容易发生OOM.
【解決方法】：
- 声明成静态内部类，因为静态内部类不持有外部类的对象，所以外部类可以被回收
- 如果要访问外部类组件，可以在静态内部类中声明一个WeakReference来引用外部类的实例，可以参照下面匿名内部类的示例
4. 匿名内部类
使用匿名内部类的情况有很多，比如AsyncTask，Handeler，Thread，Timer Tasks。匿名内部类和非静态内部类一样，会持有外部类的强引用，所以很容易引起内存泄露。
比如：定义一个匿名Handler用来处理一个耗时操作的后续操作，如一个后台线程在执行完从网络拉取图片后，通过消息机制通知Handler，而后Handler把图片更新到界面上。然而如果在网络请求的过程中关闭Activity，正常情况下，该Activity不被使用，那它就有可能在GC检查时被回收掉，但是由于这时网络请求线程还没有执行完成，而该线程持有Handler引用，这个Handler又持有Activity的引用，这就导致该Activity无法被回收，从而导致内存泄露。
另外，如果你执行了Handler的postDelayed()方法，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，那么在你设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致你的Activity被持有引用而无法被回收。
【解决方法】：
同非静态内部类的解决方法
【示例】：
下面以Handler的使用方法来演示如何解决匿名内部类内存泄露的问题。
修改前：
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}
修改后：
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}
参考文献
网友评论