Android内存泄漏终极解决篇(下)
一、概述
在 Android内存泄漏终极解决篇(上)中我们介绍了如何检查一个App是否存在内存泄漏的问题,本篇将总结典型的内存泄漏的代码,并给出对应的解决方案。内存泄漏的主要问题可以分为以下几种类型:
- 静态变量引起的内存泄漏
- 非静态内部类引起的内存泄漏
- 资源未关闭引起的内存泄漏
二、静态变量引起的内存泄漏
在java中静态变量的生命周期是在类加载时开始,类卸载时结束。换句话说,在android中其生命周期是在进程启动时开始,进程死亡时结束。所以在程序的运行期间,如果进程没有被杀死,静态变量就会一直存在,不会被回收掉。如果静态变量强引用了某个Activity中变量,那么这个Activity就同样也不会被释放,即便是该Activity执行了onDestroy(不要将执行onDestroy和被回收划等号)。这类问题的解决方案为:1.寻找与该静态变量生命周期差不多的替代对象。2.若找不到,将强引用方式改成弱引用。比较典型的例子如下:
- 单例引起的Context内存泄漏
public class IMManager { private Context context; private static IMManager mInstance; public static IMManager getInstance(Context context) { if (mInstance == null) { synchronized (IMManager.class) { if (mInstance == null)
mInstance = new IMManager(context);
}
} return mInstance;
} private IMManager(Context context) { this.context = context;
}
}
当调用getInstance时,如果传入的context是Activity的context。只要这个单例没有被释放,这个Activity也不会被释放。
解决方案
传入Application的context,因为Application的context的生命周期比Activity长,可以理解为Application的context与单例的生命周期一样长,传入它是最合适的。
public class IMManager { private Context context; private static IMManager mInstance; public static IMManager getInstance(Context context) { if (mInstance == null) { synchronized (IMManager.class) { if (mInstance == null) //将传入的context转换成Application的context
mInstance = new IMManager(context.getApplicationContext());
}
} return mInstance;
} private IMManager(Context context) { this.context = context;
}
}
三、非静态内部类引起的内存泄漏
在java中,创建一个非静态的内部类实例,就会引用它的外围实例。如果这个非静态内部类实例做了一些耗时的操作,就会造成外围对象不会被回收,从而导致内存泄漏。这类问题的解决方案为:1.将内部类变成静态内部类 2.如果有强引用Activity中的属性,则将该属性的引用方式改为弱引用。3.在业务允许的情况下,当Activity执行onDestory时,结束这些耗时任务。
- 内部线程造成的内存泄漏
public class LeakAty extends Activity { @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
test();
} public void test() { //匿名内部类会引用其外围实例LeakAty.this,所以会导致内存泄漏
new Thread(new Runnable() { @Override
public void run() { while (true) { try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}
解决方案
将非静态匿名内部类修改为静态匿名内部类
public class LeakAty extends Activity { @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
test();
} //加上static,变成静态匿名内部类
public static void test() { new Thread(new Runnable() { @Override
public void run() { while (true) { try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}
- Handler引起的内存泄漏
public class LeakAty extends Activity { @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
fetchData();
} private Handler mHandler = new Handler() { public void handleMessage(android.os.Message msg) { switch (msg.what) { case 0: // 刷新数据
break; default: break;
}
};
}; private void fetchData() { //获取数据
mHandler.sendEmptyMessage(0);
}
}
mHandler 为匿名内部类实例,会引用外围对象LeakAty.this,如果该Handler在Activity退出时依然还有消息需要处理,那么这个Activity就不会被回收。
解决方案
public class LeakAty extends Activity { private TextView tvResult; private MyHandler handler; @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
tvResult = (TextView) findViewById(R.id.tvResult);
handler = new MyHandler(this);
fetchData();
} //第一步,将Handler改成静态内部类。
private static class MyHandler extends Handler { //第二步,将需要引用Activity的地方,改成弱引用。
private WeakReference<LeakAty> atyInstance; public MyHandler(LeakAty aty) { this.atyInstance = new WeakReference<LeakAty>(aty);
} @Override
public void handleMessage(Message msg) { super.handleMessage(msg);
LeakAty aty = atyInstance == null ? null : atyInstance.get(); //如果Activity被释放回收了,则不处理这些消息
if (aty == null||aty.isFinishing()) { return;
}
aty.tvResult.setText("fetch data success");
}
} private void fetchData() { // 获取数据
handler.sendEmptyMessage(0);
} @Override
protected void onDestroy() { //第三步,在Activity退出的时候移除回调
super.onDestroy();
handler.removeCallbacksAndMessages(null);
}
}
四、资源未关闭引起的内存泄漏
当使用了BraodcastReceiver、Cursor、Bitmap等资源时,当不需要使用时,需要及时释放掉,若没有释放,则会引起内存泄漏。
五、总结
综上所述,内存泄漏的主要情况为上面的三大类型,最终归结为一点,就是资源在不需要的时候没有被释放掉。所以在编码的过程中要注意这些细节,提高程序的性能。
文章来源:本文出自[HCY的博客] ,点击下方的阅读原文,可以关注和查看原文。转载请注明出处。
- 基于Metronic的Bootstrap开发框架经验总结(9)--实现Web页面内容的打印预览和保存操作
- 在Windows上安装Jekyll
- 如何解决ajax跨域问题
- 基础篇章:React Native之 Image 的讲解
- 防守式编程的艺术
- Git 简单命令,木有高深内容
- 基础篇章:React Native之 ScrollView 的讲解
- 常用 Git 命令清单
- 如何将配置spring文件指定名字,指定位置
- 基础篇章:React Native 之 TextInput 的讲解
- Linux下 标准错误输出重定向
- CentOs6.5 修改主机名
- 基础篇章:React Native 之 View 和 Text 的讲解
- CentOs7.3 修改主机名
- java教程
- Java快速入门
- Java 开发环境配置
- Java基本语法
- Java 对象和类
- Java 基本数据类型
- Java 变量类型
- Java 修饰符
- Java 运算符
- Java 循环结构
- Java 分支结构
- Java Number类
- Java Character类
- Java String类
- Java StringBuffer和StringBuilder类
- Java 数组
- Java 日期时间
- Java 正则表达式
- Java 方法
- Java 流(Stream)、文件(File)和IO
- Java 异常处理
- Java 继承
- Java 重写(Override)与重载(Overload)
- Java 多态
- Java 抽象类
- Java 封装
- Java 接口
- Java 包(package)
- Java 数据结构
- Java 集合框架
- Java 泛型
- Java 序列化
- Java 网络编程
- Java 发送邮件
- Java 多线程编程
- Java Applet基础
- Java 文档注释
- 老司机手把手教你编写自己的springboot starter
- 实战|如何消除又臭又长的if...else判断更优雅的编程?
- 硬核 | 使用spring cache让我的接口性能瞬间提升了100倍
- 11张图让你彻底明白jdk1.7 hashmap的死循环是如何产生的
- 基于qiankun落地部署微前端爬”坑“记
- springboot面试杀手锏-自动配置原理
- 树酱的前端知识体系构建(上)
- 这8种保证线程安全的技术你都知道吗?
- 并发编程中cas的这三大问题你知道吗?
- 再也不用怕面试问二叉树了
- Redux快速上手
- CSP
- Saltstack_使用指南07_远程执行-执行模块
- 学习从拥有一支好笔开始
- Saltstack_使用指南08_远程执行-返回程序