避免长期持有了一个Context的引用造成内存泄露
2015-04-29 10:36
197 查看
Android上 ,Context可以用于很多操作,但是大部分时候是用来加载以及使用资源。这就是为什么所有的widgets在他们的构造函数中接受一个Context参数。在一般的android应用中,你通常有两种Context:分别是Activity和Application。通常的,当我们的类和方法需要使用到context时,我们传递的是Activity这个context。
[java]
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
这意味着views拥有一个对整个activity的引用,也就是引用了你的activity所拥有的一切;通常的,这指的是完整的视图层级结构以及所有它的资源。因此,如果你泄露了一个Context(“ 泄漏 ”意味着你保持着它的一个引用,从而使它不能被垃圾回收机制回收),就意味着你泄漏了很多的内存。如果你不小心, 泄漏一 个activity的所有资源真的非常容易。
当 屏幕的方向发生改变的时候,系统默认将会销毁当前的activity并且创建一个新的activity同时保持着原有的状态。在做这个的时候,Android会从资源重新加载应用的UI。现在,想象一下你写了一个应用,这个应用有一张很大的bitmap。你不想再每一次旋转的时候重新加载它。最简单的方法让bitmap持续作用而不随每一个方向而重新加载
,就是把它放进一个静态域:
[java]
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);
}
这段代码很快,但是错误也很严重:它泄漏了第一个activity,这个在第一次屏幕改变时被创建的activity。当一个Drawable被关联到一个view上,这个view就相当于在drawable上设置的一个回调。在上面的代码片段中,这表示drawable有一个TextView的引用,而这个TextView又拥有一个activity的引用(Context),activity依次引用了几乎所有的东西(取决于你的代码)。
这个例子展示了一个最简单的Context
泄漏的情况,你可以在Home screen 的源码中看到我们是如何解决这个问题的( 查找unbindDrawables() 方法) ,这就是当activity 被销毁的时候将drawables 的回调设为null 。有趣的是,你可能创造出一系列context泄漏的情况有很多,这非常糟糕。他们会是你很快内存溢出。
有两种简单的方法来避免context 相关的内存泄漏。最显著地一个是避免context 逃出他自己的范围之外。上面的例子就展示了使用静态引用的情况,而内部类和他们对外部类的的隐式引用也是同样危险的。第二种方法是使用Application context 。这个context 的生存周期和你的应用的生存周期一样长,而不是取决于activity 的生存周期。如果你想保持一个长期生存的对象,并且这个对象需要一个context ,记得使用application 对象。你可以通过调用Context.getApplicationContext()
or Activity.getApplication() 来获得。
总而言之,想要避免context 相关的内存泄漏 ,记住以下几点:
1、不要对activity 的context 长期引用( 一个activity 的引用的生存周期应该和activity 的生命周期相同)
2、试着使用关于application的 context 来替代和activity相关的context
3、如果一个acitivity 的非静态内部类的生命周期不受控制,那么避免使用它;使用一个静态的内部类并且对 其中的activity 使用一个弱引用。解决这个问题的方法是使用一个静态的内部类,并且对它的外部类有一 WeakReference,就像在ViewRoot中内部类W所做的就是这么个例子。
a037
4、垃圾回收器不能处理内存泄漏的保障
[java]
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
这意味着views拥有一个对整个activity的引用,也就是引用了你的activity所拥有的一切;通常的,这指的是完整的视图层级结构以及所有它的资源。因此,如果你泄露了一个Context(“ 泄漏 ”意味着你保持着它的一个引用,从而使它不能被垃圾回收机制回收),就意味着你泄漏了很多的内存。如果你不小心, 泄漏一 个activity的所有资源真的非常容易。
当 屏幕的方向发生改变的时候,系统默认将会销毁当前的activity并且创建一个新的activity同时保持着原有的状态。在做这个的时候,Android会从资源重新加载应用的UI。现在,想象一下你写了一个应用,这个应用有一张很大的bitmap。你不想再每一次旋转的时候重新加载它。最简单的方法让bitmap持续作用而不随每一个方向而重新加载
,就是把它放进一个静态域:
[java]
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);
}
这段代码很快,但是错误也很严重:它泄漏了第一个activity,这个在第一次屏幕改变时被创建的activity。当一个Drawable被关联到一个view上,这个view就相当于在drawable上设置的一个回调。在上面的代码片段中,这表示drawable有一个TextView的引用,而这个TextView又拥有一个activity的引用(Context),activity依次引用了几乎所有的东西(取决于你的代码)。
这个例子展示了一个最简单的Context
泄漏的情况,你可以在Home screen 的源码中看到我们是如何解决这个问题的( 查找unbindDrawables() 方法) ,这就是当activity 被销毁的时候将drawables 的回调设为null 。有趣的是,你可能创造出一系列context泄漏的情况有很多,这非常糟糕。他们会是你很快内存溢出。
有两种简单的方法来避免context 相关的内存泄漏。最显著地一个是避免context 逃出他自己的范围之外。上面的例子就展示了使用静态引用的情况,而内部类和他们对外部类的的隐式引用也是同样危险的。第二种方法是使用Application context 。这个context 的生存周期和你的应用的生存周期一样长,而不是取决于activity 的生存周期。如果你想保持一个长期生存的对象,并且这个对象需要一个context ,记得使用application 对象。你可以通过调用Context.getApplicationContext()
or Activity.getApplication() 来获得。
总而言之,想要避免context 相关的内存泄漏 ,记住以下几点:
1、不要对activity 的context 长期引用( 一个activity 的引用的生存周期应该和activity 的生命周期相同)
2、试着使用关于application的 context 来替代和activity相关的context
3、如果一个acitivity 的非静态内部类的生命周期不受控制,那么避免使用它;使用一个静态的内部类并且对 其中的activity 使用一个弱引用。解决这个问题的方法是使用一个静态的内部类,并且对它的外部类有一 WeakReference,就像在ViewRoot中内部类W所做的就是这么个例子。
a037
4、垃圾回收器不能处理内存泄漏的保障
相关文章推荐
- 非静态的内部类会持有外部类的一个隐式引用 造成内存泄露
- 避免引用Context造成的内存泄露
- Android内存泄露问题(一)之context的引用
- 解决问题--VS2012中一个Panel覆盖另一个Panel时拖动时容易造成两个控件成父子关系的避免
- 多个js引用同一个jquery 避免冲突
- 造成 未将对象引用设置到对象实例 的另 一个原因
- 解决问题--VS2012中一个Panel覆盖另一个Panel时拖动时容易造成两个控件成父子关系的避免
- 如何避免在Block里用self造成循环引用
- android开发中对context引用造成内存泄漏的一些猜测
- 非静态内部类持有外部类的引用 使用不慎会造成内存溢出
- 如何避免在Block里用self造成循环引用
- SpringContextHolder 静态持有SpringContext的引用
- SpringContextHolder 静态持有SpringContext的引用(如何取得Spring管理的bean )
- SpringContextHolder 静态持有SpringContext的引用
- SpringContextHolder 静态持有SpringContext的引用
- 如何避免在Block里用self造成循环引用
- asp.net中引用同一个项目中的类库 避免goToDefinition时不能到达真正的定义类
- 安卓获取context是一个null对象的引用所出现的其中一种情况!坑
- 非静态的内部类会持有外部类的一个隐式引用
- 如何避免在Block里用self造成循环引用