安卓内存泄露
2016-01-27 23:23
99 查看
因为Android使用Java作为开发语言,很多人在使用会不注意内存的问题。
于是有时遇到程序运行时不断消耗内存,最终导致OutOfMemery,程序异常退出,这就是内存泄露导致的。
我们现在就来总结一下可能导致内存泄露的情况:
通常,在Activity中,我们可以调用startManagingCursor或直接使用,%20java.lang.String,%20java.lang.String[],%20java.lang.String%29]managedQuery让Activity自动管理Cursor对象。
但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程),那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
虽然表面看起来,Cursor.close()已经被调用,但若出现异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
Cursor c = queryCursor();
try {
int a = c.getInt(1);
......
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
}
而我们经常可以看到类似于如下的代码:
registerReceiver(new BroadcastReceiver() {
...
}, filter); ...
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露
先让我们看一下以下代码:
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
于是有时遇到程序运行时不断消耗内存,最终导致OutOfMemery,程序异常退出,这就是内存泄露导致的。
我们现在就来总结一下可能导致内存泄露的情况:
查询数据库而没有关闭Cursor
在Android中,Cursor是很常用的一个对象,但在写代码是,经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程),那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
虽然表面看起来,Cursor.close()已经被调用,但若出现异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
Cursor c = queryCursor();
try {
int a = c.getInt(1);
......
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
}
调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存是相当大的。而我们经常可以看到类似于如下的代码:
registerReceiver(new BroadcastReceiver() {
...
}, filter); ...
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
未关闭InputStream/OutputStream
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露Bitmap使用后未调用recycle()
根据SDK的描述,调用recycle并不是必须的。但在实际使用时,Bitmap占用的内存是很大的,所以当我们不再使用时,尽量调用recycle()以释放资源。Context泄露
这是一个很隐晦的内存泄露的情况。先让我们看一下以下代码:
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
相关文章推荐
- NYOJ-13-Fibonacci数
- poj1679 The Unique MST
- centos 下vmware 下添加硬盘到root
- Day3~Day7(2016/1/23~2016/1/27)
- javaweb学习总结(四十一)——Apache的DBUtils框架学习
- 蚂蚁啃大象之zookeeper学习过程
- 玩转MySQL之Linux下的简单操作(服务启动与关闭、启动与关闭、查看版本)
- hdu1754 区间查询+点修改 分块模板
- Android自定义属性格式
- oracle with as介绍
- 以Attention Model为例谈谈两种研究创新模式
- spring mvc 的jpa JpaRepository数据层 访问方式汇总
- spring AOP
- 基于Theano的深度学习(Deep Learning)框架Keras学习随笔-06-激活函数
- 初次体验完美easy ui 1.4.4
- R语言 dplyr传递参数
- poj_2945 Find the Clones (Trie树 内存分配)
- 18.逻辑运算符
- Swipe JS – 移动WEB页面内容触摸滑动类库
- Java程序在命令行下编译运行打Jar包