Context上下文的一些应用

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 广播，也是所有的上下文都支持。

上下文有一种用法，当某个类写成单例模式，需要传入上下文，由于单例模式会一直引用上下文，生命周期特别差，会导致被引用的上下文无法被回收，此时上下文选择一定要慎重，保持上下文的生命周期，防止内存泄漏。

1. public class CustomManager  
2. {  
3.     private static CustomManager sInstance;  
4.     private Context mContext;  
5.   
6.     private CustomManager(Context context)  
7.     {  
8.         this.mContext = context;  
9.     }  
10.   
11.     public static synchronized CustomManager getInstance(Context context)  
12.     {  
13.         if (sInstance == null)  
14.         {  
15. synchronized (CustomManager.class){
16. if(sInstance == null)  {
17.  sInstance = new CustomManager(context);  
    
18. }
19. 
    
20. }
21.         }  
22.         return sInstance;  
23.     }  
24.       
25. }  

此时如果传入activity，该acitivity会一直存在，即使调用了finish()方法，依然无法关闭，长时间会造成内存泄漏。