Android源码个个击破之Context和Activity的启动流程
Activity 中mParent 成员变量是如何被赋值的。 - CSDN博客
10年的沾益网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。全网营销推广的优势是能够根据用户设备显示端的尺寸不同,自动调整沾益建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联建站从事“沾益网站设计”,“沾益网站推广”以来,每个客户项目都认真落实执行。
Android 视图渲染过程的源码分析 - CSDN博客
android系统启动框架、Activity界面显示过程详解 - snow_flower - 博客园
Android源码之Activity从启动到显示到界面 - 阿里云
以下的源码都是API26.
context的初始化过程:https://www.jianshu.com/p/7d4b605f5060
----------------------------------------------------------------------------------------------------------------------------------------------
系统级别的Context实例化过程:
SystemServer的run方法中,调用createSystemContext方法
1)systemMain方法
通过ActivityThread的systemMain方法创建了一个系统级别的ActivityThread
调用activityThread的attach方法,传入true。
该方法创建了application并调用了onCreate方法。
2)getSystemContext()
以上是系统级别的context实例化过程,为了弄清activity这个context是如何实例化的,就得研究一下activity的启动过程。https://blog.csdn.net/qq_23547831/article/details/51224992
需要注意的是activity,service启动activity的过程都各不一样,activity复写了startActivity方法,service直接调用了父类的方法。
activity之所以要复写startActivity方法,是为了复用activity独有的startActivityForResult方法。
最终都会调用到Instrumentation的启动activity方法,再调用ActivityManagerNative
很明显,启动activity使用了binder。
这个"activity"为key的service是何时添加的呢?
我尝试着在SystemServer里找,但是没有找到。在ActivityManagerService自身的代码里找到。而setSystemProcess在SystemServer里被调用。
ActivityManagerService的实例是怎么创建出来的呢?
上面根据字节码反射创建了service的实例,实例实际是ActivityManagerService的内部类:Lifecycle.
调用了
getService方法得到了真正的ActivityManagerService.
调用了service的onStart方法。
上面说了这么多,关于ActivityManagerService创建的过程。
但是疑问尚在:
1)activity怎么就具备了context的特性了,它也没有new,怎么使之成为一个context。
2)startActivity怎么android系统就会弹出一个界面
前面
开启activity,最终会通过Binder机制(数据传输机制比较麻烦,后面研究)跨进程调用
ActivityManagerServcie的startActivityAsUser方法:
继而调用ActivityStarter的startActivityMayWait方法
在方法中又会调用到startActivityLocked方法
方法最后会调用到 startActivityUnchecked方法
最终调用了ActivityStack的startActivityLocked方法:
注意下面这部分代码,不同版本的源码会有很大的区别。
1)首先判断开启的activity是否是新任务,分别做不同的处理。
2)主要是调用WindowManager
***准备事务
***添加token
调用WindowManagerService的H来发送消息
注意ensureActivitiesVisibleLocked这个方法
接着方法调用顺序:
makeVisibleAndRestartIfNeeded (ActivityStack)
startSpecificActivityLocked (ActivityStackSupervisor)
realStartActivityLocked (ActivityStackSupervisor)
此方法内部会调用 app.thread.scheduleLaunchActivity,这个app.thread是IApplicationThread类的实例,具体的子类是哪个呢?
下面的源码为API26
app即Proce***ecord类
在里面搜索thread的set方法:
makeActive点击发现有2处引用:
引用1:
引用2:
找到上一个调用的地方
由上面的分析可知:app.thread的thread是ActivityThread
下面看它的scheduleLaunchActivity方法,看它是如何启动Activity的:
1)发送消息给H这个Handler
注意这个r变量,在后面有关Activity渲染绘制的源码中会用到。
2)handler的处理
实例化了Activity的对象:
通过Instrumentation的newActivity方法创建了Activity的实体:
尝试创建Application
下面的代码说明了Application只存在一个实例。
接着看performLaunchActivity方法:
将ContextImpl对象通过Activity的attach方法传入到Activity
最后这个也说明了ContextWrapper里的mBase是对ContextImpl。
看官方对ContextWrapper类解释:
英文的意思是说ContextWrapper是对Context的一种代理实现。
#Activity的onCreate方法回调
下面我们来细抠Activity的onCreate方法:
@MainThread @CallSuper protected void onCreate(@Nullable Bundle savedInstanceState) { if (DEBUG_LIFECYCLE) Slog.v(TAG, "onCreate " + this + ": " + savedInstanceState); if (getApplicationInfo().targetSdkVersion > O && mActivityInfo.isFixedOrientation()) { final TypedArray ta = obtainStyledAttributes(com.android.internal.R.styleable.Window); final boolean isTranslucentOrFloating = ActivityInfo.isTranslucentOrFloating(ta); ta.recycle(); if (isTranslucentOrFloating) { throw new IllegalStateException( "Only fullscreen opaque activities can request orientation"); } } if (mLastNonConfigurationInstances != null) { mFragments.restoreLoaderNonConfig(mLastNonConfigurationInstances.loaders); } if (mActivityInfo.parentActivityName != null) { if (mActionBar == null) { mEnableDefaultActionBarUp = true; } else { mActionBar.setDefaultDisplayHomeAsUpEnabled(true); } } if (savedInstanceState != null) { mAutoFillResetNeeded = savedInstanceState.getBoolean(AUTOFILL_RESET_NEEDED, false); mLastAutofillId = savedInstanceState.getInt(LAST_AUTOFILL_ID, View.LAST_APP_AUTOFILL_ID); if (mAutoFillResetNeeded) { getAutofillManager().onCreate(savedInstanceState); } Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG); mFragments.restoreAllState(p, mLastNonConfigurationInstances != null ? mLastNonConfigurationInstances.fragments : null); } mFragments.dispatchCreate(); getApplication().dispatchActivityCreated(this, savedInstanceState); if (mVoiceInteractor != null) { mVoiceInteractor.attachActivity(this); } mCalled = true; }
mFragments.dispatchCreate() :将onCreate事件分发给fragment,至于具体怎么分发的,后面再研究。
getApplication().dispatchActivityCreated(this, savedInstanceState) :这个方法是将activity的生命周期方法回调给Application
在Application里即可利用这2个方法来监听activity的状态:
这样,不需要通过广播,就能监听到Activity的生命周期方法了。(所以不阅读源码,很多好用的东西发现不了!)
Activity的onCreate方法里会有一个mCalled变量,来判断程序员复写onCreate方法是否调用了super.onCreate方法。
紧接着onCreate,又调用了onStart等其它的生命周期方法。
所以Activity初始创建的生命周期方法调用顺序是:
attach
onCreate
onStart
上面我们的注重点在于activity是如何实例化的,下面来研究一下UI方面的:Activity是怎么弹出并展示到我们的眼前的呢?
请看 Android源码个个击破之Activity的渲染过程
标题名称:Android源码个个击破之Context和Activity的启动流程
URL网址:http://pwwzsj.com/article/ijcjos.html