1.Activity生命周期简介
（1）onCreate
此时Activity正在创建
并且执行一些初始化工作，如setContentView界面资源，初始化数据等等
Bundle参数为Activity上次被异常情况下销毁而保存的状态信息
（2）onStart
此时Activity正在启动，但前台不可见，无法和用户交互
（3）onResume
此时Activity获得焦点，在前台可见并且可以和用户交互
（4）onPause
此时Activity正在停止
可以做持久层的数据存储、停止动画等操作
如果启动一个新的Activity，旧的Activity的onPause方法会先执行，然后才是新的Activity的生命周期方法调用
（5）onStop
此时Activity即将停止
可以做相对重量级的回收工作，如释放网络连接、注销广播等操作
需要注意的是，如果新启动的Activity是透明的或者没有完全覆盖旧Activity，旧的Activity都不会执行onStop
（6）onDestory
此时Activity即将销毁
可以做回收工作和资源释放等操作
（7）onRestart
此时Activity重新启动，Activity由后台切换到前台，由不可见到可见。
可以分类去理解这些生命周期，这些生命周期可以分为3组
第一组：创建、销毁
onCreate、onDestory
第二组：是否可见
onStart、onStop
第三组：是否可交互
onResume、onPause
2.Activity生命周期的切换过程
(1)启动一个Activity
onCreate -> onStart -> onRseume
(2)打开一个新的Activity
旧Activity onPause -> 新Activity onCreate -> 新Activity onStart -> 新Activity onResume ->旧Activity onStop（是否执行取决于旧Activity是否被完全覆盖）
感谢读到这里的小伙伴，下面的情况可以先自己分析一下，然后在一起讨论
（3）返回到旧的Activity
（4）Activity1上弹出对话框Activity2
（5）关闭屏幕/按Home键
（6）点亮屏幕/回到前台
（7）关闭对话框Activity2
（8）销毁Activity1
------------------------------------------------------------------------------------
（3）新Activity onPause -> 旧Activity onRestart-> 旧Activity onStart -> 旧Activity ->onResume ->新Activity onStop -> 新Activity onDestory
（4）Activity1 onPause -> Activity2 onCreate -> Activity2 -> onStart -> Activity2 onResume
（5）Activity2 onPause -> Activity2 onStop -> Activity1 -> onStop
（6）Activity2 onRestart -> Activity2 onStart -> Activity1 onRestart -> Activity2 onRestart -> Activity2 onStart -> Activity2 onResume
（7）Activity2 onPause -> Activity1 onResume -> Activity2 onStop -> Activity2 onDestory
（8）onPause -> onStop -> onDestory
在从生命周期的各个阶段去划分
完整的生命周期 onCreate -> onDestory
可见的生命周期 onStart -> onStop
可交互的生命周期 onResume -> onPause
以上这些偏概念性的生命周期解读，在开发前期确实很有指导性，但是在不断的开发中，难免会有这样的疑问，这些生命周期的回调方法是怎么执行的呢？又是在什么时候被调用的呢？
接下来从源码的角度，在去进一步的理解Activity的生命周期（源码基于Api28）
我们的Activity一般会继承于AppcompatActivity
那么来看看AppcompatActivity的onCreate方法是怎么写的
//AppcompatActivity @Override protected void onCreate(@Nullable Bundle savedInstanceState) { final AppCompatDelegate delegate = getDelegate(); delegate.installViewFactory(); delegate.onCreate(savedInstanceState); /.../ super.onCreate(savedInstanceState); }这里有发现了AppCompatDelegate这个抽象类，它是用来设置主题等UI显示，暂且不管它，在这里又看到了它调用父类的onCreate，在跟进去看继承的FragmentActivity的onCreate代码
//FragmentActivity @Override protected void onCreate(@Nullable Bundle savedInstanceState) { mFragments.attachHost(null /*parent*/); super.onCreate(savedInstanceState); /.../ }FragmentActivity主要做了和Fragment交互的一些操作，我们暂且不关注这些代码，继续看父类的onCreate方法
//ComponentActivity @Override @SuppressWarnings("RestrictedApi") protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); ReportFragment.injectIfNeededIn(this); }ComponentActivity这里注入了Fragment的LifeCycle，但依然不是我们想找的onCreated调用，继续看父类，终于来到了大名鼎鼎的Activity
//Activity @MainThread @CallSuper protected void onCreate(@Nullable Bundle savedInstanceState) { if (DEBUG_LIFECYCLE) Slog.v(TAG, "onCreate " + this + ": " + savedInstanceState); 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); } mRestoredFromBundle = savedInstanceState != null; mCalled = true; }这里看到了Activity的onCreate为我们做的事情，设置ActionBar、通过savedInstanceState恢复Activity状态等等，接下来去找onCreate的调用
同样在Activity类里，发现了performCreate的两个重载方法，在这里调用了onCreate
final void performCreate(Bundle icicle) { performCreate(icicle, null); } final void performCreate(Bundle icicle, PersistableBundle persistentState) { mCanEnterPictureInPicture = true; restoreHasCurrentPermissionRequest(icicle); if (persistentState != null) { onCreate(icicle, persistentState); } else { onCreate(icicle); } /.../ }至此，我们离真相已经很近了，我们了解了从AppcompatActivity的onCreate开始，每一层的父类在onCreate里做了什么事情，以及最终调用Activity的onCreate方法的方法，至此回答了第一个问题，onCreate方法是如何执行的，但是在什么时机被调用，却还是没有找到答案，没关系，我们在来看看performCreate这个方法是在什么时候被调用的
跟踪performCreate方法，在Instrumentation里发现了它的身影
//Instrumentation public void callActivityOnCreate(Activity activity, Bundle icicle) { prePerformCreate(activity); activity.performCreate(icicle); postPerformCreate(activity); }暂且不关注Instrumentation这个较为陌生的类，继续看callActivityOnCreate方法的调用
此时来到了ActivityThread这个里，到这里似乎一切就很明朗了，众所周知，ActivityThread就是我们常说的UI线程或者主线程，ActivityThread的main方法是整个程序的入口，在初始化的时候调用onCreate，也很合逻辑与我们平常开发时的宏观认知。
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) { /.../ //1 try { java.lang.ClassLoader cl = appContext.getClassLoader(); activity = mInstrumentation.newActivity( cl, component.getClassName(), r.intent); StrictMode.incrementExpectedActivityCount(activity.getClass()); r.intent.setExtrasClassLoader(cl); r.intent.prepareToEnterProcess(); if (r.state != null) { r.state.setClassLoader(cl); } } catch (Exception e) { if (!mInstrumentation.onException(activity, e)) { throw new RuntimeException( "Unable to instantiate activity " + component + ": " + e.toString(), e); } } try { //2 Application app = r.packageInfo.makeApplication(false, mInstrumentation); if (activity != null) { /.../ //3 if (r.isPersistable()) { mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState); } else { mInstrumentation.callActivityOnCreate(activity, r.state); } /.../ } return activity; }这段代码很长，我们先看两个地方，注释1和注释3，注释1处通过反射的方法创建了Activity，注释3处调用了callActivityOnCreate方法，至此，我们找到了第二个问题的答案，onCreate实在Activity创建的时候就进行了调用。
在看这个方法的时候，发现了注释2处的代码很有意思，makeApplication是获取Application的单例方法
public Application makeApplication(boolean forceDefaultAppClass, Instrumentation instrumentation) { if (mApplication != null) { return mApplication; } /.../ return app; }那这里为什么要重新调用呢？（第一次调用是在接收到BIND_APPLICATION消息的时候），笔者认为，这里还是分两种情况，第一种情况在同一个进程下，获取了已经存在的Application实例。第二种情况是在多进程下，先回想我们开发中的一个常识：App中有几个进程，Application就会被创建几次，新进程中的单例和所有变量会失效，因为是一个新的内存区域，然后结合此处的代码，可以推测出，新进程的Application会为空，所以需要再次创建。
综上所述，我们已经找到了关于Activity生命周期的在文章开始提出的两个问题的答案。至此，从Activity的创建到onCreate的调用以及onCreate所做事情，我们都已经通过源码熟悉了，那么Activity的创建时机是在什么时候，应用进程又是和系统进程如何交互的，从我们点击桌面图标到应用程序展示在我们眼前，系统又做了哪些事情?笔者将会在后续博客中和小伙伴一起进行探讨，感兴趣的小伙伴也可以自己探索，源码确实是进阶路上必不可少的一步。
