译者:
本准备写一篇Context相关的文, 看到此文, 觉得很好, 先搞个"拿来主义"译过来, 作为探索Context系列的第一篇吧.
译文:
Context可能是我们开发App中用的最多是元素了, 也可能是最容易被误用的...
Context对象如此常见, 经常各种传递, 用来很方便的创建一些情景, 诸如加载资源文件, 启动一个新的Activity, 获取一个系统服务, 获取内部存储文件路径, 创建Views等等等等(太多了...). 我写此文的目的是想提供给你一些观察Context如何工作的视角, 以便你可以在你的App开发中更有效准确的使用Context.
1, Context类型
并不是所有的Context都是等同的. 根据你所在的App的组件(译者注: 组件包括Application, Activity, Service, Receiver, Provider)不同, Context略有不同:
Application Context
Application Context在你的应用进程里是一个单例的存在. 可以在Activity或Service中通过getApplication()来访问, 也可以在任意继承Context的对象中通过getApplicationContext()来访问. 不管以何种形式访问, 在同一应用进程中你获得的Application Context实例都是同一个.
Activity/Service Context
Activity/Service继承自ContextWrapper, ContextWrapper作为Context(一个Base Context)的代理, 实现了和Context一样的接口. 没当framework创建一个Activity/Service实例时, 也会创建一个ContextImpl的实例来真正处理(Context接口所描述的)繁重的工作. 每个Activity/Service实例, 都有一个对应的Base Context的实例.
Broadcast Receiver中的Context
实际上Broadcast Receiver并不是一个Context, 但是framework会每次广播事件到来时传递一个Context给onReceive()方法. 这个Context是一个ReceiverRestrictedContext实例, 它禁用了Context的registerReceiver()和bindService() (译者注: 这也是为什么我们说不能在onReceive方法里面绑定一个Service的起源). 每次有广播事件收到时, 传过来的Context都是一个新的Context实例.
ContentProvider中的Context
本身也不是一个Context, 但是可以通过getContext()方法来获取一个Context对象. 如果ContentProvider和调用者是同一个应用进程, getContext()会返回一个Application级别的单例的Context实例; 然而, 如果二者处于不同的进程, getContext()会返回一个新的代表Provider所运行的包的Context实例.
(译者注: 下面是作者的关于Context的使用经验)
2, 保存引用
第一个我们需要解决的问题是: 在一个对象或类中保存一个Context, 但是这个对象或类的生命周期超过了你保存的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或Service的引用是不安全的. 因为单例在类的内部维持一个单一的静态引用, 意味着这个单例, 以及该单例所引用的其他所有对象都永远不会被GC回收. 如果这个context是一个Activity, 我们将会持有这个Activity以及它的所有Views和其他可能的关联的大对象, 从而造成内存泄露.
为了避免这种问题, 我们使用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的来源, 因为我们保存的context引用是安全的. Application Context本身就是单例, 所以我们在创建另一个静态引用时不会泄露任何东西.
另一个很好的例子是, 在后台线程或是等待中的Hanlder中也可以使用Application类型的Context.
但是为什么我们不能总是使用Application Context呢? 正如前面例子中说的, 引用Application Context永远不用担心内存泄漏的问题. 问题的答案是, 就像我一开始介绍的那样, 是因为不同组件中的Context并不是完全一样的.
3, Context的能力
Context能做什么决定于它来自哪儿. 下表描述了常见的Context的来源以及其应用范围:
注解:
1, Application的Context可以启动一个Activity, 但是会在新Task中创建(译者注, 待验证). 这可能可以满足一些特定需求, 但是这也会创建不标准的返回栈(Back Stack), 所以不推荐, 也不认为是好的实践.
2, 这个也是合法的, 但是Inflate出来的View是根据你当前系统的默认主题(Theme)的, 而非你的Application所使用的主题.
3, Android 4.2及以上, 如果Receiver是null(用来获取一个Sticky Broadcast的当前值的), 则是允许的.
4, 用户界面
从前面的表格可以看到, 很多(UI相关的)情况下 Application Context并不适合来处理. 实际上, 只用Activity Context能够处理所有与UI相关的任务. 其他的任务所有类型的Context都差不多.
幸运的是, 有三种事是Activity之外不能处理的, 这可能是Android framework故意这么设计的. 如果你尝试使用Application Context去show一个对话框; 或是启动一个Activity, 系统会抛出异常, 导致崩溃---来提示你出问题了...
另外一个并不明显的是Inflate布局. 如果你读过我另一篇关于Layout Inflation的文(译者注, 这篇文也推荐一读, 有空了翻译下). 你就已经知道它可能是一个非常神秘的过程, 隐藏着一些不可知的行为。使用正确的Context关系到其中的行为表现. 当你使用Application Context来inflate一个布局的时候并不会报错, 会返回一个系统默认的主题的view给你, 而没有考虑你的Applicaiton本身的Theme和Style. 这是因为Acitivity是唯一的绑定了在manifast文件中定义主题Theme的Context. 其他的Context实例将会使用系统默认的主题来inflate你的view. 这可能会导致显示的View并不是你所希望的那样的.
5, 规则的交叉点
显然, 可能有些读者已经看出两个规则互相矛盾之处. 在一些Application的设计中, 我们可能既需要长期的保存一个引用，而且为了完成与UI相关的工作又必须保存一个Activity的Context. 如果出现这种情况, 我强烈建议你重新考虑你的设计, 它将是一个很好的"反框架"案例.
6, 使用经验
绝大多数情况下, 使用在你的所在的组件内部能够直接获取的Context. 只要这个Context引用没有超过这个组件的生命周期, 你就可以安全的保存这个引用. 一旦你要保存一个Context的引用到你的对象中, 该对象超过了你的Activity或者Service的生命周期范围, 即使是暂时的, 你就需要转换你的引用为Application Context.
