通过阅读源码,我们会发现:
1、它描述的是一个应用程序环境的信息,即上下文。
2、该类是一个抽象(abstract class)类,Android提供了该抽象类的具体实现类ContextIml。
3、Activity类 、Service类 、Application类本质上都是Context子类,Broadcast reseive中系统会传递一个Context进来;
4、程序中Context实例个数 = Service个数 + Activity个数 + 1(Application对应的Context实例)
5、注意context的生命周期,比如Android知识梳理:消息机制之Handler(http://gqdy365.iteye.com/admin/blogs/2148925)中提的。
6、不同的context,其能力是不一样的,见下表(来自网络):
[img]http://dl2.iteye.com/upload/attachment/0102/6405/b1cf36a5-d134-390c-b7a3-4212369a2fcf.png[/img]
注:NO1 表示Application context的确可以开始一个Activity,但是它需要创建一个新的task。这可能会满足一些特定的需求,但是在你的应用中会创建一个不标准的回退栈(back stack),这通常是不推荐的或者不是是好的实践。
NO2 表示这是非法的,但是这个填充(inflation)的确可以完成,但是是使用所运行的系统默认的主题(theme),而不是你app定义的主题。
NO3 在Android4.2以上,如果Receiver是null的话(这是用来获取一个sticky broadcast的当前 值的),这是允许的
getApplicationContext() 返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁
Activity.this的context 返回当前activity的上下文,属于activity ,activity 摧毁他就摧毁
getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文
1、它描述的是一个应用程序环境的信息,即上下文。
2、该类是一个抽象(abstract class)类,Android提供了该抽象类的具体实现类ContextIml。
3、Activity类 、Service类 、Application类本质上都是Context子类,Broadcast reseive中系统会传递一个Context进来;
4、程序中Context实例个数 = Service个数 + Activity个数 + 1(Application对应的Context实例)
5、注意context的生命周期,比如Android知识梳理:消息机制之Handler(http://gqdy365.iteye.com/admin/blogs/2148925)中提的。
6、不同的context,其能力是不一样的,见下表(来自网络):
[img]http://dl2.iteye.com/upload/attachment/0102/6405/b1cf36a5-d134-390c-b7a3-4212369a2fcf.png[/img]
注:NO1 表示Application context的确可以开始一个Activity,但是它需要创建一个新的task。这可能会满足一些特定的需求,但是在你的应用中会创建一个不标准的回退栈(back stack),这通常是不推荐的或者不是是好的实践。
NO2 表示这是非法的,但是这个填充(inflation)的确可以完成,但是是使用所运行的系统默认的主题(theme),而不是你app定义的主题。
NO3 在Android4.2以上,如果Receiver是null的话(这是用来获取一个sticky broadcast的当前 值的),这是允许的
getApplicationContext() 返回应用的上下文,生命周期是整个应用,应用摧毁它才摧毁
Activity.this的context 返回当前activity的上下文,属于activity ,activity 摧毁他就摧毁
getBaseContext() 返回由构造函数指定或setBaseContext()设置的上下文