context_contextmenu - CSDN
精华内容
参与话题
  • Context是什么

    万次阅读 2019-11-13 14:38:51
    1.Context是什么 相信很多人多会问Context到底是什么? 我们可以理解为“上下文”:它贯穿整个应用; 也可以理解成“运行环境”:它提供了一个应用运行所需要的信息,资源,系统服务等; 同样可以理解成“场景”...

    1.Context是什么

    相信很多人多会问Context到底是什么?

    • 我们可以理解为“上下文”:它贯穿整个应用;
    • 也可以理解成“运行环境”:它提供了一个应用运行所需要的信息,资源,系统服务等;
    • 同样可以理解成“场景”:用户操作和系统交互这一过程就是一个场景,比如Activity之间的切换,服务的启动等都少不了Context。

    然而以上这些都是我们从抽象角度去理解Context的作用,那么从Code代码来看Context到底是什么呢?Activity是一个Context,Application是一个Context,Service也是一个Context你信么?不信的话,同样还是那句话“look the fuck resource code”。

    public abstract class Context {
    ..............................
     /** Return an AssetManager instance for your application's package. */
        public abstract AssetManager getAssets();
    
        /** Return a Resources instance for your application's package. */
        public abstract Resources getResources();
    
        /** Return PackageManager instance to find global package information. */
        public abstract PackageManager getPackageManager();
    
        /** Return a ContentResolver instance for your application's package. */
        public abstract ContentResolver getContentResolver();
    
    ...................
    //获取系统服务
    public abstract Object getSystemService(@ServiceName @NonNull String name);
    //发送广播
    public abstract void sendBroadcast(Intent intent);
    //启动Activity
    public abstract void startActivity(Intent intent);
    //启动服务,绑定服务
    public abstract ComponentName startService(Intent service);
    public abstract boolean bindService(Intent service, @NonNull ServiceConnection conn,
                @BindServiceFlags int flags);
    
    ................
    }
    •  

    从源码看Context就是一个抽象类,里面定义了各种抽象方法,包括获取系统资源,获取系统服务,发送广播,启动Activity,Service等。所以从源码角度看Context就是抽象出一个App应用所有功能的集合,由于Context是一个纯的抽象类,所以它的具体的方法实现是在其之类ContextImpl中实现了,稍后分析。我们平时在MainActivity中会这么给mContext = this赋值,其言外之意就是当前Activity类就是Context,那说明Activity是Context的子类。通过Android Studio查看Context的子类图如下:

    这里写图片描述

    有图可知,Context的子类很多,我们主要分析以上红色矩形框内的即可。接下来就分析Android系统中Context的继承关系!

    2.Android系统中Context的继承关系

    有上一节我们知道,Activity是一个Context,Service也是一个Context等等,那么这些类跟Context具体什么关系呢?接下来有一幅图Context继承关系图来说明: 
    这里写图片描述 
    Context类是一个抽象类,具体实现在ContextImpl类中;而ContextWrapper是Context的一个包装类,其里面所有的方法实现都是调用其内部mBase变量的方法,而mBase就是ContextImpl对象,稍后分析。然而ContextWrapper还有一个ContextThemeWrapper子类,该类中扩展了主题相关的方法。有继承关系图可以看出,Application和Service是继承自ContextWrapper,而Activity是继承自ContextThemeWrapper,是不是有点奇怪?其实一点都不奇怪,Activity在启动的时候系统都会加载一个主题,也就是我们平时在AndroidManifest.xml文件里面写的android:theme=”@style/AppTheme”属性啦!然而Service和Applicaton都和UI界面并没有卵关系!因此他们继承自ContextWrapper。所以Activity,Application,Service其实都关联着一个mBase变量,而mBase变量是ContextImpl对象的赋值,也是真正实现抽象类Context的地方。虽然Activity,Application,Service都有一个共同的祖先Context,但是他们自己本身持有的Context对象是不同的,接下来我们从源码角度分析以上几个类的实现。

    3.不同Context源码分析

    3.1ContextImpl—真正实现Context功能的类

    从源码看出Context类仅仅是定义了一组抽象方法的抽象类,其内部的方法真正实现的地方都在ContextImpl类中。class ContextImpl extends Context {

        //整个App的主线程
        final ActivityThread mMainThread;
        //整个App的相关信息
        final LoadedApk mPackageInfo;
        //资源解析器
        private final ResourcesManager mResourcesManager;
        //App资源类
        private final Resources mResources;
        //外部Context的引用
        private Context mOuterContext;
        //默认主题
        private int mThemeResource = 0;
        private Resources.Theme mTheme = null;
        //包管理器
        private PackageManager mPackageManager;
    
        ................................
    //以下是静态区注册系统的各种服务,多大五六十种系统服务,因此每个持有Context引用的对象都可以随时通过getSystemService方法来轻松获取系统服务。
    static {
            registerService(ACCESSIBILITY_SERVICE, new ServiceFetcher() {
                    public Object getService(ContextImpl ctx) {
                        return AccessibilityManager.getInstance(ctx);
                    }});
    
            registerService(CAPTIONING_SERVICE, new ServiceFetcher() {
                    public Object getService(ContextImpl ctx) {
                        return new CaptioningManager(ctx);
                    }});
    
            registerService(ACCOUNT_SERVICE, new ServiceFetcher() {
                    public Object createService(ContextImpl ctx) {
                        IBinder b = ServiceManager.getService(ACCOUNT_SERVICE);
                        IAccountManager service = IAccountManager.Stub.asInterface(b);
                        return new AccountManager(ctx, service);
                    }});
            ........................
    
           }
    
    .................
    //启动Activity的地方
     @Override
        public void startActivity(Intent intent, Bundle options) {
            warnIfCallingFromSystemProcess();
            if ((intent.getFlags()&Intent.FLAG_ACTIVITY_NEW_TASK) == 0) {
                throw new AndroidRuntimeException(
                        "Calling startActivity() from outside of an Activity "
                        + " context requires the FLAG_ACTIVITY_NEW_TASK flag."
                        + " Is this really what you want?");
            }
            mMainThread.getInstrumentation().execStartActivity(
                getOuterContext(), mMainThread.getApplicationThread(), null,
                (Activity)null, intent, -1, options);
        }
    
    ..........
    //启动服务的地方
    @Override
        public ComponentName startService(Intent service) {
            warnIfCallingFromSystemProcess();
            return startServiceCommon(service, mUser);
        }
    ...............     
    }

    分析:ContextImpl实现了抽象类Context里面的所有方法,获取资源,启动Activity,Service等。值得注意的是在ContextImpl创建的时候就会利用静态区来注册系统的各种服务,因此每个持有Context引用的类都可以通过getSystemService来轻松的获取系统服务了。比如我们平时LayoutInflater类来加载一个XML布局时时这么写的LayoutInflater inflater = LayoutInflater.from(mContext);

    View layout = inflater.inflate(R.layout.activity_main,null);

    其实源码内部是这样实现的:

     /**
         * Obtains the LayoutInflater from the given context.
         */
        public static LayoutInflater from(Context context) {
            LayoutInflater LayoutInflater =
                    (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
            if (LayoutInflater == null) {
                throw new AssertionError("LayoutInflater not found.");
            }
            return LayoutInflater;
        }

     

    可以看出LayoutInflater布局加载器也是调用context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);来获取系统服务得到的。因此我们以后在代码中也可以这么来加载一个XML布局:

     //获取服务
    LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
    View layout = inflater.inflate(R.layout.activity_main,null);

    由于ContextImpl是抽象类Context的具体实现,而Application,Activity,Service的祖先又都是Context类,那么它们都关联着一个ContextImpl对象来真正实现Context里面所有的方法。现在来分析下不同子类创建的Context对象。

    3.2ContextWrapper

    public class ContextWrapper extends Context {
        Context mBase;
    
        public ContextWrapper(Context base) {
            mBase = base;
        }
    
        /**
         * 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 PackageManager getPackageManager() {
            return mBase.getPackageManager();
        }
    ...............
    }

     

    分析:从ContextWrapper源码可以看到,这个类只是一个装饰类,其内部所有方法的实现都指向mBase成员变量,而然谁给mBase成员变量赋值呢?结论是Context的真正实现类ContextImpl对象,后面会分析到。该类中通过attachBaseContext方法将ContextImpl对象赋值给mBase成员变量。

    每一个App应用都是由ASM通过Binder机制创建一个新的进程然后调用ActivityThread类中的main方法开始的。很多人可能会感到奇怪为啥Android也是基于Java实现的,为啥没有看到main方法呢?其实整个App应用的入口在ActivityThread.main方法里面啦!关于Activity启动过程请参考大神级别人物老罗的这篇博客:Android应用程序的Activity启动过程简要介绍和学习计划。所有有关Application,Activity,Service的创建都是在ActivityThread类中,其实该类就是我们App的主线程。

    3.3Application中的Context

    每一个应用在启动的时候都会创建一个Application对象,该对象是全局的,开发者可以实现一个子类MyApplication类来继承Application,然后实现一些全局的方法或者数据。

    应用入口ActivityThread#main

     public static void main(String[] args) {
            ................
            //初始化Looper
            Looper.prepareMainLooper();
            //创建一个APP主线程ActivityThread对象
            ActivityThread thread = new ActivityThread();
            //初始化App应用信息
            thread.attach(false);
            //获得主线程也就是UI线程的handler对象
            if (sMainThreadHandler == null) {
                sMainThreadHandler = thread.getHandler();
            }
            //此处值得注意了,在Android4.1版本之后添加了这么一个方法,目的就是为了能让AsyncTask能在子线程创建,
            //在之前的版本是不能在子线程中创建初始化AsyncTask的。
            //对AsyncTask感兴趣的童鞋可以参考这篇博客[ Android异步任务处理框架AsyncTask源码分析](http://blog.csdn.net/feiduclear_up/article/details/46860015)
            AsyncTask.init();
            //启动Looper循环,进入消息循环。
            Looper.loop();
        }

     

    分析:main方法主要工作就是创建一个App应用的主线程ActivityThread并初始化,且构建一个消息循环机制用于处理UI交互。代码第6-8行,创建了一个应用的主线程ActivityThread并且调用attach方法来初始化。进入attach方法: 
    ActivityThread#attach

    private void attach(boolean system) {
        //整个应用的Application对象
        Application mInitialApplication;
        //整个应用的后台管家
        Instrumentation mInstrumentation;
            ................
                try {
                    mInstrumentation = new Instrumentation();
                    ContextImpl context = ContextImpl.createAppContext(
                            this, getSystemContext().mPackageInfo);
                    //利用ContextImpl创建整个应用的Application对象
                    mInitialApplication = context.mPackageInfo.makeApplication(true, null);
                    //调用Application对象的onCreate方法
                    mInitialApplication.onCreate();
                } 
           ................
        }

     

    代码第13行:通过调用LoadedApk#makeApplication方法创建应用程序的Application对象。 
    LoadedApk#makeApplication

     public Application makeApplication(boolean forceDefaultAppClass,
                Instrumentation instrumentation) {
            //第一次进来mApplication==null条件不满足,之后创建Activity的时候条件满足直接返回当前Application对象
            if (mApplication != null) {
                return mApplication;
            }
    
            Application app = null;
    
            try {
    
                //为Appliaction创建ContextImpl对象
                ContextImpl appContext = ContextImpl.createAppContext(mActivityThread, this);
                //调用Instrumentation类中的newApplication方法创建Application
                app = mActivityThread.mInstrumentation.newApplication(
                        cl, appClass, appContext);
                //给ContextImpl设置外部引用
                appContext.setOuterContext(app);
            } 
          ....................
            return app;
        }
    • 分析: 

    1.代码第4-6行:判断当前应用是否是第一次创建Application对象,如果不是则直接返回Application对象,否则去创建第一个Application对象。目的是确保当前应用之创建了一个全局的Application对象。 
    2.代码第13行:创建了一个ContextImpl对象,然后作为参数用于创建Application对象。 
    3.代码第15行:调用Instrumentation类中的newApplication方法来创建Application对象。 
    4.代码第18行:将创建好的Application对象赋值给ContextImpl类的mOuterContext成员变量,目的是让ContextImpl持有外部Application类的引用用于注册系统服务或者其他方法。

    Instrumentation#newApplication

    public Application newApplication(ClassLoader cl, String className, Context context)
                throws InstantiationException, IllegalAccessException, 
                ClassNotFoundException {
            return newApplication(cl.loadClass(className), context);
        }
    
        static public Application newApplication(Class<?> clazz, Context context)
                throws InstantiationException, IllegalAccessException, 
                ClassNotFoundException {
            Application app = (Application)clazz.newInstance();
            app.attach(context);
            return app;
        }

     

    分析:以上代码通过类加载器来创建Application对象,并且调用app.attach(context)方法来初始化Application对象。这里的context就是上面传下来的ContextImpl对象了。进入Application源码 
    Application#attach

    public class Application extends ContextWrapper implements ComponentCallbacks2 {
    ..................
    /**
         * @hide
         */
        /* package */ final void attach(Context context) {
            attachBaseContext(context);
            mLoadedApk = ContextImpl.getImpl(context).mPackageInfo;
        }
    ...............
    }

     

    分析:Application类是继承自ContextWrapper类,在attach方法中调父类也就是ContextWrapper中的attachBaseContext方法来对ContextWrapper的成员变量mBase赋值成ContextImpl对象,具体可以参考3.2小节。因此Application通过父类ContextWrapper类的成员变量mBase指向了ContextImpl,让Application类真正实现了其祖父类Context抽象类中的所有抽象方法。

    3.4Activity中的Context

    当Application创建完成之后,ASM会通过Binder机制通知ActivityThread去创建需要的Activity了。最后会辗转到ActivityThread类中的performLaunchActivity方法来创建Activity。

    ActivityThread#performLaunchActivity

    private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
            ........................
    
            Activity activity = null;
            try {
            //通过Instrumentation类的newActivity方法来创建一个Activity对象
                java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
                activity = mInstrumentation.newActivity(
                        cl, component.getClassName(), r.intent);
               ..........................
            }
            try {
                //获取当前应用的Application对象,该对象的唯一作用就是作为参数传递到Activity里,
                然后在Activity类中可以获得调用getApplication方法来获取Application对象
                Application app = r.packageInfo.makeApplication(false, mInstrumentation);
    
              .............................
                if (activity != null) {
                    //为Activity创建ContextImpl对象
                    Context appContext = createBaseContextForActivity(r, activity);
                    //为Activity赋值初始化
                     activity.attach(appContext, this, getInstrumentation(), r.token,
                            r.ident, app, r.intent, r.activityInfo, title, r.parent,
                            r.embeddedID, r.lastNonConfigurationInstances, config,
                            r.voiceInteractor);
                   ...................
                    //获取当前应用的主题资源
                    int theme = r.activityInfo.getThemeResource();
                    if (theme != 0) {
                    //设置主题
                        activity.setTheme(theme);
                    }
    
                    activity.mCalled = false;
                    if (r.isPersistable()) {
                    //辗转到Activity,调用Activity的生命周期onCreate方法
                        mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
                    } else {
                        mInstrumentation.callActivityOnCreate(activity, r.state);
                    }
                    .............
                    r.activity = activity;
                    r.stopped = true;
                    if (!r.activity.mFinished) {
                    //调用Activity的生命周期onStart方法
                        activity.performStart();
                        r.stopped = false;
                    }
                    ......................
    
            return activity;
        }

    分析:

    1. step1 这里也是通过Instrumentation类的newActivity方法来创建一个Activity对象,跟上面创建Application对象基本类似,这里就不贴源码了。
    2. step2 之后在调用本地方法 createBaseContextForActivity去创建ContextImpl对象,该对象将作为参数传递到Activity#attach方法中。
    3. step3 调用Activity#attach方法对刚创建好的Activity进行初始化操作。后面会分析Activity#attach方法。
    4. step4 获取当前应用的主题资源,然后调用Activity#setTheme方法给刚创建好的Activity对象设置主题。
    5. setp5 一次调用Activity的生命周期方法onCreate,onStart。

    step2 
    现在来分析下ActivityThread#createBaseContextForActivity方法。

    ActivityThread#createBaseContextForActivity

    private Context createBaseContextForActivity(ActivityClientRecord r,
                final Activity activity) {
            ContextImpl appContext = ContextImpl.createActivityContext(this, r.packageInfo, r.token);
            appContext.setOuterContext(activity);
            Context baseContext = appContext;
       .............
       return baseContext;
    }

     

    分析:该方法里面的确创建了一个ContextImpl对象,并且返回该对象。同时也调用了ContextImpl#setOuterConexet方法让ContextImpl持有外部Activity对象的引用,目的是在ContextImpl类中注册一些服务,设置主题等都需要外部Activity对象的引用。

    setp3 
    由于Activity没有重写构造方法,因此创建出来的Activity并没有初始化。为了对Activity初始化,以上代码调用了Activity#attach方法来进行初始化操作。

    Activity#attach

    public class Activity extends ContextThemeWrapper
            implements LayoutInflater.Factory2,
            Window.Callback, KeyEvent.Callback,
            OnCreateContextMenuListener, ComponentCallbacks2,
            Window.OnWindowDismissedCallback {
    
    ............................
    
    final void attach(Context context, ActivityThread aThread,
                Instrumentation instr, IBinder token, int ident,
                Application application, Intent intent, ActivityInfo info,
                CharSequence title, Activity parent, String id,
                NonConfigurationInstances lastNonConfigurationInstances,
                Configuration config, IVoiceInteractor voiceInteractor) {
            //调用父类方法对mBase变量赋值
            attachBaseContext(context);
            //创建一个Activity的窗口
            mWindow = PolicyManager.makeNewWindow(this);
            //给Window窗口设置回调事件
            mWindow.setCallback(this);
            mWindow.setOnWindowDismissedCallback(this);
            mWindow.getLayoutInflater().setPrivateFactory(this);
            //设置键盘弹出状态
            if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
                mWindow.setSoftInputMode(info.softInputMode);
            }
            if (info.uiOptions != 0) {
                mWindow.setUiOptions(info.uiOptions);
            }
            mUiThread = Thread.currentThread();
    
            mMainThread = aThread;
            mInstrumentation = instr;
            mToken = token;
            mIdent = ident;
            //此处注意,将整个应用的Application对象赋值给Activity的mApplication成员变量。
            //目的是为了能在Activity中通过getApplication方法来直接获取Application对象
            mApplication = application;
           ......................
        }
        //在Activity中返回当前应用的Application对象
    /** Return the application that owns this activity. */
        public final Application getApplication() {
            return mApplication;
        }
    
    .......................

     

    分析:attach方法一进来就调用了父类的attachBaseContext方法将ContextImpl对象注册到Activity里面去。由于Activity的父类是ContextThemeWrapper,进入该类查看attachBaseContext方法

    ContextThemeWrapper#attachBaseContext

    public class ContextThemeWrapper extends ContextWrapper {
       ............
    
        @Override protected void attachBaseContext(Context newBase) {
            super.attachBaseContext(newBase);
        }
        ...........

     

    该方法也很简单,还是调用父类的attachBaseContext方法注册ContextImpl,然而该类的父类就是ContextWrapper类。 
    ContextWrapper#attachBaseContext

    public class ContextWrapper extends Context {
    ..............
     protected void attachBaseContext(Context base) {
            if (mBase != null) {
                throw new IllegalStateException("Base context already set");
            }
            mBase = base;
        }
    ..........
    }

     

    在ContextWrapper类中调用attachBaseContext方法将ContextImpl对象(真正实现Context抽象类里面各种方法的类)赋值给mBase成员变量,而ContextWrapper只是一个装饰类,里面所有方法的实现都是调用mBase的方法。此时mBase方法被赋值成ContextImpl对象,这么一来Activity的祖父类就实现了里面的所有Context抽象方法,那么在Activity中可以调用Context里面的任何方法了。

    3.5 Service中的Context

    同样创建Service也是有ASM通过Binder机制通知ActivityThread类去创建一个Service服务了,最后会辗转到ActivityThread#handleCreateService方法中来创建一个Service服务。

    ActivityThread#handleCreateService

    private void handleCreateService(CreateServiceData data) {
    
            LoadedApk packageInfo = getPackageInfoNoCheck(
                    data.info.applicationInfo, data.compatInfo);
            Service service = null;
            try {
                //通过类加载器创建Service服务
                java.lang.ClassLoader cl = packageInfo.getClassLoader();
                service = (Service) cl.loadClass(data.info.name).newInstance();
            } 
        .............
            try {
              ............
              //此处为Service创建一个ContextImpl对象
                ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
                //同样为ContextImpl类设置外部对象,目的还是让ContextImpl持有外部类的引用
                //在ContextImpl类中的许多方法需要使用到外部Context对象引用
                context.setOuterContext(service);
        ................
                //获得当前应用的Applicaton对象,该对象在整个应用中只有一份,是共享的。
                Application app = packageInfo.makeApplication(false, mInstrumentation);
                //将ContextImpl对象和Application对象作为attach方法参数来初始化Service
                service.attach(context, this, data.info.name, data.token, app,
                        ActivityManagerNative.getDefault());
                //Service初始化完成之后系统自动调用onCreate生命周期方法
                service.onCreate();
         ................
        }

     

    分析: 
    跟以上Activity和Application创建类似,通过类加载器来创建Service对象。然后在创建一个ContextImpl对象,并且为ContextImpl类设置外部Service对象Context的引用,目的之在ContextImpl类中的许多方法都需要使用到外部Context引用。

    其次和Activity一样调用packageInfo.makeApplication方法去获得当前应用的Application对象,然后将Application对象和ContextImpl对象作为Service#attach方法去初始化Service,当Service初始化完成之后,系统调用Service的生命周期方法onCreate方法,该方法是创建Service过程中最早暴露给开发者的,所有开发者在实现自己的Service时可以重写onCreate方法来进行一些初始化工作。

    现在我们来分析下Service#attach方法

    Service#attach

    public abstract class Service extends ContextWrapper implements ComponentCallbacks2 {
        //默认构造方法调用父类构造方法并且参数为null,意味着构造方法里并没有对Service初始化
        public Service() {
            super(null);
        }
    
    //在Service中返回整个应用的Application对象
        /** Return the application that owns this service. */
        public final Application getApplication() {
            return mApplication;
        }
        ..............
     /**
         * @hide
         */
        public final void attach(
                Context context,
                ActivityThread thread, String className, IBinder token,
                Application application, Object activityManager) {
            //调用父类方法去注册ContextImpl对象
            attachBaseContext(context);
            mThread = thread;           // NOTE:  unused - remove?
            mClassName = className;
            mToken = token;
            //将整个应用的Applicaton对象赋值给Service类的成员变量mApplication
            mApplication = application;
            mActivityManager = (IActivityManager)activityManager;
    
        }
    

     

    分析: 
    Service的父类是ContextWrapper,在attach方法中调用了父类中attachBaseContext方法去注册CotextImpl对象,这一操作和创建Application一样,具体参考前面分析。

    3.6总结

    至此,一个Android应用可能创建Context的地方基本分析结束。所有有关创建Context对象的地方都是在ActivityThread类中,该类就是整个应用的入口,也是整个应用的主线程。每个应用首先会创建一个Application对象,且一个应用只有唯一一个Application对象,之后再根据需求创建Activity或者Service。且在创建Activity或者Service的时候都会持有一份当前应用的Application对象,通过getApplication方法即可获得。

    不管在创建Application,Activity还是Service的时候都会去创建一个ContextImpl对象(真正实现抽象类Context功能的类就是ContextImpl),然后将该对象注册到对应的Application,Activity,Service中,之后在Application,Activity,Service类中就可以使用Context的所有功能了。所以Application,Activity,Service的祖先都是抽象类Context,相当于Context给了他们身体,让他们有了一个躯壳有思想,但真正让他们思想得到执行的类还是ContextImpl类。因此我们可以这么来理解:抽象类Context给了Application,Activity,Service思想,而ContextImpl类给了他们去执行思想的功能。

    有以上分析我们知道,每创建一个Application,Activity还是Service都会创建一个ContextImpl类(真正实现Context类功能)。且一个应用只会创建一个Application对象。因此:一个App中Context的个数=1个Application+Activity的个数+Service的个数。

    【转载请注明出处:http://blog.csdn.net/feiduclear_up CSDN 废墟的树】

    4.Context应用场景

    虽然Application,Activity,Service的祖先都是Context,并不是每个Context对象都是相同的。

    • Application:一个应用在创建的时候只会创建一个ActivityThread主线程,而在初始化ActivityThread主线程的时候就会创建一个Application对象。Application是全局的,在Activity和Service里都可以调用getApplication方法来获得一个应用的Application对象。Application的父类是ContextWrapper类。
    • **Service:**Service父类是ContextWrapper,一个应用每创建一个Service,都会创建一个ContextImpl类去关联Service。
    • **Activity:**Activity父类是ContextThemeWrapper,而ContextThemeWrapper父类是ContextWrapper。ContextThemeWrapper类是其父类的扩张,里面额外添加了关于主题设置的一些方法。在ActivityThread主线程中创建Activity的时候我们知道,创建完了Activity之后会立马调用Activity#setTheme设置Activity的主题。

    不同Context的应用场景如下图标

    功能 Application Service Activity
    Start an Activity NO1 NO1 YES
    Show a Dialog NO NO YES
    Layout Inflation YES YES YES
    Start a Service YES YES YES
    Bind to a Service YES YES YES
    Send a Broadcast YES YES YES
    Register BroadcastReceiver YES YES YES
    Load Resource Values YES YES YES

    解释:

    • NO1表示Application和Service可以启动一个Activity,但是需要创建一个新的task。比如你在Application中调用startActivity(intent)时系统会报如下错误:
    java.lang.RuntimeException: Unable to create application 
    com.xjp.toucheventdemo.MyApplication: android.util.AndroidRuntimeException: Calling 
    startActivity() from outside of an Activity  context requires the FLAG_ACTIVITY_NEW_TASK 
    flag. Is this really what you want?

     

    意思就是当在Activity以外的环境启动一个新的Activity的时候需要给Intent添加一个FLAG_ACTIVITY_NEW_TASK标记,该标记的作用就是为当前需要启动的Activity创建一个新的task任务队列。

    • 除了Activity可以创建一个Dialog,其他都不可以创建Dialog。比如在Application中创建Dialog会报如下错误:
    Caused by: java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.

     

    原因是因为在创建Dialog的时候会使用到Context对象去获取当前主题信息,但是我们知道Application和Service是继承自ContextWrapper,没有实现关于主题的功能,然而Activity是继承自ContextThemeWrapper,该类是实现了关于主题功能的,因此创建Dialog的时候必须依附于Activity的Context引用。

    5.getApplication和getApplicationContext区别

    很多人对getApplication方法和getApplicationContext感到疑惑,这两个方法返回值有什么不同?什么场合使用什么样的方法?这里我们从源码角度告诉大家:这两个方法返回值都是指向同一个Application对象,仅仅是返回类型和实现方法的地方不同而已。

    5.1 getApplication

    public class Activity extends ContextThemeWrapper
            implements LayoutInflater.Factory2,
            Window.Callback, KeyEvent.Callback,
            OnCreateContextMenuListener, ComponentCallbacks2,
            Window.OnWindowDismissedCallback {
    ..............
    /** Return the application that owns this activity. */
        public final Application getApplication() {
            return mApplication;
        }
    ...........

     

    getApplication方法实现是在Activity类中,且返回值是当前应用的Application对象。该对象是在ActivityThread类创建Activity时传递下来的。具体可以参考3.4小节。

    5.2 getApplicationContext

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

     

    getApplicationContext方法是在ContextWrapper类中实现,由于mBase变量指向的是ContextImpl对象,因此真正实现的地方是ContextImpl类中

    class ContextImpl extends Context {
    ................
     @Override
        public Context getApplicationContext() {
            return (mPackageInfo != null) ?
                    mPackageInfo.getApplication() : mMainThread.getApplication();
        }
    ..........
    }

     

    该方法返回的是Context类型,且返回值也是调用mPackageInfo.getApplication()或者mMainThread.getApplication()。

    public final class LoadedApk {
    ............
    Application getApplication() {
            return mApplication;
        }
    ..........
    }

     

    可以看出返回的是当前应用的Application对象,由于一个应用只有一份LoadedApk对象,此处返回的也是系统的唯一Application对象。

    public final class ActivityThread {
    .................
    public Application getApplication() {
            return mInitialApplication;
        }
    ................
    }

     

    可以看出返回值也是当前应用的Application对象,由于一个应用只有一个主线程,此处返回的也是系统的唯一Application对象。

    因此:getApplication和getApplicationContext方法返回的对象都是指向当前应用的Application对象,是同一个Application对象,仅仅是返回值类型不同而已。

    查看源码会发现getApplication方法是在Activity,Service类中实现的;而getApplicationContext方法是在ContextWrapper类中实现的。也就是getApplication方法是在Context子类中实现的,而getApplicationContext是在父类中实现的,从而导致两个方法的使用范围是不一样的。你可以这么调用

    context.getApplicationContext(); 

     

    但是却不可以这么调用

    context.getApplication();

     

    因为getApplication方法是Context子类中实现的,所以你必须这样调用

    ((Activity)context).getApplication();

     

    6.Context内存泄漏问题

    在项目中,我们经常会遇到使用单例模式或者静态static变量,虽然使用静态类或者静态变量很方便,但是也潜在很多的内存泄漏问题。

    6.1静态资源导致的内存泄漏

    你可能遇到以下这段代码:

    public class MyCustomResource {
        //静态变量drawable
        private static Drawable drawable;
        private View view;
    
        public MyCustomResource(Context context) {
            Resources resources = context.getResources();
            drawable = resources.getDrawable(R.drawable.ic_launcher);
            view = new View(context);
            view.setBackgroundDrawable(drawable);
        }
    }

     

    请问,这段代码有什么问题?乍一看貌似没啥问题,挺好的啊!其实不然,主要的问题在于view.setBackgroundDrawable方法里面,我们知道静态变量在整个应用的内存里只保存一份,一旦创建就不会释放该变量的内存,直到整个应用都销毁才会释放static静态变量的内存。

    public class View implements Drawable.Callback, KeyEvent.Callback,
            AccessibilityEventSource {
        ...........
        public void setBackgroundDrawable(Drawable background) {
             ..........
             /**此处的this就是当前View对象,而View对象又是有Context对象获得
             因此,变量background持有View对象的引用,View持有Context的引用,
             所有background间接持有Context对象的引用了*/
             background.setCallback(this);
             .......
        }
        ..........
    }

     

    setBackgroundDrawable方法内部调用了background.setCallback(this)回调方法,而该参数this就是View的对象,由于background是一个静态变量,会一直持有View对象的引用,而然View对象又是由Context对象创建出来的,因此background会间接持有Context的对象的引用,也就意味着如果该Context对应的Activity退出finish掉的时候其实该Activity是不能完全释放内存的,因为静态变量drawable持有该Activity的Context对象的间接引用。从而导致该Activity内存无法回收,导致内存泄漏隐患。因为Activity就是Context,所有Context的生命周期和Activity是一样长的,我们希望Activity退出时Context也释放内存,这样才不会导致内存泄漏隐患。那么以上这段代码是不安全的。值得注意的是:以上代码是由于静态资源drawable持有View对象的引用导致内存泄漏隐患的,并不是由于context.getResource导致内存泄漏,因此如果你想通过context.getApplicaitonContext来获取getResource是解决不了内存泄漏的。因此,Android系统在在3.0版本之后修改了setBackgroundDrawable内部方法中的 background.setCallback(this);方法,里面的实现使用了弱引用来持有View对象的引用,从而避免了内存泄漏隐患。所以,以后代码中避免使用静态资源,或者使用弱引用来解决相应的问题也是可以的。

    6.2 单例模式导致内存泄漏

    相信单例模式对开发者很有诱惑力吧!或多或少在项目中都有用过单例模式。你也可能见过一下这段代码:

    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对象的引用,如果你是在Application中创建以上单例的话是木有任何问题的。因为Application的Context生命周期是整个应用,和单例的生命周期一样,因此不会导致内存泄漏。但是,如果你是在Activity中创建以上单例的话,就会导致和6.1小节一样的问题—内存泄漏。所以我们同样可以将代码修改成如下:

    public class CustomManager {
        private static CustomManager sInstance;
        public static CustomManager getInstance(Context context) {
            if (sInstance == null) {
                sInstance = new CustomManager(context.getApplicationContext());
            }
            return sInstance;
        }
    
        private Context mContext;
        private CustomManager(Context context) {
            mContext = context;
        }
    }

     

    6.3 总结

    以后在使用Context对象获取静态资源,创建单例对象或者静态方法的时候,请多考虑Context的生命周期,一定要记得不要使用Activity的Context,切记要使用生命周期长的Application的Context对象。但是并不是所有情况使用Application的Context对象,比如第4小节,在创建Dialog,View控件的时候都必须使用Activity的Context对象。

    Context总结

    1. Context是什么?Context是”运行上下文环境“,从代码角度看Application,Service,Activity都是Context。
    2. 所有Context都是在应用的主线程ActivityThread中创建的,由于Application,Service,Activity的祖先都是Context抽象类,所以在创建它们的同时也会为每一个类创建一个ContextImpl类,ContextImpl是Context的之类,真正实现Context功能方法的类。因此Application,Service,Activity都关联着一个ContextImpl对象。
    3. 尽量少用Context对象去获取静态变量,静态方法,以及单例对象。以免导致内存泄漏。
    4. 在创建与UI相关的地方,比如创建一个Dialog,或者在代码中创建一个TextView,都用Activity的Context去创建。然而在引用静态资源,创建静态方法,单例模式等情况下,使用生命周期更长的Application的Context才不会导致内存泄漏。

    展开全文
  • Context相信所有的Android开发人员基本上每天都在接触,因为它太常见了。但是这并不代表Context没有什么东西好讲的,实际上Context有太多小的细节并不被大家所关注,那么今天我们就来学习一下那些你所不知道的细节。...

    转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/47028975


    前几篇文章,我也是费劲心思写了一个ListView系列的三部曲,虽然在内容上可以说是绝对的精华,但是很多朋友都表示看不懂。好吧,这个系列不仅是把大家给难倒了,也确实是把我给难倒了,之前为了写瀑布流ListView的Demo就写了大半个月的时间。那么本篇文章我们就讲点轻松的东西,不去分析那么复杂的源码了,而是来谈一谈大家都熟知的Context。


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


    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理解的还有些欠缺。那么这里我们先来对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()方法就能拿到我们自定义的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()方法了,如下所示:

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

    这是一个非常简单的自定义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时的一些低级错误。


    关注我的技术公众号,每天都有优质技术文章推送。关注我的娱乐公众号,工作、学习累了的时候放松一下自己。

    微信扫一扫下方二维码即可关注:

            

    展开全文
  • 关于Context(上下文)的理解

    千次阅读 2019-07-01 16:35:39
    感觉对Context这个词翻译的不太好,不应该叫上下文,应该直接就叫“环境”,不过都这么叫,就叫上下文好了 所谓的上下文就是指语境,每一段程序都有很多的外部变量。只有想Add这种简单的函数才是没有外部变量的。...

    一直听到上下文一说,一直没弄清楚到底是啥意思,今天总结一下,不知道对不对

    感觉对Context这个词翻译的不太好,不应该叫上下文,应该直接就叫“环境”,不过都这么叫,就叫上下文好了

    所谓的上下文就是指语境,每一段程序都有很多的外部变量。只有想Add这种简单的函数才是没有外部变量的。一旦写的一段程序中有了外部变量,这段程序就是不完整的,不能独立运行,要想让他运行,就必须把所有的外部变量的值一个一个的全部传进去,这些值的集合就叫上下文

    说的通俗一点就是一段程序的执行需要依赖于外部的一些环境(外部变量等等),如果没有这些外部环境,这段程序是运行不起来的。

    子程序之于程序,进程之于操作系统,甚至app的一屏之于app,都是一个道理

    当程序执行了一部分,要跳转到其他的地方,而跳转到的地方需要之前程序的一些结果(包括但不限于外部变量,外部对象等等)。

    app点击一个按钮进入一个新的界面,也要保存你是在那个屏幕跳过来的等等信息,以便你点击返回的时候能正确跳回

    上面这些都是上下文的典型例子,所以把“上下文”理解为环境就可以了。(而且上下文虽然是上下文,但是程序里面一般都只有上文而已,只是叫的好听叫上下文。进程中断在操作系统中是有上有下的)。

    所以说,通俗一点理解就是,当程序从一个位置调到另一个位置的时候,这个时候就叫上下文的切换(因为他要保存现场,各种的压栈,出栈等等),进程之间切换也叫上下文切换,因为也要保存现场,以便切换回之前的线程

    以我自己的认识水平来说,在C或者C++中,context一般就是一个结构体,用来存储一些关键信息,比如切换上下文时,要保存切换之前的状态和数据,这需要一个结构体来承担,然后将contex中的状态和数据重新赋值为新的,这样就切换了,等运行完了之后,又要切换回来,那么之前保存的那些状态和数据又要重新启用了,就是这么回事。

    我想之所以在多线程网络编程中,现在采用的多是one loop per thread + thread poll,而不是采用一个socket一个线程,就是因为在切换线程(也就是切换上下文)的时候,需要保留大量的现场数据,而在重新切回到该线程时,又要恢复这个保存的数据(即保存的环境),保存/恢复都是需要花费cpu大量的资源和时间的,所以不如one loop per thread + thread poll的模式,当然one loop per thread + thread poll还有其他的好处,这只是其中一个好处,不需要大量的切换上下文,占用cpu大量的资源。

    展开全文
  • 揭秘Context(上下文)

    万次阅读 多人点赞 2020-02-27 16:41:09
    本文主要记述,Context到底是什么、如何理解Context、一个APP可以有几个ContextContext能干啥、Context的作用域、获取Context、全局获取Context技巧。 思考: Java:万物皆对象。Flutter:万物皆组件。 俗语:”没...

    最熟悉的陌生人——Context

    刚刚学android或者js等,都会看见这个频繁的字眼——Context。
    意为”上下文“。

    本文主要记述,Context到底是什么、如何理解Context、一个APP可以有几个Context、Context能干啥、Context的作用域、获取Context、全局获取Context技巧。


    思考:

    Java:万物皆对象。Flutter:万物皆组件。
    俗语:”没对象吗?自己new一个啊~“
    既然大多数情况可以new一个实例,那么,我们在android中的Activity实例怎么获取呢?Activity.instance可以获取activity。既然Activity也大致归属于一个类,那么可不可以用 Activity activity=new Activity(); 呢?安卓不像Java程序一样,随便创建一个类,写个main()方法就能运行,**Android应用模型是基于组件的应用设计模式,组件的运行要有一个完整的Android工程环境。在这个环境下,Activity、Service等系统组件才能正常工作,而这些组件不能采用普通的java对象创建方式,new一下是不能创建实例的,而是要有它们各自的上下文环境,也就是Context.
    所以说,Context是维持android各组件能够正常工作的一个核心功能类。


    what 's Context:

    (本图为沙拉查词给出的中文翻译)
    在这里插入图片描述
    有点晦涩难懂。但在程序中,我们可理解为当前对象在程序中所处的一个环境,一个与系统交互的过程。 比如QQ和你们自己的女朋友聊天时(没有grilfriend的可自己跳过举例),此时的context是指的聊天界面以及相关的数据请求与传输,Context在加载资源、启动Activity、获取系统服务、创建View等操作都要参与。
    所以,一个Activity就是一个Context(getActivity()==getContext),一个Service也是一个Context。Android把场景抽象为Context类,用户和操作系统的每一次交互都是一个场景,比如:打电话、发短信等,都有activity,还有一些我们肉眼看不见的后台服务。一个应用程序可以认为是一个工作环境,用户在这个环境中切换到不同的场景,这就像服务员,客户可能是外卖小哥、也可能是农民工等,这些就是不同的场景,而服务员就是一个应用程序。


    How to understand the ‘Context’:

    Context理解为”上下文“/”场景“,可能还是很抽象。那么我们可以做一个比喻:
    一个APP是仙剑奇侠传3电视剧,Activity、Service、BroadcastReceiver、ContentProvider这四大组件就是电视剧的主角。它们是导演(系统)一开始就确定好试镜成功的人。换言之, 不是我们每个人都能被导演认可的。有了演员,就要有镜头啊,这个镜头便是(Context)。通过镜头,我们才能看见帅气 的胡歌。演员们都是在镜头(Context环境)下表演的。那么Button这些组件子类型就是配角,它们没有那么重要,随便一个组件都能参与演出(即随便new 一个实例),但是它们也需要参与镜头,不然一部戏只有主角多没意思,魔尊重楼还是要的,魔尊也要露面(工作在Context环境下),所以可以用代码new Button();或者xml布局定义一个button。

    打开AndroidStudio,输入Context,然后ctrl+鼠标左键追朔其源码(看源码一般都先看注释便于理解):import android.content.Context;

    在这里插入图片描述
    看注释,TMD,是English,那么笔者这里就用小学生英语水平来翻译一哈哈:
    Context提供了关于应用环境全局信息的接口。它是一个abstract类,它的执行被Android系统提供,允许获取以应用为特征的资源和类型,是一个统领一些资源APP环境变量等的上下文。通过它可以获取应用程序的资源和类(包括应用级别操作,如启动Activity,发广播,接收intent等)。abstract会有它的实现类。在源码中,我们可以通过AndroidStudio去查看它的子类,得到以下关系:
    它有2个具体实现子类:ContextImpl、ContextWrapper。

    • 其中,ContextWrapper类,只是一个包装类,其构造函数中必须包含一个Context引用,同时它提供了attachBaseContext()用于给ContextWrapper对象中指定真正的Context对象,调用它的方法都会被转向其所包含的真正的Context对象。
    • ContextThemeWrapper类其内部包含了与主题相关的接口。主题就是清单文件中android:theme为Application或Activity元素指定的主题。(Activity才需要主题,Serviceu不需要,因为服务是没有界面的后台场景,所以服务直接继承ContextWrapper。Application同理。)而Contextlmpl类则是真正实现了Context中的所有函数,应用程序中所调用的各种Context类的方法,其实现均来自这个类。
    • 换言之:Context的2个实现子类分工的,其中ContextImpl是Context的具体是实现类,而ContextWrapper则是Context的包装类。Activity、Application、Service都继承自ContextWrapper(Activity继承自ContextWrapper的子类ContextThemeWrapper),但它们的初始化过程中都会创建ContextImpl对象,由ContextImpl实现Context中的方法。

    How much has Context in a App:

    关键在于对COntext的理解。从上面提到的实现子类可以看出,在APP中,Context的具体实现子类是Acitivity、Service、Applicaiton。所以Context’s number=Activity’s number + Service’s number+1(1个APP只有一个Application)。为啥不是4大组件,上面不是说四大组件也是主角吗?看看BroadcastReceiver和ContentProvider的源码可以知道它们并不是Context的子类,它们持有的Context都是其他地方传递过去的(比如我们发送广播intent中的context就是外部传递过来的),所以不计数它们。


    Context’s method:

    Context哪里会用到它。刚开始了解Android的时候不知道它是个啥玩意儿,但是久了发现有些地方就不得不传这个参数。
    比如Toast、启动Activity、启动Service、发送广播、操作数据库等等都需要传Context参数,具体例子就不说了。详细可以看后文将提到的如何获取它。


    Context’s 作用域:

    不是随便获取一个Context实例就可以的,它的使用有一些规则和限制。因为Context的具体实例是由ContextImpl类去实现的,因此,Activity、Service、Application3种类型的Context都是等价的。但是,需要注意的是,,有些场景,比如启动Activity、弹出Dialog等。为了安全,Android不允许Activity或者Dialog凭空出现,一个Activity的启动肯定是由另一个Activity负责的,也就是以此形成的返回栈(具体可以看看任主席的《Android开发艺术探索》)而Dialog则必须是在一个Activity上弹出(系统Alert类型的Dialog除外),这种情况下, 我们只能用Activity类型的Context,否则报错。

    Context作用域 Application Activity Service
    Show a Dialog No Yes No
    Start an Activity 不推荐 Yes 不推荐
    Layout Inflation 不推荐 Yes 不推荐
    Start a Service Yes Yes Yes
    Send a Broadcast Yes Yes Yes
    Register Broadcast Receiver Yes Yes Yes
    Load Resource Values Yes Yes Yes

    Activity继承自ContextThemeWrapper,而Application和Service继承ContextWrapper,所以ContextThemeWrapper在ContextWrapper的基础上作了一些操作,使得Activity更加厉害。
    关于表格中提到的Application和Service不推荐的2种情况:

    1. 如果用ApplicationContext去启动一个LaunchMode为standard的Activity的时候会报错:androud,util.AndroidRuntimeException:Calling startActivity from outside of an Activity context require the FLAG_ACTIVITY_NEW_TASK flag。Is this really what you want?
      翻译一下,并了解这个FLAG的都知道,此时的非Activity类型的Context并没有所谓的返回栈,因此带启动的Activity就找不到栈。它还给我们明确之处了FLAG的解决办法,这样启动的时候就为它创建一个新的任务栈,而此时Activity是以Single Task模式启动的。所以这种用Application Context启动Activity的方式不推荐,Service同理。
    2. 在Application和Service中去layout inflate也是合法的,但是会使用系统默认的主题样式,如果自定义了某些样式可能不会被使用,所以也不推荐。

    注:和UI相关的,都应该使用Activity Context来处理。其他的一些操作,Service、Activity、Application等实例都是可以的。同时要注意Context的引用持有,防止内存泄漏。可在被销毁的时候,置Context为null。

    How to get the ‘Context’:

    常用4种方法获取Context对象:

    1. View.getContext():返回当前View对象的Context对象。通常是当前正在展示的Activity对象。
    2. Activity,getApplicationContext()[后文会详细介绍这个方法]:获取当前Activity所在应用进程的Context对象,通常我们使用Context对象时,要优先考虑这个全局的进程Context。
    3. ContextWrapper.getBaseContext():用来获取一个ContextWrapper进行装饰之前的Context。实际开发很少用,也不建议使用。
    4. Activity.this:返回当前Activity的实例,如果的UI控件需要使用Activity作为Context对象,但默认的Toast实际上使用的ApplicationContext也可以。
      实现View.OnClick监听方法中,写Toast,不要用this,因为this,在onClick(View view)指的是view对象而不是Activity实例,所以在这个方法中,应该使用”当前的Activity名.this“,这是入门者比较容易混淆的地方。
    • getApplication()和getApplicationContext():
      获取当前Application对象用getApplicationContext.但是getApplication又是什么。
      我们可以自己写代码打印一下:
    Application app=(Application)getApplication();
    Log.e(TAG,"getApplication is "+app);
    Context context=getApplicationContext();
    Log.e(TAG,"getApplicationContext is "+ context);
    

    运行后看logcat,效果图就不贴了(电脑卡)。从打印结果可以看出它们2个的内存地址是相同的,即它们是同一个对象。 因为Application本来就是一个Context,那么这里获取的getApplicationContext()自然也是Application本身的实例了。那这2个相同方法存在的意义是啥?(双胞胎?)实际上这2个方法在作用域上有比较大的区别。 getApplication()一看就知道是用来获取Application实例的(道理可以联想getActivity())。但getApplication()只有在Activity和Service中才能调用的到。 对于比如BroadcastReceiver等中也想要获取Application实例,这时就需要getApplicationContext()方法。

    //继承BroadcastReceiver并重写onReceive()方法
    @Override
    public void onReceive(Context context.Intent intent){
    	Application app=(Application)context.getApplicationContext();
    }
    

    内存泄漏之Context:

    我们经常会遇到内存泄漏,比如Activity销毁了,但是Context还持有该Activity的引用,造成了内存泄漏。(经常遇到)

    2种典型的错误引用方式:

    1. 错误的单例模式:
    public class Singleton{
    	private static Singleton instancel
    	private Context context;
    	private Singleton(Context context){
    		this.context=context;
    	}
    	public static Singleton getInstance(Context context){
    		if(instance == null ){
    			instance=new Singleton(context);
    		}
    		return instance;
    	}
    }
    

    熟悉单例模式的都知道,这是一个非线程安全的单例模式,instance作为静态对象,其生命周期要长于普通的对象(单例直到APP退出后台才销毁),其中也包含了Activity。比如Activity A去getInstance()得到instance对象,传入this,常驻内存的Singleton保存了我们传入的A对象,并一直持有,即使Activity被销毁掉,但因为它的引用还存在于一个Singleton中,就不可能被GC掉,这样就导致了内存泄漏。比如典型的数据库操作,存储数据,需要重复的去索取数据,用单例保持数据和拿到Activity持有context引用,因为单例可以看作是上帝,它帮我们保存数据。所以即使Activity被finish掉,还有它的引用在Singleton中。

    1. View持有Activity引用:
    public class MainActivity extend Activity{
    	private static Drawable mDrawable;	
    	@Override
    	protected void onCreate(Bundle saveInstanceState){
    		super.onCreate();
    		setContentView(R.layout.activity_main);
    		ImageView imageview=new ImageView(this);//通过代码动态的创建组件,而不是传统的xml配置组件,这里的ImageView持有当前Activity的引用。
    		mDrawable=getResources().getDrawable(R.drawable.ic_launcher);
    		imageview.setImageDrawable(mDrawable);
    	}
    }
    

    上述代码中,有一个static的Drawable对象。当ImageView设置这个Drawable的时候,ImageView保存了这个mDrawable的引用,而ImageView初始化的时候又传入了this,此处的this是指MainActivity的context。因为被static修饰的mDrawable是常驻内存的(比类还要早加载)。MainActivity是它的间接引用了,当MainActivity被销毁的时候,也不能被GC掉,就造成了内存泄漏。


    How to get the context in the whole :

    大量的地方都需要使用Context,我们常常会因为不知道怎么得到这个Context而苦恼。那么,全局获取Context无疑是最好的解决方案。
    很多时候,我们也不是经常为得不到Context而发愁,毕竟我们很多的操作都是在活动中进行的,而活动本身就是一个Context对象。但APP架构复杂后,很多逻辑代码都脱离了Activity类,此时又需要使用Context,所以我们需要采取全局获取Context的方法。
    举例, 我们平常经常会写网络工具类,比如下面的这些代码:

    public calss HttpUtil{
    	public static void sendHttpRequest(final String address,final HttpCallbackListener listener){
    		new Thread(new Runnable()){
    		@Override 
    		public void run(){
    		HttpURLConnection connection=null;
    		try{
    			URL url =new URL(address);
    			connection=(HttpURLConnection)url.openConnection();
    			connection.setRequestMethod("GET");
    			connection.setConnectTimeout(8000);
    			connection.setReadTimeout(8000);
    			connection.setDoInput(true);
    			connection.setDoOutput(true);
    			InputStream in =connection.getInputStream();
    			BufferedReader reader=new BufferedReader(new InputStreamReader(in));
    			StringBuilder response=new StringBuilder();
    			String line;
    			while((line=reader.readLine())!=nulll){
    				response.append(line);
    			}
    			if(listener!=null){
    				//回调onFinish()
    				listener.onFinish(response.toString);
    			}
    		}catch(Execption e){
    			if(listener!=null){
    				//回调onError()
    				listener.onError(e);
    			}
    		}finally{
    			if(connection!=null){
    				connection.disconnect();
    			}
    		}
    		}}.start();
    	}
    }
    

    上述代码中使用sendHttpRequest()方法来发送HTTP请求显然没问题。并且还可以在回调方法中处理服务器返回的数据。但是这个方法还可以被优化。当检测不到网络存在的时候就给用户一个Toast,并不再执行后面的代码。问题来了,Toast需要一个Context参数,但是在本来没有可以传递的Context对象。。。
    一般思路:在方法中添加一个COntext参数:

    	public static void sendHttpRequest(final String address,final HttpCallbackListener listener,final Context context){
    	if(!isNetWorkAvailable()){
    		Toast.makeText(context,……);
    		……
    	}
    	……
    

    看似可以,但是有点甩锅。我们将获取Context的任务转移到了sendHttpRequest()方法的调用方。至于调用方能不能得到COntext对象就不是我们要考虑的问题了。

    甩锅不一定是通用的解决方案。于是这里介绍哈如何获取全局Context的步骤:,通过它在项目的任何地方都能轻松的获取到Context。:

    • Android提供了一个Application类,每当APP启动的时候,系统就会自动将这个类进行初始化。我们可以定制一个自己的Application类,以便管理程序内一些全局的状态信息,比如说全局Context。
    • 定制一个自己的Application并不复杂,首先, 需要创建一个MyApplication类继承自系统的Application:
    public calss MyApplication extends Application{
    	private static Context context;
    	@Overrride
    	public void onCreate(){
    		context=getApplicationContext();
    	}
    	public static Context getContext(){
    		return context;
    	}
    }
    

    代码很简单,容易理解。重写了父类的onCreate()方法,并通过调用getApplicationContext()方法得到一个应用程序级别的Context,然后又提供了一个静态的getContext()方法,在这里将刚才获取到的COntext进行返回。

    • 接下来,我们需要告诉系统,当程序启动的时候应该初始化MyApplication类,而不是系统默认的Application类。这一步需要在清单文件里面实现,找到清单文件的<application>标签下进行指定就可以了:
    <manifest ……
    ……>
    <application 
    		android :name="com.example.myContext.MyApplication" //这里输入.MyApplication也可以,或者输入MyApplication根据AS提示自动补全包名
    					..>
    </application>
    

    注意:这里一定要加上完整的包名,不然系统将无法找到这个类。

    • 以上就是实现了一种全局获取Context的机制,在这个项目的任何地方使用Context,只需要调用MyApplication.getContext()就可以了。

    关于自定义Application和LitePal配置冲突的问题:
    自定义需要在清单文件写出android.name="……"。而为了让LitePal可以正常工作,也需要在清单文件下,配置:

    android:name="org.litepal.LitePalApplication"
    

    道理也是一样的,这样配置后,LitePal就能在内部自动获取到Context了。
    问题:当都已经配置过自定义的Application怎么办?岂不是和LitePalApplication冲突了?
    解答:任何一个项目都只能配置一个Application. 对于这种情况,LitePalApplication给出了很简单的解决方案,在自定义的Application中去调用LitePal的初始化方法就可以了:

    public calss MyApplication extends Application{
    	private static Context context;
    	@Overrride
    	public void onCreate(){
    		context=getApplicationContext();
    		LitePalApplication.initialize(context);
    	}
    	public static Context getContext(){
    		return context;
    	}
    }
    

    这种写法就相当于我们把全局Context对象通过参数传递给了LitePal,效果和在清单文件配置LitePalApplication是一样的。


    总结,如何在程序中正确的使用Context:
    一般Context造成的内存泄漏,几乎都是当Context销毁的时候,因为被引用导致销毁失败。而Application的Context对象可以简单的理解为伴随着进程存在的(它的生命周期也很长,毕竟APP加载的时候先加载Application,我们可以自定义Application然后继承系统的Application)。
    正确使用:

    1. 当Applicatin的Context能搞定的情况下,并且生命周期长的对象,优先使用Application的Context;
    2. 不要让生命周期长于Activity的对象持有Activity的引用。
    3. 尽量不要在Activity中使用非静态内部类。非静态内部类会隐式持有外部类实例的引用。如果使用静态内部类,将外部实例引用作为弱引用持有。

    获取全局context的另一种思路:

    ActivityThread是主进程的入口,它的currentApplication返回值是application.

    
    import android.app.Application;
    
    import java.lang.reflect.InvocationTargetException;
    
    /**
     * 这种方式获取全局的Application 是一种拓展思路。
     * <p>
     * 对于组件化项目,不可能把项目实际的Application下沉到Base,而且各个module也不需要知道Application真实名字
     * <p>
     * 这种一次反射就能获取全局Application对象的方式相比于在Application#OnCreate保存一份的方式显示更加通用了
     */
    public class AppGlobals {
        private static Application sApplication;
    
        public static Application getApplication() {
            if (sApplication == null) {
                try {
                    sApplication = (Application) Class.forName("android.app.ActivityThread")
                            .getMethod("currentApplication")
                            .invoke(null, (Object[]) null);
                } catch (IllegalAccessException e) {
                    e.printStackTrace();
                } catch (InvocationTargetException e) {
                    e.printStackTrace();
                } catch (NoSuchMethodException e) {
                    e.printStackTrace();
                } catch (ClassNotFoundException e) {
                    e.printStackTrace();
                }
            }
            return sApplication;
        }
    }
    
    
    展开全文
  • 编程中什么是「Context(上下文)

    万次阅读 多人点赞 2019-08-27 20:00:51
    编程中什么是「Context(上下文)」? 最近读Flask的文档,读到很多关于Context(上下文)的术语,如应用上下文,请求上下文等,查阅资料但没有得到理解?有没有比较好的解释? 每一段程序都有很多外部变量。只有...
  • 由浅入深聊聊Golang的context

    万次阅读 2020-03-01 03:08:26
    前言 正文
  • 浅析Android的Context

    千次阅读 2018-04-23 16:28:26
    Context是Android App中用的非常多的一种概念,常被翻译成上下文,这种概念在其他的技术中也有所使用,无意间点了Context的源码,那么就来分析分析Context在Android中到底是什么东西? 先贴段代码 /** * ...
  • 1、Context概念 其实一直想写一篇关于Context的文章,但是又怕技术不如而误人子弟,于是参考了些资料,今天准备整理下写出来,如有不足,请指出,参考资料会在醒目地方标明。 Context,相信不管是第一天开发...
  • Android之Context和Activity互相转换

    万次阅读 2015-02-03 17:47:06
    1、context转换为activity  Activity activity = (Activity) context; 2、从activity得到context 在activity的方法中用context = getBaseContext(); 而在activity中用context = this即可.
  • [2013-09-18 01:13:57,850] [ERROR] org.springframework.web.context.ContextLoader Context initialization failed  org.springframework.beans.factory.BeanCreationException: Error creating bean with name ...
  • idea报duplicate context path '/'

    万次阅读 2018-03-27 10:24:59
    我tomcat下加入两个maven项目,就是同一个项目的war和exploded两个版本,但是报错 在右下角提示什么Error:Duplicate context path '/'原因:因为不可能存在几个项目都发布到同一个地址下 这里是'/',所以需要修改...
  • 启动idea报错org.springframework.web.context.ContextLoader.initWebApplicationContext Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with ...
  • Android:根据上下文Context获取Activity

    万次阅读 2016-10-31 10:46:47
    根据Context获取Activity: private Activity getActivity() { Context context = getContext(); while (!(context instanceof Activity) && context instanceof ContextWrapp
  • 错误主要是jdk版本出现问题,博主也出现过这样的错误。当时使用的是jdk1.8一直报错,百度也没有效果。最终找到了答案,分享给大家。通过configure build path 换了jdk版本1.7,同时也要讲java compiler 改成jdk1.7 ...
  • Web应用设置Context Path的方式

    万次阅读 2015-04-30 10:15:46
    URL:http://hostname.com/contextPath/servletPath/pathInfoJetty如果没有contextPath,则默认使用root上下文,root上下文的路径为"/"。warName.war在没有XML IoC文件的情况下:如果WAR文件名是myapp.war,那么上...
  • // Only override drawRect: if you perform custom drawing. // An empty implementation adversely affects performance during animation. - (void)drawRect:(CGRect)rect ... CGContextRef context = UIGraphi
  • spring配置文件中时常会出现这个提示,翻译过来大概意思就是没有配置该文件到项目中 于是进入到file-Project Structure中查看 可以很明显的看到下面有个感叹号,大概意思是下面的文件没有匹配 ...
  • spring-boot配置文件中server.context-path不起作用

    万次阅读 热门讨论 2018-05-25 17:02:15
    spring-boot配置文件中server.context-path=/XXXXXXX不起作用:原因是更新后写法变成了server.servlet.context-path=/XXXXXX,这样写即可
  • LayoutInflater inflater = (LayoutInflater) context .getSystemService(context.LAYOUT_INFLATER_SERVICE); view = inflater.inflate(R.layout.home_select_list, null); 这行报空指针,可能原因为,这个...
  • Tomcat启动报错: Context initialization failed 检查Service层实现类是否加@Service注解 检查applicationcontext中配置的Mapper映射器baskPackage位置是否正确 检查mybatis-config配置文件 ...
1 2 3 4 5 ... 20
收藏数 1,658,274
精华内容 663,309
关键字:

context