首页 > 安全资讯 >

getApplicationContext和Context的区别

17-03-23

getApplicationContext和Context的区别,Context的中文翻译为:语境; 上下文; 背景; 环境,在开发中我们经常说称之为“上下文”,那么这个“上下文”到底是指什么意思呢。

一、什么是Context

Context的中文翻译为:语境; 上下文; 背景; 环境,在开发中我们经常说称之为“上下文”,那么这个“上下文”到底是指什么意思呢?在语文中,我们可以理解为语境,在程序中,我们可以理解为当前对象在程序中所处的一个环境,一个与系统交互的过程。

getApplicationContext()

返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁。

Activity.this

返回当前activity的上下文,生命周期只是它所在的Activity,activity 摧毁他就摧毁。

二、生命周期

基本上来说呢,应用程序Context是和应用程序关联的,并且在程序的生命周期内,总是一样的。但是,活动Context是关联在某个活动上的。

随着Activity的销毁(比如横竖屏切换等情况),这个Context也会被销毁N多次。

三、Context作用域

由于Context的具体实例是由ContextImpl类去实现的,因此在绝大多数场景下,Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊,比如启动Activity,还有弹出Dialog。出于安全原因的考虑,Android是不允许Activity或Dialog凭空出现的,一个Activity的启动必须要建立在另一个Activity的基础之上,也就是以此形成的返回栈。

而Dialog则必须在一个Activity上面弹出(除非是System Alert类型的Dialog),因此在这种场景下,我们只能使用Activity类型的Context,否则将会出错。

Paste_Image.png

从上图我们可以发现Activity所持有的Context的作用域最广,无所不能。因为Activity继承自ContextThemeWrapper,而Application和Service继承自ContextWrapper,很显然ContextThemeWrapper在ContextWrapper的基础上又做了一些操作使得Activity变得更强大,这里我就不再贴源码给大家分析了,有兴趣的童鞋可以自己查查源码。上图中的YES和NO我也不再做过多的解释了,这里我说一下上图中Application和Service所不推荐的两种使用情况。

1:如果我们用ApplicationContext去启动一个LaunchMode为standard的Activity的时候会报错android.util.AndroidRuntimeException: Calling startActivity from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?这是因为非Activity类型的Context并没有所谓的任务栈,所以待启动的Activity就找不到栈了。解决这个问题的方法就是为待启动的Activity指定FLAG_ACTIVITY_NEW_TASK标记位,这样启动的时候就为它创建一个新的任务栈,而此时Activity是以singleTask模式启动的。

所有这种用Application启动Activity的方式不推荐使用,Service同Application。

2:在Application和Service中去layout inflate也是合法的,但是会使用系统默认的主题样式,如果你自定义了某些样式可能不会被使用。所以这种方式也不推荐使用。

3.创建对话框等UI操作要是有activity的context

I got bad window token errors when using application context to Progress

Dialog. So i used activity context instead.

我使用应用程序Context给进度条对话框的时候,出现了“window token errors”的错误。所以,我使用了活动Context,而不是应用程序Context。

一句话总结:凡是跟UI相关的,都应该使用Activity做为Context来处理;其他的一些操作,Service,Activity,Application等实例都可以,当然了,注意Context引用的持有,防止内存泄漏。

四、如何获取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也可以。

五、getApplication()和getApplicationContext()的区别

上面说到获取当前Application对象用getApplicationContext,不知道你有没有联想到getApplication(),这两个方法有什么区别?相信这个问题会难倒不少开发者。

Paste_Image.png

程序是不会骗人的,我们通过上面的代码,打印得出两者的内存地址都是相同的,看来它们是同一个对象。其实这个结果也很好理解,因为前面已经说过了。

Application本身就是一个Context,所以这里获取getApplicationContext()得到的结果就是Application本身的实例。

那么问题来了,既然这两个方法得到的结果都是相同的,那么Android为什么要提供两个功能重复的方法呢?实际上这两个方法在作用域上有比较大的区别。

getApplication()方法的语义性非常强,一看就知道是用来获取Application实例的,但是这个方法只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的。

但是如果在一些其它的场景,比如BroadcastReceiver中也想获得Application的实例,这时就可以借助getApplicationContext()方法了。

publicclassMyReceiverextendsBroadcastReceiver{

@Override

publicvoidonReceive(Context context,Intent intent){

ApplicationmyApp = (Application)context.getApplicationContext();

}

}

五、Context引起的内存泄露

Context并不能随便乱用,用的不好有可能会引起内存泄露的问题,下面就示例两种错误的引用方式。

1.错误的单例模式

public class Singleton {

private static Singleton instance;

private Context mContext;

private Singleton(Context context) {

this.mContext = context;

}

public static Singleton getInstance(Context context) {

if (instance == null) {

instance = new Singleton(context);

}

return instance;

}

}

这是一个非线程安全的单例模式,instance作为静态对象,其生命周期要长于普通的对象,其中也包含Activity,假如Activity A去getInstance获得instance对象,传入this,常驻内存的Singleton保存了你传入的Activity A对象,并一直持有,即使Activity被销毁掉,但因为它的引用还存在于一个Singleton中,就不可能被GC掉,这样就导致了内存泄漏。

2.View持有Activity引用

public class MainActivity extends Activity {

private static Drawable mDrawable;

@Override

protected void onCreate(Bundle saveInstanceState) {

super.onCreate(saveInstanceState);

setContentView(R.layout.activity_main);

ImageView iv = new ImageView(this);

mDrawable = getResources().getDrawable(R.drawable.ic_launcher);

iv.setImageDrawable(mDrawable);

}

}

有一个静态的Drawable对象当ImageView设置这个Drawable时,ImageView保存了mDrawable的引用,而ImageView传入的this是MainActivity的mContext,因为被static修饰的mDrawable是常驻内存的,MainActivity是它的间接引用,MainActivity被销毁时,也不能被GC掉,所以造成内存泄漏。

六、正确使用Context

一般Context造成的内存泄漏,几乎都是当Context销毁的时候,却因为被引用导致销毁失败,而Application的Context对象可以理解为随着进程存在的,所以我们总结出使用Context的正确姿势:

1:当Application的Context能搞定的情况下,并且生命周期长的对象,优先使用Application的Context。

2:不要让生命周期长于Activity的对象持有到Activity的引用。

3:尽量不要在Activity中使用非静态内部类,因为非静态内部类会隐式持有外部类实例的引用,如果使用静态内部类,将外部实例引用作为弱引用持有。

相关文章
最新文章
热点推荐