前言
Context，在翻译为上下文，也可以理解为环境，是提供一些程序的运行环境基础信息。基本上在开发项目的时候，时刻都有接触到。Android程序不像Java程序，随便创建一个类，写个main()方法就能跑，而是要有一个完整的Android工程环境，在这个环境下，有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，也就是Context。可以说Context是维持Android程序中各组件能够正常工作的一个核心功能类。
Context是个抽象类，下图取自网络，可以看到Context的继承结构。
ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。
而ContextWrapper又有三个直接的子类， ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity，所以Activity和Service以及Application的Context是不一样的，只有Activity需要主题，Service不需要主题。
Context一共有三种类型，分别是Application、Activity和Service。
这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。
Context应用场景：
NO上数字含义：
每一个Activity和Service以及Application的Context都是一个新的ContextImpl对象。
getApplication()用来获取Application实例的，但是这个方法只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法，getApplicationContext()比getApplication()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。
getBaseContext()方法得到的是一个ContextImpl对象。Application、Activity这样的类其实并不会去具体实现Context的功能，而仅仅是做了一层接口封装而已，Context的具体功能都是由ContextImpl类去完成的。
Context数量 = Activity数量 + Service数量 + 1 （1为Application）
最后注意下Context的引用，防止内存泄露问题，还有关于Context源码分析，网上还是很多资料可参考的。
总结
以上就是这篇文章的全部内容了，希望本文的内容对各位Android开发者们能有所帮助，如果有疑问大家可以留言交流。
