十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
Context的字面意思是“上下文”,那么这个“上下文”到底指的是什么?“上”指的是什么?“下”指定的是什么?
个人的理解,有助于自己的理解的方式,不一定对,如果有更好的看法可以一块交流学习。个人的理解,“上”指的是在APP启动的时候,就与Context有关了,这个时候还是系统启动阶段,就与Context发生了联系。
“下”指定的是在APP界面正常显示出来以后,正常与用户交互的过程中,可以用Context获取资源,系统服务等。所以Context所谓的上下文就是承上启下的作用。
Context的类的继承关系
从上图可以看到,Context只有一个实现类ContextImpl,Application,Service,Activity都是直接或者间接继承了ContextWrapper,ContextWrapper中有一个变量mBase,也是个Context类型,实际是ContextImpl的对象,Application,Service,Activity所有的操作都是委托给了mBase实现。
Context既然是承上启下,是个上下文,和APP启动流程有关,先来看看系统的启动流程和APP的启动流程,都在一张图里,如下:
从上图可以看到:
首先系统的第一个进程 init跑起来,作一些初始化相关的工作,然后通过系统调用fork出了一个zygote进程,init进程通过poll阻塞在那了。
zygote进程被init进程fork出来以后,做一些jni初始化等,通过调用fork出了一个SystemServer进程,SystemServer进程里面跑的都是安卓的系统服务,zygote通过jni调用java的代码,fork出了SystemServer进程,打开了java世界的大门,自己通过sokcet监听阻塞在那了,监听来自socket的信息。
SystemServer进程被fork出来以后,里面会开启非常多的系统服务,比如AMS,PMS,WMS等,SystemServer进程是一个非常重要的进程,系统的很多重要的服务都驻留在此进程中,SystemServer进程是通过Handler机制阻塞在那了。等待发来的消息并处理消息。这样整个系统就启动了。
在PMS中,会启动Lanuher APP,用户就可以看到安卓系统桌面了。如果用户点击了桌面上的QQ图标,Lannuher进程就会通过binder机制与AMS通信,告诉AMS要启动QQ应用,AMS收到 Lanuher进程发来的消息以后,通过socket发送信息给zygote进程,我们知道zygote进程在fork出了SystemServer进程以后就一直在监听着socket,所以zygote进程收到SystemServer进程发来的消息后,如果没有创建过QQ进程,这个时候,zygote就会调用fork系统调用创建一个新的进程,用来跑QQ代码,这个进程就是QQ进程,QQ App进程创建以后第一个调用的就是Activity.main()方法,如上图。
1 访问当前应用的资源
getResources
getAssets
2 启动其它组件
Activity
Service
3 获取系统服务
getSystemService
1 通过上面的系统启动流程和APP启动流程分析可知:第一个APP应用都是由AMS通过binder机制创建一个新的进程,然后调用ActivityThread类中的main方法开始的。很多人可能会感到奇怪为啥Android也是基于Java实现的,为啥没有看到main方法呢?其实整个App应用的入口就是ActivityThread.main方法.所有有关Application, Activity,Service的创建都是在ActivityThread类中,其实该类就是我们App的主线程。在ActivityThread中有一个方法 performLaunchActivity()方法,在这个方法里面就创建了Application,Activity。我们看一下这个方法。
如下图
调用mInstrumentation.newActivity()方法创建Activity。newActivity代码如下图
可以看到,创建Activity以后,调用了Activity的attach方法,第一个参数就是context,在这里Activity就和context发生了联系,这个context其实就是ContextImpl的实例。接着上面的第一张图 performLaunchActivity继续往下走,如下图:
通过上图可以看到,在创建完了activity,并且调用了activity.attach()方法之后,开始创建Application对象,如下
Application app = r.packageInfo.makeApplication(false,mInstrumentation)
makeApplication代码如下:
随后又创建了一个ContextImpl的实例,代码如下
//创建ContextImpl实例ContextImpl appContext = new ContextImpl();//初始化ContextImpl实例appContext.init(this,null,mActivityThread);//把appContext传给了newApplication方法app = mActivityThread.mInstrumentation.newApplication(cl,appClass,appContext);//与Application发生联系,ContextImpl实例保存了Application的实例appappContext.setOuterContext(app); mActivityThread.mAllApplication.add(app); mApplication = app;
下面看下newApplicaiton()方法,代码如下:
static public Application newApplication(Class> clazz,Context context){ //通过反射创建Application实例 Application app = (Application)clazz.newInstance(); //把上面传进来的ContextImpl实例通过attach方法保存了起来 app.attach(context); //返回Application实例 return app; }
创建完Application并且通过调用application实例的attach方法与ContextImpl实例发生了联系,接下来就应该调用application的onCreate()方法了。代码如下:
public void callApplicationOnCreate(Application app){ //调用Application的onCreate方法 app.onCreate(); }
创建了activity,也创建了application并且调用了application的attach和onCreate方法,接下来应该调用activity的onCreate方法了。还是在performLanucherActivity方法中。如下图:
如上图,通过mInstructation的callActivityOnCreate()方法调用activity的onCreate()。这段代码和调用application的onCreate()方法的逻辑类似,自己可以看一下。这里不再帖出代码
*** 通过上面的分析可以知道,Context是什么时候创建的,是怎么创建的,何时初始化的,如何与Application和Activity发生联系的等 ***
我们知道,Application的生命周期是和APP进程一样长的,Application对应的context也是一样,为什么Application的生命周期为什么这么长?
通过上面的分析可以知道,APP进程的入口是ActivityThread.main()方法,在这个方法中创建了一个ActivityThread的实例,通过Handler阻塞在那。ActivityThread的实例就会一直存在,如果APP不退出的话,而ActivityThread的实例中保存了application的mAllApplications,这是一个数组,保存Application实例的,在创建Application实例的时候,通过mActivityThread.mAllApplications.add(app),把app保存起来了,通过强引用可以知道,ActivityThread引用了application实例,而ActivityThread实例又在进程的循环中,一直在阻塞,所以Application的生命周期和进程一样。
下面以一张图来说明几种Context的不同点和用法。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。