Android开发——Context类的各种细节问题

最新推荐文章于 2022-04-03 03:21:39 发布

SEU_Calvin

最新推荐文章于 2022-04-03 03:21:39 发布

阅读量8.7k

点赞数 5

分类专栏： Android开发

Android开发专栏收录该内容

74 篇文章 12 订阅

订阅专栏

0. 前言

Context相信所有的Android开发人员基本上每天都在接触，因为它太常见了。但实际上Context有太多小的细节并不被大家所关注，那么今天我们就来学习一下那些你所不知道的细节。

1. Context类继承结构

Activity、Service、BroadcastReceiver等系统组件，并不像一个普通的Java对象new一下就能创建实例了，它们要有各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。

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

Context的继承结构从上图一目了然。可以看到，直系子类有两个，一个是ContextWrapper（上下文功能的封装类），一个是ContextImpl（上下文功能的实现类）。而ContextWrapper又有三个直接的子类，ContextThemeWrapper（带主题的封装类）、Service和Application。其中，ContextThemeWrapper有一个直接子类就是Activity。

Context一共有三种类型，分别是Application、Activity和Service。因为一个应用程序中可以有多个Activity和多个Service，但是只能有一个Application，因此一个应用程序的Context数量 = Activity数量+ Service数量 + 1 个Application的数量。

2. Context类继承功能概述

上述Application、Activity和Service这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。那么Context到底可以实现哪些功能呢？这个就实在是太多了——弹出Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要用到Context。

由于Context的具体能力是由ContextImpl类去实现的，因此在绝大多数场景下，Activity、Service和Application这三种类型的Context都是可以通用的。不过有几种场景比较特殊，比如启动Activity，还有弹出Dialog。出于安全原因的考虑，Android规定一个Activity的启动必须要建立在另一个Activity的基础之上，也就是以此形成的返回栈。而Dialog则必须在一个Activity上面弹出，因此在这种场景下，我们只能使用Activity类型的Context，否则将会出错。

但是在Service里就不能做Toast吗？其实也是可以的，只是需要如下权限：

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />

AlertDialog dialog = new AlertDialog.Builder(this).setTitle("标题").setMessage("内容").setPositiveButton("确定", null).create();
dialog.getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
dialog.show();

3 Application Context相关问题

基本上每一个应用程序都会有一个自己的Application，并让它继承系统的Application类，然后在自己的Application类中去封装一些通用的操作。虽然这种做法没有什么副作用，但这不是Google所推荐的一种做法，因为使用一个简单的单例类也可以实现同样的功能。这只是说明还是有不少人对于Application理解的还有些欠缺。那么这里我们先来对Application的设计进行分析，然后再看一下平时使用Application常见的问题。

3.1 Application Context的配置

首先新建一个MyApplication并让它继承自Application，然后在AndroidManifest.xml文件中对MyApplication进行配置，只有配置了才能在我们的程序启动时系统创建一个MyApplication的实例，否则默认创建一个Application的实例。

3.2 Application Context的使用

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

public class MainActivity extends Activity {  
    @Override  
    protected void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_main);  
    //1.使用getApplication
        MyApplication myApp = (MyApplication) getApplication();  
        Log.d("TAG", "getApplication is " + myApp);  
    //2.使用getApplicationContext
Context appContext = getApplicationContext();  
        Log.d("TAG", "getApplicationContext is " + appContext);  
    //3.使用getBaseContext
Context baseContext = getBaseContext ();  
        Log.d("TAG", " getBaseContext is " + baseContext);  
    }  
}

从输出结果来看，前两个方法打印出的结果是一样的，连后面的内存地址都是相同的，看来它们是同一个对象。其实这个结果也很好理解，因为前面已经说过了，Application本身就是一个Context，所以这里获取getApplicationContext()得到的结果就是MyApplication本身的实例。

这两个方法的区别在于作用域。getApplication()方法的语义性非常强，一看就知道是用来获取Application实例的，getApplication()只有在Activity和Service中才能调用的到。那么也许在绝大多数情况下我们都是在Activity或者Service中使用Application的，但是如果在一些其它的场景，比如BroadcastReceiver中也想获得Application的实例，这时就可以借助getApplicationContext()方法了。

最后的getBaseContext得到的是一个ContextImpl对象。ContextImpl正是上下文功能的实现类，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中的方法的实现都调用了mBase对象中对应的方法。第16行的attachBaseContext()方法其实是由系统来调用的，它会把ContextImpl对象作为参数传递到attachBaseContext()方法当中，从而赋值给mBase对象，之后ContextWrapper中的所有方法其实都是通过这种委托的机制交由ContextImpl去具体实现的，所以说ContextImpl是上下文功能的实现类是非常准确的。

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

4. 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的方法  
    }  
}

5. Application Context和单例模式

上文中已经提到过了，Google不推荐我们使用自定义的Application，基本上只有需要做一些全局初始化的时候才可能需要用到自定义Application。但多数项目只是把自定义Application当成了一个通用工具类，虽然没什么副作用但使用单例模式实现可能更加优雅。

但是把自定义Application和单例模式混合到一起使用，那就大错特错了。一个非常典型的例子如下所示：

public class MyApplication extends Application {  
    private static MyApplication app;  
    public static MyApplication getInstance() {  
        if (app == null) {  
            app = new MyApplication();  
        }  
        return app;  
    }   
}

因为我们知道Application是属于系统组件，系统组件的实例是要由系统来去创建的，如果这里我们自己去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具备任何Context的能力。我们只需谨记一点，Application全局只有一个，它本身就已经是单例了，无需再用单例模式去为它做多重实例保护了，正确代码如下所示：

public class MyApplication extends Application {  
private static MyApplication app;  
    // getInstance()方法里面不需要任何逻辑判断，直接返回app对象就可以了
    public static MyApplication getInstance() {  
        return app;  
    }  
    @Override  
    public void onCreate() {  
        super.onCreate();  
    //this就是当前Application的实例，那么app也就是当前Application的实例了
        app = this;  
    }  
}

本文转载整理自郭大侠博客。最后请大家多点下面的赞支持~