一、Context 的官方定义与核心作用
官方注释：关于应用程序环境的全局信息的接口。这是一个抽象类，它的实现是由 Android 系统提供。它允许访问特定应用的资源和类，以及向上调用应用程序级的操作，如启动活动，广播和接收 Intent 等。
【补充】
Context是 Android 应用开发的基石，几乎所有系统服务（如LayoutInflater、SharedPreferences、PackageManager）的获取都依赖于它。其本质是应用程序运行环境的句柄。
二、Context 的创建机制：AMS 与“凭证”传递
应用程序的启动受 AMS（Activity Manager Service） 的调控。在程序启动过程中：
- AMS 作为系统级进程，拥有访问系统级操作的权限；
- AMS 会通过跨进程通信（IPC） 向应用程序传递一个“凭证”；
- 应用程序将该“凭证”封装成
Context，并提供一系列接口，从而方便地访问系统资源。
【补充】
此处的“凭证”可理解为Binder 代理对象或Token，代表了应用在系统中的身份与权限上下文。没有此凭证，应用无法合法请求系统服务。
三、Context 的类继承体系与装饰者模式
3.1 抽象基类：Context
- 最顶层是
Context抽象类； - 它定义了一系列与系统交汇的接口（如
startActivity()、registerReceiver()、getResources()等）。
3.2 中间层：ContextWrapper
-
ContextWrapper继承自Context； -
但并未真正实现
Context中的接口； - 而是将所有接口调用委托（delegate）给内部持有的
ContextImpl实例。
【补充】
这种“持有+委托”的设计正是装饰者模式（Decorator Pattern） 的典型应用——ContextWrapper可在不修改底层实现的前提下，动态添加行为（如主题支持）。
3.3 真正实现者：ContextImpl
-
ContextImpl是Context接口的真正实现者； - 从 AMS 获取的“凭证”被封装到
ContextImpl中； -
ContextWrapper持有一个ContextImpl实例，并将其作为所有方法调用的目标。
四、具体子类及其角色
4.1 Application 与 Service
-
Application和Service均直接继承自ContextWrapper； - 因此它们天然具备
Context的全部接口方法； - 并且自身即是
Context对象，可直接用于系统 API 调用。
4.2 Activity 的特殊性：主题支持
-
Activity比较特殊，因为它是有界面的组件； - 因此它需要支持主题（Theme）；
- Android 引入了
ContextThemeWrapper，它在ContextWrapper的基础上增加了与主题相关的操作（如setTheme()、getTheme()）； -
Activity继承自ContextThemeWrapper，从而获得主题能力。
【补充】
主题（Theme）是一组 UI 属性的集合（如颜色、字体、控件样式），通过Context绑定到LayoutInflater，影响整个 Activity 的视觉表现。
五、图示说明
关键架构图：
context
【图示位置说明】
该图应位于“Context 的类继承体系”部分之后，直观展示Context←ContextWrapper← (Application,Service,ContextThemeWrapper) ←Activity的继承关系，以及ContextImpl作为实际实现者的委托路径。
