传递给BroadcastReceiver与ContentProvider的Context来源及创建机制是什么

Android中Activity和Service的Context来源与创建流程 #

我们知道Android的Context是应用访问系统资源、调用系统服务的核心上下文类，Activity和Service本身就是Context的子类，二者的Context实例创建均由系统服务ActivityThread统筹完成：

1. Activity的Context来源与创建逻辑 #

• 继承关系：Activity继承自ContextThemeWrapper → 后者继承ContextWrapper → 最终继承Context基类
• 具体创建流程：
  • 当启动Activity的请求到达ActivityThread时，系统会调用performLaunchActivity()方法
  • 方法内部首先通过类加载器创建目标Activity的实例
  • 接着创建ContextImpl实例（这是Context抽象类的唯一实现类，所有Context的功能逻辑最终都由它实现）
  • 调用Activity的attach()方法，把ContextImpl实例、当前进程信息、ActivityToken、主题配置等参数传入，完成Activity与ContextImpl的绑定
  • ContextWrapper类内部持有mBase成员变量指向传入的ContextImpl实例，我们在Activity中调用的所有Context相关方法，最终都会转发给这个mBase实例执行

2. Service的Context来源与创建逻辑 #

• 继承关系：Service继承自ContextWrapper → 最终继承Context基类，和Activity不同的是不需要主题相关封装，所以没有继承ContextThemeWrapper
• 具体创建流程：
  • 启动Service的请求到达ActivityThread后，系统调用handleCreateService()方法
  • 同样先通过类加载器创建目标Service的实例
  • 创建对应的ContextImpl实例，配置Service相关的上下文参数
  • 调用Service的attach()方法，把ContextImpl实例传入完成绑定
  • Service中调用的Context方法同样会转发给内部持有的ContextImpl实例执行

补充说明：不管是Activity还是Service，我们日常开发中直接拿到的上下文实例就是组件本身，但其内部的核心功能实现全部委托给了系统创建的ContextImpl实例，这也是为什么不能随便拿Activity/Service的Context做长生命周期持有、避免内存泄漏的核心原因之一。

内容的提问来源于stack exchange，提问作者Jim