请问Android中,Context,什么是Context?

请问Android中,Context,什么是Context?
请问Android中,Context,什么是Context?

请问Android中,Context,什么是Context?
,原文链接在这里,作者是Dave Smith.ps：这个网站的是设计风格非常清新.Context可能是Android应用中最常用的元素,而它也可能是最容易误用的.Context对象是如此常见和传递使用,它可能会很容易产生并不是你预期的情形.加载资源、启动一个新的Activity、获取系统服务、获取内部文件路径以及创建view（其实还远不止这些）统统都需要Context对象来完成.我(原文作者)想做的只是给大家提供一些Context是如何工作的见解,以及让大家在应用中更有效的使用Context的技巧.Context的类型并不是所有的context实例都是等价的.根据Android应用的组件不同,你访问的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所运行的包.保存引用第一个我们需要解决问题是,在一个对象或者类内部保存一个context引用,而它生命周期却超过其保存引用的对象的生命周期.例如,创建一个自定义的单例,它需要一个context来加载资源或者获取ContentProvider,从而保存一个指向当前Activiy或者Service的引用在单例中.糟糕的单例public class CustomManager { private static CustomManager sInstance; public static CustomManager getInstance(Context context) { if (sInstance == null) { sInstance = new CustomManager(context); } return sInstance; } private Context mContext; private CustomManager(Context context) { mContext = context; } }这里的问题在于,我们不知道这个context是从哪里来的,并且如果保存一个最终指向的是Activity或者Servece的引用是并不安全的.这是一个问题,是因为一个单例在类的内部维持一个唯一的静态引用,这意味着我们的对象,以及所有其他它所引用的对象,将永远不能被垃圾回收.假如这个Context是一个Activity,我们将保存与这个Activity相关的所有的view以及其他大的对象,从而造成内存泄漏.为了解决这个问题,我们修改单例永远只是保存Application context：改善的单例：public class CustomManager { private static CustomManager sInstance; public static CustomManager getInstance(Context context) { if (sInstance == null) { //Always pass in the Application Context sInstance = new CustomManager(context.getApplicationContext()); } return sInstance; } private Context mContext; private CustomManager(Context context) { mContext = context; } }现在这个例子中,我们的Context来自哪里都没有关系,因为我们这里保存引用是安全的.Application Context 本身就是一个单例,所以我们再创建另外一个static引用,不会造成任何内存泄漏.另外一个很好的例子是,在后台线程或者一个等待的Handler中保存Context的引用,也可以使用这样的方法.为什么我们不能总是引用Application context呢?正如前面说的,引用Application context永远不用担心内存泄漏的问题.问题的答案,就像我在开始的介绍中说的,是因为不同context并不是等价的.Context的能力Conext能做的通用操作决定于这个context最初来源于哪里.下表所列的是,在应用中常见的会收到context对象的,以及对应的每种情况,它可以用于哪些地方： ApplicationActivityServiceContentProviderBroadcastReceiverShow a DialogNOYESNONONOStart an ActivityNO1YESNO1NO1NO1Layout InflationNO2YESNO2NO2NO2Start a ServiceYESYESYESYESYESBind to a ServiceYESYESYESYESNOSend a BroadcastYESYESYESYESYESRegister BroadcastReceiverYESYESYESYESNO3Load Resource ValuesYESYESYESYESYES注：NO1 表示Application context的确可以开始一个Activity,但是它需要创建一个新的task.这可能会满足一些特定的需求,但是在你的应用中会创建一个不标准的回退栈（back stack）,这通常是不推荐的或者不是是好的实践.NO2 表示这是非法的,但是这个填充（inflation）的确可以完成,但是是使用所运行的系统默认的主题（theme）,而不是你app定义的主题.NO3 在Android4.2以上,如果Receiver是null的话（这是用来获取一个sticky broadcast的当前 值的）,这是允许的.用户界面UI从前面的表格中可以看到,application context有很多功能并不是合适去做,而这些功能都与UI相关.实际上,只有Activity能够处理所有与UI相关的任务.其他类别的context实例功能都差不多.幸运的是,在应用中这三种操作基本上都不需要在Activity范围之外进行,这很可能是android框架故意这么设计的.尝试显示一个使用Aplication context创建的Dialog,或者使用Application context开始一个Activity,系统会抛出一个异常,让你的application崩溃,非常强的告诉你某些地方出了问题.一个并不明显的问题是填充布局（inflating layout）.如果你已经读过了我（原文作者）的上一篇文章Layout inflation,你就已经知道它可能是一个非常神秘过程,伴随一些隐藏的行为.使用正确的context关系到其中的一个行为.当你使用Application context来inflate一个布局的时候,框架并不会报错,并返回一个使用系统默认的主题创建一个完美的view给你,而没有考虑你的applicaiton自定义的theme和style.这是因为Acitivity是唯一的绑定了在manifast文件种定义主题的Context.其他的Context实例将会使用系统默认的主题来inflater你的view.导致显示的结果并不是你所希望的.规则的路口可能有些读者已经得出两个规则互相矛盾的结论.可能有些情况下,在某些Application的设计中,我们可能既必须长期保存一个的引用,并且为了完成与UI相关的工作又必须保存一个Activity.如果出现这种情况,我将会强烈建议你重新考虑你的设计,它将是一个很好的“反框架”教材.经验法则绝大多数情况下,使用在你的所工作的组建内部能够直接获取的Context.只要这个引用没有超过这个组建的生命周期,你可以安全的保存这个引用.