Android中context可以作很多操作,但是最主要的功能是加载和访问资源。

在android中有两种context,一种是application context,一种是activity context,通常我们在各种类和方法间传递的是activity context。


继承关系:



区别联系:

public class MyActivity extends Activity {    public void method() {       mContext = this;    // since Activity extends Context       mContext = getApplicationContext();       mContext = getBaseContext();    } }
this 是Activity 的实例,扩展了Context,其生命周期是Activity 创建到销毁
getApplicationContext()返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁
Activity.this的context返回当前activity的上下文,属于activity ,activity 摧毁他就摧毁
getBaseContext()返回由构造函数指定或setBaseContext()设置的上下文,SDK文档很少,不推荐使用

搞清楚了生命周期就会在使用过程中犯错误,比如有一个全局的数据操作类用到了context,这个时候就要用到getApplicationContext 而不是用ACtivity,这就保证了数据库的操作与activity无关(不会一直引用Activity的资源,防止内存泄漏)


应用场景:
比如一个activity的onCreate:

protected void onCreate(Bundle state) {             super.onCreate(state);             TextView label = new TextView(this); //传递context给view control             label.setText("Leaks are bad");             setContentView(label);}

把activity context传递给view,意味着view拥有一个指向activity的引用,进而引用activity占有的资源:view hierachy, resource等。

这样如果context发生内存泄露的话,就会泄露很多内存。这里泄露的意思是gc没有办法回收activity的内存。


Leaking an entire activity是很容易的一件事。当屏幕旋转的时候,系统会销毁当前的activity,保存状态信息,再创建一个新的activity

比如我们写了一个应用程序,它需要加载一个很大的图片,我们不希望每次旋转屏幕的时候都销毁这个图片重新加载。

实现这个要求的简单想法就是定义一个静态的Drawable,这样Activity 类创建销毁它始终保存在内存中。

实现示例:

public class myactivity extends Activity {               private static Drawable sBackground;               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);//drawable attached to a view                      setContentView(label);               }}

这段程序看起来很简单,但是却问题很大。当屏幕旋转的时候会有leak(即gc没法销毁activity)。

我们刚才说过,屏幕旋转的时候系统会销毁当前的activity。但是当drawable和view关联后,drawable保存了view的reference,即sBackground保存了label的引用,而label保存了activity的引用

既然drawable不能销毁,它所引用和间接引用的都不能销毁,这样系统就没有办法销毁当前的activity,于是造成了内存泄露。gc对这种类型的内存泄露是无能为力的。


避免这种内存泄露的方法是避免activity中的任何对象的生命周期长过activity,避免由于对象对activity的引用导致activity不能正常被销毁。

我们可以使用application context。

application context伴随application的一生,与activity的生命周期无关。

application context可以通过Context.getApplicationContext()或者Activity.getApplicationContext()方法获取。


避免context相关的内存泄露,记住以下几点:

1. 不要让生命周期长的对象引用activity context,即保证引用activity的对象要与activity本身生命周期是一样的

2. 对于生命周期长的对象,可以使用application context

3. 避免非静态的内部类,尽量使用静态类,避免生命周期问题,注意内部类对外部对象引用导致的生命周期变化



参考推荐:

Android程序里面传Context对象

Android context(Application/Activity)与内存泄露


更多相关文章

  1. android点滴(23)之android监听应用卸载
  2. Android(安卓)屏幕横竖屏切换
  3. Android(安卓)各类生命周期详解
  4. Flutter1.12与原生Android交互(kotlin)
  5. android 格式化
  6. LayoutInflater.inflate()方法的介绍
  7. 引用自定义资源需注意数据类型
  8. LayoutInflater.inflate()方法的介绍
  9. Android如何引用其他工程

随机推荐

  1. MySQL慢查询的坑
  2. 解决MySQL存储时间出现不一致的问题
  3. MySQL安装后默认自带数据库的作用详解
  4. MySQL Router的安装部署
  5. MySQLShell的介绍以及安装
  6. MySQL InnoDB ReplicaSet(副本集)简单介
  7. MySQL 角色(role)功能介绍
  8. 浅谈Mysql多表连接查询的执行细节
  9. Mysql基础之常见函数
  10. MySQL分库分表与分区的入门指南