各个context的说明
Context:是一个接口类,主要提供通用接口
ContextImpl:Context接口的具体实现类
ContextWrapper:Context的包装类,内部持有一个ContextImpl的实例对象mBase,对Context的操作最终都进入ContextImpl类
ContextThemeWrapper:该类内部包含了主题(Theme)相关的接口,即android:theme属性指定的。Service不需要主题,所以Service直接继承于ContextWrapper类。而Activity继承此类。
Activity Service Applcation 分别介绍
Activity
1、UI相关的Context都推荐使用Activity,否则有可能会有异常
2、Activity的功能最全面,可以在任何需要Context的地方使用Activity
Service
1、不能用来创建Dialog
2、如果用来进行视图填充(LayoutInflation),设置的主题不会生效,只会显示默认主题
3、如果用来启动一个Activity,新的Activity会在一个新的task任务栈,不建议这么使用
Applciation
1、直接用来创建创建Dialog,会抛异常Crash,除非进行特殊设置,所以不建议这么使用
2、和Service相同,不建议用来进行视图填充(LayoutInflation),否则只显示默认主题
3、和Service相同,不建议用来启动Activity
context的类型
Application - 是一个运行在你的应用进程中的单例。在Activity或者Service中,它可以通过getApplication()函数获得,
或者人和继承于context的对象中,通过getApplicationContext()方法获得。不管你是通过何种方法在哪里获得的,在一个进程内,你总是获得到同一个实例。
Activity/Service - 继承于ContextWrapper,它实现了与context同样API,但是代理这些方法调用到内部隐藏的Context实例,
即我们所知道的基础context。任何时候当系统创建一个新的Activity或者Service实例的时候,它也创建一个新的ContextImpl实例来做所有的繁重的工作。
每一个Activity和Service以及其对应的基础context,对每个实例来说都是唯一的。
BroadcastReciver - 它本身不是context,也没有context在它里面,但是每当一个新的广播到达的时候,
框架都传递一个context对象到onReceive()。这个context是一个ReceiverRestrictedContext实例,它有两个主要函数被禁掉:registerReceiver()和bindService()。
这两个函数在BroadcastReceiver.onReceive()不允许调用。每次Receiver处理一个广播,传递进来的context都是一个新的实例。
ContentProvider - 它本身也不是一个Context,但是它可以通过getContext()函数给你一个Context对象。
如果ContentProvider是在调用者的的本地(例如,在同一个应用进程),getContext()将返回的是Application单例。然而,如果调用这和ContentProvider在不同的进程的时候,它将返回一个新创建的实例代表这个Provider所运行的包