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的启动流程
网页地址：http://cdiso.cn/article/ijcjos.html
