常见的内存泄露有哪些 android
2015-01-09 · 知道合伙人数码行家
huanglenzhi
知道合伙人数码行家
向TA提问 私信TA
知道合伙人数码行家
采纳数:117538
获赞数:517184
长期从事计算机组装,维护,网络组建及管理。对计算机硬件、操作系统安装、典型网络设备具有详细认知。
向TA提问 私信TA
关注
展开全部
1.查询数据库而没有关闭Cursor
在Android中,Cursor是很常用的一个对象,但在写代码是,经常会有人忘记调用close, 或者因为代码逻辑问题枯游状况导致close未被调用。
通常,在Activity中,我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程),那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
1.try {
2. Cursor c = queryCursor();
3. int a = c.getInt(1);
4. ......
5. c.close();
6.} catch (Exception e) {
7.}
虽然表面看起来,Cursor.close()已经被调用,但若出现异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
01.Cursor c = queryCursor();
02.try {
03. int a = c.getInt(1);
04. ......
05.} catch (Exception e) {
06.} finally {
07. c.close(); //在finally中调用close(), 保证其一定会被调用
08.}
2.调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存慎缓是相当大的。
而我们经常可以看到类似于如下的代码:
01.registerReceiver(new BroadcastReceiver() {
02. ...
03.}, filter); ...
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
3.未关闭InputStream/OutputStream
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露
4.Bitmap使用后未调用recycle()
根据SDK的描述,调用recycle并不是必须的。但在实际使用时,Bitmap占用的内存是很大的,所以当我们不再使用时,尽量调用recycle()以释放资源。
5.Context泄露
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码:
01.private static Drawable sBackground;
02.
03.@Override
04.protected void onCreate(Bundle state) {
05. super.onCreate(state);
06.
07. TextView label = new TextView(this);
08. label.setText("Leaks are bad");
09.
10. if (sBackground == null) {
11. sBackground = getDrawable(R.drawable.large_bitmap);
12. }
13. label.setBackgroundDrawable(sBackground);
14.
15. setContentView(label);
16.}
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其宽败模也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
在Android中,Cursor是很常用的一个对象,但在写代码是,经常会有人忘记调用close, 或者因为代码逻辑问题枯游状况导致close未被调用。
通常,在Activity中,我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程),那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
1.try {
2. Cursor c = queryCursor();
3. int a = c.getInt(1);
4. ......
5. c.close();
6.} catch (Exception e) {
7.}
虽然表面看起来,Cursor.close()已经被调用,但若出现异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
01.Cursor c = queryCursor();
02.try {
03. int a = c.getInt(1);
04. ......
05.} catch (Exception e) {
06.} finally {
07. c.close(); //在finally中调用close(), 保证其一定会被调用
08.}
2.调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存慎缓是相当大的。
而我们经常可以看到类似于如下的代码:
01.registerReceiver(new BroadcastReceiver() {
02. ...
03.}, filter); ...
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
3.未关闭InputStream/OutputStream
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露
4.Bitmap使用后未调用recycle()
根据SDK的描述,调用recycle并不是必须的。但在实际使用时,Bitmap占用的内存是很大的,所以当我们不再使用时,尽量调用recycle()以释放资源。
5.Context泄露
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码:
01.private static Drawable sBackground;
02.
03.@Override
04.protected void onCreate(Bundle state) {
05. super.onCreate(state);
06.
07. TextView label = new TextView(this);
08. label.setText("Leaks are bad");
09.
10. if (sBackground == null) {
11. sBackground = getDrawable(R.drawable.large_bitmap);
12. }
13. label.setBackgroundDrawable(sBackground);
14.
15. setContentView(label);
16.}
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其宽败模也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
Storm代理
2023-07-25 广告
2023-07-25 广告
StormProxies是一家可靠的代理服务提供商,提供原生IP(住宅原生IP)和高匿名代理服务。以下是关于StormProxies的原生IP服务的一些信息:1. 住宅原生IP:StormProxies提供的住宅原生IP是指从真实的家庭或企...
点击进入详情页
本回答由Storm代理提供
展开全部
1. 查询数据库而没有关闭Cursor
在Android中,Cursor是很常用的一个对象,但在写代码是,经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。
通常,在Activity中,我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程)激蚂首,那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
虽然表面看起来,Cursor.close()已经被调用,但若出现物岩异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
Cursor c = queryCursor();
try {
int a = c.getInt(1);
......
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
}
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
2. 调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存是相当大的。
而我们经常可以看到类似于如下的代码:
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
registerReceiver(new BroadcastReceiver() {
...
}, filter); ...
3. 未明数关闭InputStream/OutputStream
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露
4. Bitmap使用后未调用recycle()
根据SDK的描述,调用recycle并不是必须的。但在实际使用时,Bitmap占用的内存是很大的,所以当我们不再使用时,尽量调用recycle()以释放资源。
5. Context泄露
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码:
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
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);
}
在Android中,Cursor是很常用的一个对象,但在写代码是,经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。
通常,在Activity中,我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
但需要注意的是,当Activity介绍后,Cursor将不再可用!
若操作Cursor的代码和UI不同步(如后台线程)激蚂首,那没需要先判断Activity是否已经结束,或者在调用OnDestroy前,先等待后台线程结束。
除此之外,以下也是比较常见的Cursor不会被关闭的情况:
虽然表面看起来,Cursor.close()已经被调用,但若出现物岩异常,将会跳过close(),从而导致内存泄露。
所以,我们的代码应该以如下的方式编写:
Cursor c = queryCursor();
try {
int a = c.getInt(1);
......
} catch (Exception e) {
} finally {
c.close(); //在finally中调用close(), 保证其一定会被调用
}
try {
Cursor c = queryCursor();
int a = c.getInt(1);
......
c.close();
} catch (Exception e) {
}
2. 调用registerReceiver后未调用unregisterReceiver().
在调用registerReceiver后,若未调用unregisterReceiver,其所占的内存是相当大的。
而我们经常可以看到类似于如下的代码:
这是个很严重的错误,因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
registerReceiver(new BroadcastReceiver() {
...
}, filter); ...
3. 未明数关闭InputStream/OutputStream
在使用文件或者访问网络资源时,使用了InputStream/OutputStream也会导致内存泄露
4. Bitmap使用后未调用recycle()
根据SDK的描述,调用recycle并不是必须的。但在实际使用时,Bitmap占用的内存是很大的,所以当我们不再使用时,尽量调用recycle()以释放资源。
5. Context泄露
这是一个很隐晦的内存泄露的情况。
先让我们看一下以下代码:
在这段代码中,我们使用了一个static的Drawable对象。
这通常发生在我们需要经常调用一个Drawable,而其加载又比较耗时,不希望每次加载Activity都去创建这个Drawable的情况。
此时,使用static无疑是最快的代码编写方式,但是其也非常的糟糕。
当一个Drawable被附加到View时,这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
这就意味着,这个Drawable拥有一个TextView的引用,而TextView又拥有一个Activity的引用。
这就会导致Activity在销毁后,内存不会被释放。
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);
}
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
存在内存盯凯滑泄露问题的Android的版本为5.0.2以及之前的所有孙袜安卓版本(包括4.4.4,4.3,2.3等),直到5.1.1版本凯腊的推出才修复了该漏洞。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询