Android-Context

http://blog.csdn.net/guolin_blog/article/details/47028975

Context类型

我们知道，Android应用都是使用Java语言来编写的，那么大家可以思考一下，一个Android程序和一个Java程序，他们最大的区别在哪里？划分界限又是什么呢？其实简单点分析，Android程序不像Java程序一样，随便创建一个类，写个main()方法就能跑了，而是要有一个完整的Android工程环境，在这个环境下，我们有像Activity、Service、BroadcastReceiver等系统组件，而这些组件并不是像一个普通的Java对象new一下就能创建实例的了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

下面我们来看一下Context的继承结构：



Context的继承结构还是稍微有点复杂的，可以看到，直系子类有两个，一个是ContextWrapper，一个是ContextImpl。那么从名字上就可以看出，ContextWrapper是上下文功能的封装类，而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类，ContextThemeWrapper、Service和Application。其中，ContextThemeWrapper是一个带主题的封装类，而它有一个直接子类就是Activity。

那么在这里我们至少看到了几个所比较熟悉的面孔，Activity、Service、还有Application。由此，其实我们就已经可以得出结论了，Context一共有三种类型，分别是Application、Activity和Service。这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。

那么Context到底可以实现哪些功能呢？这个就实在是太多了，弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等等等都需要用到Context。由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android是不允许Activity或Dialog凭空出现的，一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出（除非是System Alert类型的Dialog），因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

Context数量

那么一个应用程序中到底有多少个Context呢？其实根据上面的Context类型我们就已经可以得出答案了。Context一共有Application、Activity和Service三种类型，因此一个应用程序中Context数量的计算公式就可以这样写：

Context数量 = Activity数量 + Service数量 + 1

上面的1代表着Application的数量，因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application。

Application Context的设计

基本上每一个应用程序都会有一个自己的Application，并让它继承自系统的Application类，然后在自己的Application类中去封装一些通用的操作。其实这并不是Google所推荐的一种做法，因为这样我们只是把Application当成了一个通用工具类来使用的，而实际上使用一个简单的单例类也可以实现同样的功能。但是根据我的观察，有太多的项目都是这样使用Application的。当然这种做法也并没有什么副作用，只是说明还是有不少人对于Application理解的还有些欠缺

首先新建一个MyApplication并让它继承自Application，然后在AndroidManifest.xml文件中对MyApplication进行指定，如下所示：

<application
android:name=".MyApplication"
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
......
</application>

指定完成后，当我们的程序启动时Android系统就会创建一个MyApplication的实例，如果这里不指定的话就会默认创建一个Application的实例。

前面提到过，现在很多的Application都是被当作通用工具类来使用的，那么既然作为一个通用工具类，我们要怎样才能获取到它的实例呢？如下所示：

public class MainActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
MyApplication myApp = (MyApplication) getApplication();
Log.d("TAG", "getApplication is " + myApp);
}

}

那么除了getApplication()方法，其实还有一个getApplicationContext()方法，可以获取到Application的实例。这两个方法得到的是同一个对象。其实这个结果也很好理解，因为前面已经说过了，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是MyApplication本身的实例。

那么有的朋友可能就会问了，既然这两个方法得到的结果都是相同的，那么Android为什么要提供两个功能重复的方法呢？实际上这两个方法在作用域上有比较大的区别。getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，但是这个方法只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法了，如下所示：

public class MyReceiver extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {
MyApplication myApp = (MyApplication) context.getApplicationContext();
Log.d("TAG", "myApp is " + myApp);
}

}

也就是说，getApplicationContext()方法的作用域会更广一些，任何一个Context的实例，只要调用getApplicationContext()方法都可以拿到我们的Application对象。

那么更加细心的朋友会发现，除了这两个方法之外，其实还有一个getBaseContext()方法，这个baseContext又是什么东西呢？

这次得到的是不同的对象了，getBaseContext()方法得到的是一个ContextImpl对象。

这个ContextImpl是不是感觉有点似曾相识？回去看一下Context的继承结构图吧，ContextImpl正是上下文功能的实现类。也就是说像Application、Activity这样的类其实并不会去具体实现Context的功能，而仅仅是做了一层接口封装而已，Context的具体功能都是由ContextImpl类去完成的。那么这样的设计到底是怎么实现的呢？我们还是来看一下源码吧。因为Application、Activity、Service都是直接或间接继承自ContextWrapper的，我们就直接看ContextWrapper的源码，如下所示：

/**
* Proxying implementation of Context that simply delegates all of its calls to
* another Context.  Can be subclassed to modify behavior without changing
* the original Context.
*/
public class ContextWrapper extends Context {
Context mBase;

/**
* Set the base context for this ContextWrapper.  All calls will then be
* delegated to the base context.  Throws
* IllegalStateException if a base context has already been set.
*
* @param base The new base context for this wrapper.
*/
protected void attachBaseContext(Context base) {
if (mBase != null) {
throw new IllegalStateException("Base context already set");
}
mBase = base;
}

/**
* @return the base context as set by the constructor or setBaseContext
*/
public Context getBaseContext() {
return mBase;
}

@Override
public AssetManager getAssets() {
return mBase.getAssets();
}

@Override
public Resources getResources() {
return mBase.getResources();
}

@Override
public ContentResolver getContentResolver() {
return mBase.getContentResolver();
}

@Override
public Looper getMainLooper() {
return mBase.getMainLooper();
}

@Override
public Context getApplicationContext() {
return mBase.getApplicationContext();
}

@Override
public String getPackageName() {
return mBase.getPackageName();
}

@Override
public void startActivity(Intent intent) {
mBase.startActivity(intent);
}

@Override
public void sendBroadcast(Intent intent) {
mBase.sendBroadcast(intent);
}

@Override
public Intent registerReceiver(
BroadcastReceiver receiver, IntentFilter filter) {
return mBase.registerReceiver(receiver, filter);
}

@Override
public void unregisterReceiver(BroadcastReceiver receiver) {
mBase.unregisterReceiver(receiver);
}

@Override
public ComponentName startService(Intent service) {
return mBase.startService(service);
}

@Override
public boolean stopService(Intent name) {
return mBase.stopService(name);
}

@Override
public boolean bindService(Intent service, ServiceConnection conn,
int flags) {
return mBase.bindService(service, conn, flags);
}

@Override
public void unbindService(ServiceConnection conn) {
mBase.unbindService(conn);
}

@Override
public Object getSystemService(String name) {
return mBase.getSystemService(name);
}

......
}

由于ContextWrapper中的方法还是非常多的，我就进行了一些筛选，只贴出来了部分方法。那么上面的这些方法相信大家都是非常熟悉的，getResources()、getPackageName()、getSystemService()等等都是我们经常要用到的方法。那么所有这些方法的实现又是什么样的呢？其实所有ContextWrapper中方法的实现都非常统一，就是调用了mBase对象中对应当前方法名的方法。

那么这个mBase对象又是什么呢？我们来看第16行的attachBaseContext()方法，这个方法中传入了一个base参数，并把这个参数赋值给了mBase对象。而attachBaseContext()方法其实是由系统来调用的，它会把ContextImpl对象作为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象，之后ContextWrapper中的所有方法其实都是通过这种委托的机制交由ContextImpl去具体实现的，所以说ContextImpl是上下文功能的实现类是非常准确的。

那么另外再看一下我们刚刚打印的getBaseContext()方法，在第26行。这个方法只有一行代码，就是返回了mBase对象而已，而mBase对象其实就是ContextImpl对象，因此刚才的打印结果也得到了印证。

使用Application的问题

虽说Application的用法确实非常简单，但是我们平时的开发工作当中也着实存在着不少Application误用的场景，那么今天就来看一看有哪些比较容易犯错的地方是我们应该注意的。

Application是Context的其中一种类型，那么是否就意味着，只要是Application的实例，就能随时使用Context的各种方法呢？我们来做个实验试一下就知道了：

public class MyApplication extends Application {

public MyApplication() {
String packageName = getPackageName();
Log.d("TAG", "package name is " + packageName);
}

}

应用程序一启动就立刻崩溃了，报的是一个空指针异常。看起来好像挺简单的一段代码，怎么就会成空指针了呢？但是如果你尝试把代码改成下面的写法，就会发现一切正常了：

public class MyApplication extends Application {

@Override
public void onCreate() {
super.onCreate();
String packageName = getPackageName();
Log.d("TAG", "package name is " + packageName);
}

}

在构造方法中调用Context的方法就会崩溃，在onCreate()方法中调用Context的方法就一切正常，那么这两个方法之间到底发生了什么事情呢？我们重新回顾一下ContextWrapper类的源码，ContextWrapper中有一个attachBaseContext()方法，这个方法会将传入的一个Context参数赋值给mBase对象，之后mBase对象就有值了。而我们又知道，所有Context的方法都是调用这个mBase对象的同名方法，那么也就是说如果在mBase对象还没赋值的情况下就去调用Context中的任何一个方法时，就会出现空指针异常，上面的代码就是这种情况。Application中方法的执行顺序如下图所示：



Application中在onCreate()方法里去初始化各种全局的变量数据是一种比较推荐的做法，但是如果你想把初始化的时间点提前到极致，也可以去重写attachBaseContext()方法，如下所示：

public class MyApplication extends Application {

@Override
protected void attachBaseContext(Context base) {
// 在这里调用Context的方法会崩溃
super.attachBaseContext(base);
// 在这里可以正常调用Context的方法
}

}

以下原文：http://mp.weixin.qq.com/s?__biz=MzA4NTQwNDcyMA==&mid=2650661511&idx=1&sn=1b7390e2c971e50a0db4d07c7b9ebb6f&scene=4#wechat_redirect

context使用表：



Context相关的内存泄漏问题

在讨论内存泄漏之前，先简单的说说Android中内存的回收

Dalivik虚拟机扮演了常规的垃圾回收角色，为了GC能够从App中及时回收内存，我们需要时时刻刻在适当的时机来释放引用对象，Dalvik的GC会自动把离开活动线程的对象进行回收。

什么是Android内存泄漏：

虽然Android是一个自动管理内存的开发环境，但是垃圾回收器只会移除那些已经失去引用的、不可达的对象，在十几万、几十万行代码中，由于你的失误使得一个本应该被销毁的对象仍然被错误的持有，那么该对象就永远不会被释放掉，这些已经没有任何价值的对象，仍然占据聚集在你的堆内存中，GC就会被频繁触发，多说几句，如果手机不错，一次GC的时间70毫秒，不会对应用的性能产生什么影响，但是如果一个手机的性能不是那么出色，一次GC时间120毫秒，出现大量的GC操作，我相信用户就能感觉到了吧。这些无用的引用堆积在堆内存中，越积越多最终导致Crash，有关一些性能优化推荐给大家一个我总结的博客。

「Android性能优化总结」

有些跑题了，我们赶紧来看看什么情况下Context会引发内存泄漏

错误的单例模式



我们来分析一下这个非线程安全的单例模式，假设你在Activity A去getInstance获得instance对象，顺手传了一个this，好了，现在一个常驻内存的Singleton保存了你传入Activity A的对象，并且一直持有Activity A的引用，这样即使你Activity被销毁掉，但是因为它的引用还存在于一个Singleton中，是不可能被GC掉的，这样就导致了内存泄漏。

View持有Activity的引用



再来分析一下，有一个静态的Drawable对象，当我给ImageView设置这个Drawable时，ImageView像上面那个例子一样，保存了这个mDrawable的引用（大家可以点开源码705行去看，很多UI组件都是统一的操作，一直持有传入的对象），然而ImageView传入了this，也就是ImageView同样持有一个MainActivity的mContext。因为被static修饰的mDrawable是常驻内存的，MainActivity是它的间接引用，所以当MainActivity被销毁时，也不能被GC掉，所以也造成了内存泄漏。

使用Context的正确姿势

通俗一点说，Context造成的内存泄漏，几乎都是当Context销毁的时候，却还被各种不合理、无端地引用着。那么哪个Context对象是不会被销毁的呢？对了，Application的Context对象可以理解为随着进程存在的，所以当Application的Context能搞定的情况下，并且生命周期长的对象，优先使用Application的Context



调用一行代码：



回头看看上面那张表格，显然Application的Context不是万能的，涉及UI加载操作时，似乎我们只能使用Activity的Context，所以你当你使用Activity的Context时，你要对持有Activity的对象心中有数，保证它能随着生命周期的销毁而被回收，慎用static关键字，不要因为方便访问就各种static乱入。

多说一点，上表中Layout Inflation中只能使用Activity的Context，而各种View在创建时，需要传入的Context参数也是Activity的，大家懂了吧，当解析XML文件的时候，传入的参数也就统一了，相信大家一定能想明白这点。

写在最后：

给大家推荐一个内存检测的自动化工具，LeakCanary，但是当你曾经写出的代码不规范不负责，已经达到十几万行，几十万行的时候，再去抽丝剥茧试图解开已经打上层层死结的引用关联，是非常难的。所以平时还是要注意下细节哈~