context上下文在Android中十分重要,随处可见。由集成体系了,可以看出 Activity Service Application 都最终集成于Context,可以分别通过getApplication()或者自己本身获取上下文,在广播中可以通过getAppliactionContext()获取上下文。 BroadcastReciver 和 内容提供者也提供上下文的功能。
toast 和 dialog 以及AlertDialog等都需要传入一个上下文,通过上下文引用获取LayoutInflater,启动广播注册,启动服务和绑定服务,都离不开上下文。
activity太特殊了,只要是context有的特点,他都有。并且作用范围最广,还有一些是独有的,比如支持AlertDialog 和 Dialog 的显示,其他 application service Broadcast都不支持。正常的AlertDialog 弹出时,它可以看做activity的一部分,弹出时,activity不会走onPause()生命周期。
平时也会通过LayoutInflater来映射布局, LayoutInflater LayoutInflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE); 这个功能,也只有activity可以当做context来用,其他的不行。
由一个页面启动另一个页面,并且跳转,也只有activity支持,其他的上下文都无心也无力。
toast是所有的都可以,但为了内存等问题,一般使用Application,使用activity也没问题。
resource 资源转化,也是所有上下文都支持,和toast一样的待遇。
启动 service和绑定service以及send 广播,也是所有的上下文都支持。
上下文有一种用法,当某个类写成单例模式,需要传入上下文,由于单例模式会一直引用上下文,生命周期特别差,会导致被引用的上下文无法被回收,此时上下文选择一定要慎重,保持上下文的生命周期,防止内存泄漏。
- public class CustomManager
- {
- private static CustomManager sInstance;
- private Context mContext;
- private CustomManager(Context context)
- {
- this.mContext = context;
- }
- public static synchronized CustomManager getInstance(Context context)
- {
- if (sInstance == null)
- {
- synchronized (CustomManager.class){
- if(sInstance == null) {
- sInstance = new CustomManager(context);
- }
-
- }
- }
- return sInstance;
- }
- }