当前位置: 首页 > 编程笔记 >

避免 Android中Context引起的内存泄露

赵灼光
2023-03-14
本文向大家介绍避免 Android中Context引起的内存泄露,包括了避免 Android中Context引起的内存泄露的使用技巧和注意事项,需要的朋友参考一下

Context是我们在编写Android程序经常使用到的对象,意思为上下文对象。 常用的有Activity的Context还是有Application的Context。Activity用来展示活动界面,包含了很多的视图,而视图又含有图片,文字等资源。在Android中内存泄露很容易出现,而持有很多对象内存占用的Activity更加容易出现内存泄露,开发者需要特别注意这个问题。

本文讲介绍Android中Context,更具体的说是Activity内存泄露的情况,以及如何避免Activity内存泄露,加速应用性能。

Drawable引起的内存泄露

Drawable引起内存泄露这个问题是比较隐晦,难以察觉的。在阅读了Romain Guy的Avoiding memory leaks,结合grepcode查看源码才明白了。

在Android系统中,当我们进行了屏幕旋转,默认情况下,会销毁掉当前的Activity,并创建一个新的Activity并保持之前的状态。在这个过程中,Android系统会重新加载程序的UI视图和资源。假设我们有一个程序用到了一个很大的Bitmap图像,我们不想每次屏幕旋转时都重新加载这个Bitmap对象,最简单的办法就是将这个Bitmap对象使用static修饰。

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);
}

但是上面的方法在屏幕旋转时有可能引起内存泄露,无论是咋一看还是仔细看这段代码,都很难发现哪里引起了内存泄露。

当一个Drawable绑定到了View上,实际上这个View对象就会成为这个Drawable的一个callback成员变量,上面的例子中静态的sBackground持有TextView对象lable的引用,而lable只有Activity的引用,而Activity会持有其他更多对象的引用。sBackground生命周期要长于Activity。当屏幕旋转时,Activity无法被销毁,这样就产生了内存泄露问题。

2.3.7及以下版本Drawable的setCallback方法的实现

public final void setCallback(Callback cb) {
 mCallback = cb;
}

好在从4.0.1开始,引入了弱引用处理这个问题,弱引用在GC回收时,不会阻止GC回收其指向的对象,避免了内存泄露问题。

public final void setCallback(Callback cb) {
 mCallback = new WeakReference<Callback>(cb);
}

单例引起的内存泄露

单例是我们比较简单常用的一种设计模式,然而如果单例使用不当也会导致内存泄露。 比如这样一个例子,我们使用饿汉式初始化单例,AppSettings我们需要持有一个Context作为成员变量,如果我们按照下面的实现其实是有问题。

public class AppSettings { 
 private Context mAppContext;
 private static AppSettings sInstance = new AppSettings();

 //some other codes
 public static AppSettings getInstance() {
  return sInstance;
 }
 
 public final void setup(Context context) {
  mAppContext = context;
 }
}

sInstance作为静态对象,其生命周期要长于普通的对象,其中也包含Activity,当我们进行屏幕旋转,默认情况下,系统会销毁当前Activity,然后当前的Activity被一个单例持有,导致垃圾回收器无法进行回收,进而产生了内存泄露。

解决的方法就是不持有Activity的引用,而是持有Application的Context引用。代码如下修改

public final void setup(Context context) {
 mAppContext = context.getApplicationContext(); 
}

访问这里了解更多关于单例模式的问题

条条方法返回Context

通常我们想要获取Context对象,主要有以下四种方法

  1. View.getContext,返回当前View对象的Context对象,通常是当前正在展示的Activity对象。
  2. Activity.getApplicationContext,获取当前Activity所在的(应用)进程的Context对象,通常我们使用Context对象时,要优先考虑这个全局的进程Context。
  3. ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context,可以使用这个方法,这个方法在实际开发中使用并不多,也不建议使用。
  4. Activity.this 返回当前的Activity实例,如果是UI控件需要使用Activity作为Context对象,但是默认的Toast实际上使用ApplicationContext也可以。

其他内存泄露问题

Android中糟糕的AsyncTask

Android中Handler引起的内存泄露

OnSharedPreferenceChangeListener详解及出现不触发解决办法

避免内存泄露须谨记

  1. 不要让生命周期长于Activity的对象持有到Activity的引用
  2. 尽量使用Application的Context而不是Activity的Context
  3. 尽量不要在Activity中使用非静态内部类,因为非静态内部类会隐式持有外部类实例的引用(具体可以查看细话Java:”失效”的private修饰符了解)。如果使用静态内部类,将外部实例引用作为弱引用持有。
  4. 垃圾回收不能解决内存泄露,了解Android中垃圾回收机制

参考文章

Avoiding memory leaks
Difference between getContext() , getApplicationContext() , getBaseContext() and “this”
Android – what's the difference between the various methods to get a Context?

以上就是对Android Context 内存泄漏的资料整理,后续继续添加相关资料,谢谢大家的支持!

 类似资料:
  • 我是android开发的新手,我刚刚从以下链接读到了Romain Guy的“避免android内存泄漏” http://www.curious-creature.org/2008/12/18/avoid-memory-leaks-on-android/ 然后我在我的android模拟器上用他著名的代码片段做了一个小测试 此代码应该在更改方向时泄漏第一个活动上下文。因此,我在emulator中运行了

  • 问题内容: 所以我有这个C ++程序,它是通过Java程序中的JNI调用的,代码如下: 在倒数第二行中,从不释放而是返回,是否会导致最终的内存泄漏?反正有解决这个问题的方法吗? 还有可能不是返回字符串而是返回布尔值(由LogonUser函数返回),而不是jstring,而是添加了要在方法中传递的“ errormessage”引用,并更新了它?我的Java程序能否看到“ errormessage”的

  • 问题内容: 有效的Java说: 内存泄漏的第三个常见来源是侦听器和其他回调。如果在客户端注册回调但未显式注销的情况下实现API,除非您采取某些措施,否则它们会累积。确保回调被及时垃圾回收的最佳方法是仅存储对其的弱引用,例如,通过仅将它们作为键存储在WeakHashMap中。 我是Java的初学者。有人可以教我如何在回调中创建弱引用,并告诉我它们如何解决内存泄漏问题吗?谢谢。 问题答案: 阅读这篇文

  • 我在SupportMapFragmet上阅读了这篇文档,它说: 从GoogleMap获得的任何对象都与视图相关联。重要的是不要持有超出视图生命周期的对象(例如标记)。否则会导致内存泄漏,因为视图无法释放。 我对此有点困惑,因为没有办法修改,除非您持有它们的引用,就像这里的许多问题所说的那样(像这样和这样)......所以我错过了什么吗? 我目前正在使用哈希映射将我的标记与其他对象关联起来,我看不出

  • 在MAT工具中分析了堆转储后。泄漏嫌疑人说:“”加载的一个“java.util.TaskQueue”实例占用680,207,896(82.39%)字节。该实例由org.apache.tomcat.util.threads.taskThread@0xC1B52018 ajp-bio-8009-exec-243引用,由“java.net.urlClassLoader@0xCE67A9B8”加载。内存积

  • 我读了很多关于如何避免Android内存泄漏的文章,但我仍然不太确定我是否做对了。 我的应用程序由一个活动组成 问题1:这够了吗? 让我困惑的是,你可以在网上找到一个经典的“不去”的例子(http://www.curious-creature.org/2008/12/18/avoid-memory-leaks-on-android/): 我认为,一旦创建完成, 检索上下文,将其传递给手动创建的查看