探索Android的Context之Context是什么

最新推荐文章于 2022-07-18 22:19:56 发布

ReminderFish

最新推荐文章于 2022-07-18 22:19:56 发布

阅读量330

点赞数 1

分类专栏： Android 文章标签： context android

Android 专栏收录该内容

51 篇文章 1 订阅

订阅专栏

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实例.

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;
    }
}

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.

原文链接探索Context之Context是什么