也谈Android中的Context（1）

对于Android中的Context类，对于常年致力于移动开发的码农而言似乎也既熟悉又陌生。在Google api中对其介绍如下：

Interface to global information about an application environment. This is an abstract class whose implementation is provided by the Android system. It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.

由上可知，这个类提供了一个诸如执行Activity，发送广播，接收Intent等的入口。通过考察其继承结构，可以知道它是一个抽象类，ContextWrapper是其重要的直接子类

其实仔细分析Android中的类结构，能发现其中的精巧之处，我们熟知的Activity，Application，Service是这样被布局在一盘大棋上。

仅通过这一点了解，再去考察网上随处可见的文章，便可发现很多问题。诸如一段多处被引用的文字如下：

------------------------------------------------------------------------------------------------------------------------------------------------

Context字面意思上下文，位于framework package的android.content.Context中，其实该类为LONG型，类似Win32中的Handle句柄，很多方法需要通过 Context才能识别调用者的实例，比如说Toast的第一个参数就是Context，一般在Activity中我们直接用this代替，代表调用者的 实例为Activity，而到了一个button的onClick(View view)等方法时，我们用this时就会报错，所以我们可能使用ActivityName.this来解决，主要原因是因为实现Context的类主要有Android特有的几个模型，Activity、Service以及BroadcastReceiver。

------------------------------------------------------------------------------------------------------------------------------------------------

这段话中至少出现了两处错误：

1.类不为long型

2.BroadcastReceiver并不是实现Context的类

这里附带一句，很多地方把Context直译为 上下文，相应把ContextMenu译为 上下文菜单等，在最近的一次面试里我曾问道关于Context的理解，答曰：Context就是上下文。这个回答无异于“Activity就是活动”。随着Android开发近年的火爆，各种简单的翻译抄袭和充斥着各种误导的文章比比皆是，其实这时回归本源反而是最好的方式。

下面再探讨一下一个应用中会建立多少个Context的实例的问题，我们可以找到的比较好的答案可能如下：

总Context实例个数 = Service个数 + Activity个数 + 1（Application对应的Context实例）

然仔细分析，也会发现其中的一些变数。

首先，还是从类的继承结构来看，例如在应用中有用到ActivityGroup，这个公式直接就跪了。

第二，只有实例化了的Activity才会生成Context，例如我们写了一个通用的CustomActivity，它就可能生成多个Context，又如一次操作中未进入的Activity，Context就不会生成。当然对于公式的理解如果是“启动的Activity个数”，这一点并没有问题。