android中的context到底是什么？

Context神通作用：
Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要用到Context。

TextView tv = new TextView(getContext());
 
ListAdapter adapter = new SimpleCursorAdapter(getApplicationContext(), ...);
 
AudioManager am = (AudioManager) getContext().
                        getSystemService(Context.AUDIO_SERVICE);
getApplicationContext().getSharedPreferences(name, mode);
 
getApplicationContext().getContentResolver().query(uri, ...);
 
getContext().getResources().getDisplayMetrics().widthPixels * 5 / 8;
 
getContext().startActivity(intent);
 
getContext().startService(intent);
 
getContext().sendBroadcast(intent);

Context到底是什么？
Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。
Context我们通过它我们可以获取应用程序的资源和类（包括应用级别操作，如启动Activity，发广播，接受Intent等）。既然上面Context是一个抽象类，那么肯定有他的实现类咯，我们在Context的源码中通过IDE可以查看到他的子类最终可以得到如下关系图：

那Context到底是什么呢？一个Activity就是一个Context，一个Service也是一个Context。
所以就会发现将Activity作为Context传递，因为Activity就是一个context；

在应用程序中Context的具体实现子类就是：Activity，Service，Application。那么Context数量=Activity数量+Service数量+1。当然如果你足够细心，可能会有疑问：我们常说四大组件，这里怎么只有Activity，Service持有Context，那Broadcast Receiver，Content Provider呢？Broadcast Receiver，Content Provider并不是Context的子类，他们所持有的Context都是其他地方传过去的，所以并不计入Context总数。上面的关系图也从另外一个侧面告诉我们Context类在整个Android系统中的地位是多么的崇高，因为很显然Activity，Service，Application都是其子类，其地位和作用不言而喻。

Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要用到Context。
Activity继承自ContextThemeWrapper，而Application和Service继承自ContextWrapper

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

错误的单例模式

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掉，这样就导致了内存泄漏。

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中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。

总结

总之Context在Android系统中的地位很重要，它几乎无所不能，但它也不是你想用就能随便用的，谨防使用不当引起的内存问题。

Context 就相当于 Application 的大管家，主要负责：

四大组件的交互，包括启动 Activity、Broadcast、Service，获取 ContentResolver 等
获取系统/应用资源，包括 AssetManager、PackageManager、Resources、System Service 以及 color、string、drawable 等
文件，包括获取缓存文件夹、删除文件、SharedPreference 相关等
数据库（SQLite）相关，包括打开数据库、删除数据库、获取数据库路径等
其它辅助功能，比如设置 ComponentCallbacks，即监听配置信息改变、内存不足等事件的发生

context其实bai就是句柄，只不过不像windows一样，每个资源都可以du是一个句zhi柄，Android的一个句柄包含了很多全局信dao息，比如说Activity就是一个句柄
官方文档的解释是：Context提供了关于应用环境全局信息的接口。它是一个抽象类，它的执行被Android系统所提供。它允许获取以应用为特征的资源和类型。同时启动应用级的操作，如启动Activity，broadcasting和接收intents。