Android开发 Context详解与类型 转载

时间  2019-12-07
标签 android 开发 context 详解 类型 转载 栏目 Android 繁體版
原文   原文链接

转载地址:https://blog.csdn.net/guolin_blog/article/details/47028975

我的总结:

Context分为android

  • 　　activity : activity其实就是Context,在通常须要使用Context引用状况,直接使用它是最好的.
  • 　　Service : 与activity同样.
  • 　　Application : 应用Context,一个app只有一个此Context,不建议随便调用,不然会让某些类持有后,这些类没法被释放.使用的状况只有一种:某个功能或框架须要全局初始化,而且全局调用
  • 　　baseContext  :  基础底层上下文,Application仍是baseContext的封装,因此与Application同样,不建议随便调用

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。app

Application Context的设计

基本上每个应用程序都会有一个本身的Application，并让它继承自系统的Application类，而后在本身的Application类中去封装一些通用的操做。其实这并非Google所推荐的一种作法，由于这样咱们只是把Application当成了一个通用工具类来使用的，而实际上使用一个简单的单例类也能够实现一样的功能。可是根据个人观察，有太多的项目都是这样使用Application的。固然这种作法也并无什么反作用，只是说明仍是有很多人对于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都是被看成通用工具类来使用的，那么既然做为一个通用工具类，咱们要怎样才能获取到它的实例呢？以下所示：

 ide

  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()方法就能拿到咱们自定义的Application的实例了，打印结果以下所示：



那么除了getApplication()方法，其实还有一个getApplicationContext()方法，这两个方法看上去好像有点关联，那么它们的区别是什么呢？咱们将代码修改一下：

   工具

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);
            Context appContext = getApplicationContext();
            Log.d("TAG", "getApplicationContext is " + appContext);
        }
        
    }

一样，咱们把getApplicationContext()的结果打印了出来，如今从新运行代码，结果以下图所示：




咦？好像打印出的结果是同样的呀，连后面的内存地址都是相同的，看来它们是同一个对象。其实这个结果也很好理解，由于前面已经说过了，Application自己就是一个Context，因此这里获取getApplicationContext()获得的结果就是MyApplication自己的实例。


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

 oop

   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对象，所以刚才的打印结果也获得了印证。

this

使用Application的问题

虽然说Application的用法确实很是简单，可是咱们平时的开发工做当中也着实存在着很多Application误用的场景，那么今天就来看一看有哪些比较容易犯错的地方是咱们应该注意的。


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

 

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



这是一个很是简单的自定义Application，咱们在MyApplication的构造方法当中获取了当前应用程序的包名，并打印出来。获取包名使用了getPackageName()方法，这个方法就是由Context提供的。那么上面的代码能正常运行吗？跑一下就知道了，你将会看到以下所示的结果：




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

  

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


以上是咱们平时在使用Application时须要注意的一个点，下面再来介绍另一种很是广泛的Application误用状况。


其实Android官方并不太推荐咱们使用自定义的Application，基本上只有须要作一些全局初始化的时候可能才须要用到自定义Application，官方文档描述以下：


可是就个人观察而言，如今自定义Application的使用状况基本上能够达到100%了，也就是咱们平时本身写测试demo的时候可能不会使用，正式的项目几乎所有都会使用自定义Application。但是使用归使用，有很多项目对自定义Application的用法并不到位，正如官方文档中所表述的同样，多数项目只是把自定义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;
        }
        
    }


就像单例模式同样，这里提供了一个getInstance()方法，用于获取MyApplication的实例，有了这个实例以后，就能够调用MyApplication中的各类工具方法了。


可是这种写法对吗？这种写法是大错特错！由于咱们知道Application是属于系统组件，系统组件的实例是要由系统来去建立的，若是这里咱们本身去new一个MyApplication的实例，它就只是一个普通的Java对象而已，而不具有任何Context的能力。有不少人向我反馈使用 LitePal 时发生了空指针错误其实都是因为这个缘由，由于你提供给LitePal的只是一个普通的Java对象，它没法经过这个对象来进行Context操做。


那么若是真的想要提供一个获取MyApplication实例的方法，比较标准的写法又是什么样的呢？其实这里咱们只需谨记一点，Application全局只有一个，它自己就已是单例了，无需再用单例模式去为它作多重实例保护了，代码以下所示：

    public class MyApplication extends Application {
        
        private static MyApplication app;
        
        public static MyApplication getInstance() {
            return app;
        }
        
        @Override
        public void onCreate() {
            super.onCreate();
            app = this;
        }
        
    }

getInstance()方法能够照常提供，可是里面不要作任何逻辑判断，直接返回app对象就能够了，而app对象又是什么呢？在onCreate()方法中咱们将app对象赋值成this，this就是当前Application的实例，那么app也就是当前Application的实例了。好了，关于Context的介绍就到这里吧，内容仍是比较简单易懂的，但愿你们经过这篇文章能够理解Context更多的细节，而且不要去犯使用Context时的一些低级错误。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程