在开始这节之前，我先介绍下我写源码分析类文章的方式．
首先源码分析类的文章，顾名思义就是从源码的角度来分析某一个知识点，我不希望我写的源码分析类的文章是这样的：整个篇幅或者一上来就是关于各种方法调用的分析，方法逻辑的分析，这种形式的文章会给人枯燥乏味感．
我希望以这样的方式来写这类文章：
首先是原理部分：这部分内容不会包含代码的分析，主要以图文的形式来对源码的整个流程进行梳理总结，不会涉及到细节，进而对相应的知识从整体上有一个了解．
其次是源码部分：这部分就是完全以源码的角度来分析，并且会涉及到细节．
最后是思考部分：这部分是我的一些思考，一些问题，一些能借鉴的东西．
Activity界面状态数据的保存是在onSaveInstanceState回调方法，界面状态数据的恢复是在onRestoreInstanceState回调方法。本节就从原理和源码两个角度来进行分析。
原理
Activity界面状态分为保存和恢复两个步骤，就按这俩步骤来介绍下原理。
保存
保存这一过程，它不受AMS（ActivityManagerService的简称，运行于系统进程）的控制，android把保存的自主权完全交给了app，app会根据不同的条件来决定是否要进行数据的保存。
若需要保存，它会在Activity进入stop状态之后或之前，它会调用Activity的onSaveInstanceState方法，在这个方法中会把保存这一操作告诉给Activity包含的所有views和fragments，你们有需要保存数据的吗？有的话就交上来。app进程把需要保存的数据收集起来后，就统一寄存在AMS，因此即使当前app进程被杀掉，它的一些需要保存的数据已经在AMS中保存下来了。
不同的view会根据自己的需求来决定是否需要保存数据（比如EditText会把正在输入的文本信息保存下来）
恢复
恢复这一过程，它是受AMS控制的。由于低内存等异常原因导致app被杀掉，app再次重新创建的时候，AMS会把之前app保存的数据传递给相应的Activity，Activity的onRestoreInstanceState方法或者onCreate方法的Bundle类型的参数包含了传递过来的参数，Activity也会把view保存的数据分发给它包含的views，不同的view根据自己保存的数据，恢复自己的状态（比如EditText会把上次输入时候的文本恢复）
当然了恢复机制完全是针对 由于一些异常情况导致app进程被杀或者Activity需要重新启动的情况。用户正常的按返回键退出Activity或者正常退出应用，或者用户手动杀掉app进程（在最近任务中）这种情况是不会启动恢复机制的。
源码分析
源码分析着重介绍app进程端的，关于AMS端的会在后面逐步介绍（分析的源码版本是android 12）。我们从保存和恢复这两个步骤来分别进行分析。
1. 保存
保存的操作分为三部分：
- 决定是否保存
- 若需要保存，则收集需要保存的数据
- 收集的数据发送给AMS
config信息变化会导致保存操作，从一个Activity跳转到另外一个Activity或者点击home键回到桌面也会引起保存操作。
咱们分析从一个Activity跳转到另外一个Activity这种情况下的保存操作。
跳转到另外一个Activity时候，当前的Activity会进入stop状态，AMS会通知Activity进入stop，那就从这作为切入点
1.1 Activity进入stop流程
1.1.1 StopActivityItem的初始化
StopActivityItem的初始化代码如下：(位于StopActivityItem.java)
public static StopActivityItem obtain(int configChanges) {
StopActivityItem instance = ObjectPool.obtain(StopActivityItem.class);
if (instance == null) {
instance = new StopActivityItem();
}
instance.mConfigChanges = configChanges;
return instance;
}
上面的代码AMS会调用，AMS初始化一个StopActivityItem后，最终会把它通过binder调用传入app进程（关于AMS与app进程的binder通信后面会介绍），StopActivityItem就是AMS用来告诉app的哪个Activity可以开始进入stop状态。当StopActivityItem的实例post到ui线程后，它的execute方法会被执行。
1.1.2 execute方法
execute方法代码如下：(StopActivityItem.java)
@Override
public void execute(ClientTransactionHandler client, ActivityClientRecord r,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStop");
//ActivityThread继承了ClientTransactionHandler，因此进入ActivityThread的handleStopActivity方法
client.handleStopActivity(r, mConfigChanges, pendingActions,
true /* finalStateRequest */, "STOP_ACTIVITY_ITEM");
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
从这个方法开始后面所有的流程都是运行在app进程的
StopActivityItem重写了ActivityLifecycleItem的execute，这方法是一个回调方法，在合适的时机会调用它。这个类还有一个postExecute方法，在整个stop流程执行完毕后，还会返回到这个方法，请记住它。
方法的参数介绍：
ClientTransactionHandler client：是一个抽象类，定义了一组接口，ActivityThread继承了它。
ActivityClientRecord r：封装了启动的Activity的很多信息。
这些都不属于咱们这节要讨论的内容，后面章节会详细介绍。
因为ActivityThread继承了ClientTransactionHandler，因此进入ActivityThread的handleStopActivity方法
1.1.3 handleStopActivity方法
对应代码：（位于ActivityThread.java)
@Override
public void handleStopActivity(ActivityClientRecord r, int configChanges,
PendingTransactionActions pendingActions, boolean finalStateRequest, String reason) {
r.activity.mConfigChangeFlags |= configChanges;
final StopInfo stopInfo = new StopInfo();
//在调用这个方法的时候，saveState的值为true，代表需要Activity进行状态保存
performStopActivityInner(r, stopInfo, true /* saveState */, finalStateRequest,
reason);
if (localLOGV) Slog.v(
TAG, "Finishing stop of " + r + ": win=" + r.window);
updateVisibility(r, false);
// Make sure any pending writes are now committed.
if (!r.isPreHoneycomb()) {
QueuedWork.waitToFinish();
}
stopInfo.setActivity(r);
stopInfo.setState(r.state);
stopInfo.setPersistentState(r.persistentState);
pendingActions.setStopInfo(stopInfo);
mSomeActivitiesChanged = true;
}
首先构造一个StopInfo stopInfo对象，它作为performStopActivityInner方法的参数，performStopActivityInner方法还有个参数saveState（代表是否要进行保存操作），当前的值为true
那就先就进入performStopActivityInner这个方法探探究竟，后面还会返回到这方法
1.1.4 performStopActivityInner方法
看下它的代码：（位于ActivityThread.java)
private void performStopActivityInner(ActivityClientRecord r, StopInfo info,
boolean saveState, boolean finalStateRequest, String reason) {
......省略代码
// One must first be paused before stopped...
//进入stop状态之前需要先进入pause状态
performPauseActivityIfNeeded(r, reason);
......省略代码
//调用callActivityOnStop方法
callActivityOnStop(r, saveState, reason);
}
上面代码的意思：
在Activity进入stop状态之前会先让Activity进入pause状态进而会调用Activity的onPause方法，接着调用callActivityOnStop方法
1.2 决定是否保存操作
callActivityOnStop方法中决定了是否要进行保存操作。
1.2.1 callActivityOnStop方法
看下它的关键代码：（位于ActivityThread.java)
private void callActivityOnStop(ActivityClientRecord r, boolean saveState, String reason) {
// Before P onSaveInstanceState was called before onStop, starting with P it's
// called after. Before Honeycomb state was always saved before onPause.
//当前saveState为true，
final boolean shouldSaveState = saveState && !r.activity.mFinished && r.state == null
&& !r.isPreHoneycomb();
final boolean isPreP = r.isPreP();
//在android P版本之前 在onStop方法之前执行onSaveInstanceState方法
if (shouldSaveState && isPreP) {
callActivityOnSaveInstanceState(r);
}
try {
//开始调用Activity的onStop方法
r.activity.performStop(r.mPreserveWindow, reason);
} catch (SuperNotCalledException e) {
throw e;
} catch (Exception e) {
if (!mInstrumentation.onException(r.activity, e)) {
throw new RuntimeException(
"Unable to stop activity "
+ r.intent.getComponent().toShortString()
+ ": " + e.toString(), e);
}
}
r.setState(ON_STOP);
//在P版本以后，在onStop方法之后执行onSaveInstanceState方法
if (shouldSaveState && !isPreP) {
callActivityOnSaveInstanceState(r);
}
}
先来看下final boolean shouldSaveState这个值，它最后的值最终决定了是否要进行保存操作，它的值是由
saveState && !r.activity.mFinished && r.state == null && !r.isPreHoneycomb() 计算得到的
saveState：当前的值为true
r.activity.mFinished：当用户按了返回按键或者代码里面主动调用了finish方法（暂且称这种操作为主动操作），该值为true。那 !r.activity.mFinished 就代表着非主动操作的时候才有必要保存。
r.state：它指向了保存的数据，r.state会在ActivityThread的performResumeActivity方法中置为null（也就是Activity进入resume状态的时候）。r.state == null 就意味着只有Activity进入resume状态后才有必要保存
!r.isPreHoneycomb()：android为Honeycomb这个版本的是，保存的操作是在pause状态的时候进行存储。非Honeycomb版本，则需要在Activity进入stop状态存储。
小结下上面代码： 在saveState为true，也就是调用者要求保存的前提下，需要当前的Activity 非主动操作，并且Activity进入过resume状态，并且是在android不是Honeycomb这个版本 的情况下才会进行保存操作。
或者可以这样理解：
- 用户点击了返回按键或者代码中主动调用了finish方法导致 需要销毁Activity，这种情况下是不需要保存操作的。这也很好理解，这都属于主动操作，为啥还有保存操作呢，保存这些数据没有任何意义并且还会浪费内存
- 启动新的Activity或者点击home进入桌面的时候 导致Activity进入stop状态，这些情况是需要保存操作的
- 当Activity没有进入过resume状态的时候（不能与用户进行交互的状态），这时候是完全没必要进行保存操作的。这也很好理解，用户都不能操作Activity何来保存一说呢。
当shouldSaveState为true，会调用callActivityOnSaveInstanceState方法
1.3 收集需要保存的数据
下面的分析开始进入收集保存数据的流程
1.3.1 callActivityOnSaveInstanceState方法
看下它的代码：（位于ActivityThread.java)
private void callActivityOnSaveInstanceState(ActivityClientRecord r) {
r.state = new Bundle();
r.state.setAllowFds(false);
//需要在AndroidManifest配置activity的时候，配置android:persistableMode属性设置为非persistNever时候有效，Activity的信息会被持久化的disk上
if (r.isPersistable()) {
r.persistentState = new PersistableBundle();
mInstrumentation.callActivityOnSaveInstanceState(r.activity, r.state,
r.persistentState);
} else {
//咱们只关心下面的情况
mInstrumentation.callActivityOnSaveInstanceState(r.activity, r.state);
}
}
保存的数据都会存放在r.state中
1.3.2 callActivityOnSaveInstanceState方法
它的代码：（Instrumentation.java)
public void callActivityOnSaveInstanceState(@NonNull Activity activity,
@NonNull Bundle outState) {
activity.performSaveInstanceState(outState);
}
1.3.3 performSaveInstanceState方法
代码如下：（Activity.java)
final void performSaveInstanceState(@NonNull Bundle outState) {
dispatchActivityPreSaveInstanceState(outState);
//咱们只关注onSaveInstanceState方法
onSaveInstanceState(outState);
saveManagedDialogs(outState);
mActivityTransitionState.saveState(outState);
storeHasCurrentPermissionRequest(outState);
if (DEBUG_LIFECYCLE) Slog.v(TAG, "onSaveInstanceState " + this + ": " + outState);
dispatchActivityPostSaveInstanceState(outState);
}
1.3.4 onSaveInstanceState方法
代码如下：（Activity.java)
protected void onSaveInstanceState(@NonNull Bundle outState) {
//把从mWindow.saveHierarchyState()获取的数据以WINDOW_HIERARCHY_TAG作为key放入outState中
outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState());
outState.putInt(LAST_AUTOFILL_ID, mLastAutofillId);
//mFragments.saveAllState()获取的数据也同样会放入outState中，因此Fragments中也会做和Activity同样的事情，去收集需要保存的数据
Parcelable p = mFragments.saveAllState();
if (p != null) {
outState.putParcelable(FRAGMENTS_TAG, p);
}
if (mAutoFillResetNeeded) {
outState.putBoolean(AUTOFILL_RESET_NEEDED, true);
getAutofillManager().onSaveInstanceState(outState);
}
dispatchActivitySaveInstanceState(outState);
}
上面代码作用：
- 从mWindow中收集需要保存的数据放入outState中
- 从所有的fragments中收集数据放入outState中
- 分发save事件出去
fragment不属于咱们讨论的范畴，咱们只关注window相关的保存。mWindow它是PhoneWindow的实例，PhoneWindow是Window的子类，这个会在view系列介绍
1.3.5 saveHierarchyState方法
代码如下：（PhoneWindow.java)
@Override
public Bundle saveHierarchyState() {
//new 一个outState，它会把数据收集起来，最终返回给Activity进行保存
Bundle outState = new Bundle();
//mContentParent为null就完全没必要收集，直接返回
if (mContentParent == null) {
return outState;
}
SparseArray<Parcelable> states = new SparseArray<Parcelable>();
//mContentParent可以理解为一个Activity中顶层的view，它包含了所有的content view
mContentParent.saveHierarchyState(states);
outState.putSparseParcelableArray(VIEWS_TAG, states);
// Save the focused view ID.
final View focusedView = mContentParent.findFocus();
//如果焦点view不为null，并且它的id存在，则把是焦点的view的id保存起来
if (focusedView != null && focusedView.getId() != View.NO_ID) {
outState.putInt(FOCUSED_ID_TAG, focusedView.getId());
}
......省略代码
return outState;
}
上面代码作用：
- new一个Bundle outState，它会作为返回值返回给Activity
- mContentParent收集需要保存的数据，放入outState
- 找到焦点view，如果它存在id，则保存下来，以便下次恢复
咱们只关系view的保存，看下saveHierarchyState这方法
1.3.6 saveHierarchyState方法
它的代码：（View.java)
public void saveHierarchyState(SparseArray<Parcelable> container) {
dispatchSaveInstanceState(container);
}
因为mContentParent是一个ViewGroup（ViewGroup是View的子类），saveHierarchyState方法位于View类
1.3.7 ViewGroup的dispatchSaveInstanceState方法
它的代码：（ViewGroup.java)
@Override
protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
super.dispatchSaveInstanceState(container);
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
View c = children[i];
//遍历它的所有的子view，当子view没有设置PARENT_SAVE_DISABLED这个flag的时候，去保存数据
if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
//若c是ViewGroup则进入ViewGroup的dispatchSaveInstanceState方法，否则进入View的dispatchSaveInstanceState方法
c.dispatchSaveInstanceState(container);
}
}
}
上面方法作用：
遍历它的所有的子view（因为ViewGroup包含了很多的子view），当子view没有设置PARENT_SAVE_DISABLED这个flag的时候，去保存数据
那来看下View类的dispatchSaveInstanceState方法
1.3.8 View的dispatchSaveInstanceState方法
代码如下：（View.java)
protected void dispatchSaveInstanceState(SparseArray<Parcelable> container) {
//有一个非常关键的条件，view必须要有id，并且没有SAVE_DISABLED_MASK的flag
if (mID != NO_ID && (mViewFlags & SAVE_DISABLED_MASK) == 0) {
mPrivateFlags &= ~PFLAG_SAVE_STATE_CALLED;
//调用view的onSaveInstanceState方法，它会返回一个Parcelable
Parcelable state = onSaveInstanceState();
if ((mPrivateFlags & PFLAG_SAVE_STATE_CALLED) == 0) {
throw new IllegalStateException(
"Derived class did not call super.onSaveInstanceState()");
}
if (state != null) {
// Log.i("View", "Freezing #" + Integer.toHexString(mID)
// + ": " + state);
//保存起来
container.put(mID, state);
}
}
}
如果一个view想要保存数据，一个很关键的条件就是它需要有id（id的设置可以在layout文件中使用android:id 进行设置，也可以使用代码方式设置），并且mViewFlags没有设置不能保存的flag，才可对view数据进行保存。
1.3.9 onSaveInstanceState方法
方法代码：（View.java)
@Nullable protected Parcelable onSaveInstanceState() {
mPrivateFlags |= PFLAG_SAVE_STATE_CALLED;
if (mStartActivityRequestWho != null || isAutofilled()
|| mAutofillViewId > LAST_APP_AUTOFILL_ID) {
BaseSavedState state = new BaseSavedState(AbsSavedState.EMPTY_STATE);
if (mStartActivityRequestWho != null) {
state.mSavedData |= BaseSavedState.START_ACTIVITY_REQUESTED_WHO_SAVED;
}
if (isAutofilled()) {
state.mSavedData |= BaseSavedState.IS_AUTOFILLED;
}
if (mAutofillViewId > LAST_APP_AUTOFILL_ID) {
state.mSavedData |= BaseSavedState.AUTOFILL_ID;
}
state.mStartActivityRequestWhoSaved = mStartActivityRequestWho;
state.mIsAutofilled = isAutofilled();
state.mHideHighlight = hideAutofillHighlight();
state.mAutofillViewId = mAutofillViewId;
return state;
}
return BaseSavedState.EMPTY_STATE;
}
上面方法是View类的默认实现，自定义的View可以根据自己的需求只需要重写onSaveInstanceState该方法，就可以把需要保存的数据收集起来。
1.4 收集的数据发送给AMS
当需要保存的数据都收集起来，放入r.state（r是ActivityClientRecord的实例）中后，就需要把数据发送给AMS。在回到handleStopActivity方法
1.4.1 handleStopActivity方法
代码如下：
@Override
public void handleStopActivity(ActivityClientRecord r, int configChanges,
PendingTransactionActions pendingActions, boolean finalStateRequest, String reason) {
r.activity.mConfigChangeFlags |= configChanges;
final StopInfo stopInfo = new StopInfo();
//在调用这个方法的时候，saveState的值为true，代表需要Activity进行状态保存
performStopActivityInner(r, stopInfo, true /* saveState */, finalStateRequest,
reason);
if (localLOGV) Slog.v(
TAG, "Finishing stop of " + r + ": win=" + r.window);
updateVisibility(r, false);
// Make sure any pending writes are now committed.
if (!r.isPreHoneycomb()) {
QueuedWork.waitToFinish();
}
stopInfo.setActivity(r);
stopInfo.setState(r.state);
stopInfo.setPersistentState(r.persistentState);
pendingActions.setStopInfo(stopInfo);
mSomeActivitiesChanged = true;
}
performStopActivityInner方法执行完毕后，会对StopInfo stopInfo进行初始化，其中 stopInfo.setState(r.state);代码中的r.state就是刚刚收集到的保存数据，设置到stopInfo中。
PendingTransactionActions pendingActions：pendingActions.setStopInfo(stopInfo)把stopInfo设置到pendingActions中。
handleStopActivity方法执行完后，会进入StopActivityItem的postExecute方法
1.4.2 postExecute方法
它的代码：（StopActivityItem.java)
@Override
public void postExecute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
client.reportStop(pendingActions);
}
同样这个方法也是被动调用的，ActivityThread继承了ClientTransactionHandler，它实现了reportStop方法
1.4.3 reportStop方法
它的代码：（ActivityThread.java）
@Override
public void reportStop(PendingTransactionActions pendingActions) {
//post到ui线程执行，pendingActions.getStopInfo()肯定是一个Runnable
mH.post(pendingActions.getStopInfo());
}
1.4.1 步为PendingTransactionActions pendingActions设置了stopinfo，那来看下StopInfo到底是一个什么？
1.4.4 StopInfo类
它的代码：（StopInfo.java)
public static class StopInfo implements Runnable{
@Override
public void run() {
// Tell activity manager we have been stopped.
try {
if (DEBUG_MEMORY_TRIM) Slog.v(TAG, "Reporting activity stopped: " + mActivity);
// TODO(lifecycler): Use interface callback instead of AMS.
ActivityClient.getInstance().activityStopped(
mActivity.token, mState, mPersistentState, mDescription);
} catch (RuntimeException ex) {
// Dump statistics about bundle to help developers debug
final LogWriter writer = new LogWriter(Log.WARN, TAG);
final IndentingPrintWriter pw = new IndentingPrintWriter(writer, " ");
pw.println("Bundle stats:");
Bundle.dumpStats(pw, mState);
pw.println("PersistableBundle stats:");
Bundle.dumpStats(pw, mPersistentState);
if (ex.getCause() instanceof TransactionTooLargeException
&& mActivity.packageInfo.getTargetSdkVersion() < Build.VERSION_CODES.N) {
Log.e(TAG, "App sent too much data in instance state, so it was ignored", ex);
return;
}
throw ex;
}
}
}
1.4.3 步在ui线程中post了一个Runnable，最终会进入它的run方法， 会调用ActivityClient.getInstance().activityStopped方法，其中mState参数就是保存的收集的数据
1.4.5 activityStopped方法
它的代码如下：（ActivityClient.java)
public void activityStopped(IBinder token, Bundle state, PersistableBundle persistentState,
CharSequence description) {
try {
getActivityClientController().activityStopped(token, state, persistentState,
description);
} catch (RemoteException e) {
e.rethrowFromSystemServer();
}
}
getActivityClientController().activityStopped这是一个binder调用，会把token，收集的数据等传递给AMS。
到此收集的数据就发送给了AMS
1.5 小结
用一张时序图总结
按以下步骤分析了保存的流程：
- AMS通知Activity进入stop状态
- 决定是否要保存数据
- 从Activity及它包含的views/fragments收集数据
- 把收集到的数据发送给AMS
对于像横竖屏切换这种导致Activity保存数据的过程有一个小小的差别，这种情况下收集的数据不会发送给AMS，一般会把收集的数据直接用于新创建的Activity。
2. 恢复
恢复的流程其实和保存基本相似，它的流程很简单，AMS若传递了收集的数据，就进行恢复操作，否则不进行
2.1 AMS通知Activity启动
像StopActivityItem一样，启动Activity也对应了一个类LaunchActivityItem，那我们就从它的初始化开始。
2.1.1 LaunchActivityItem初始化
它的代码：（LaunchActivityItem.java)
public static LaunchActivityItem obtain(Intent intent, int ident, ActivityInfo info,
Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo,
String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state,
PersistableBundle persistentState, List<ResultInfo> pendingResults,
List<ReferrerIntent> pendingNewIntents, ActivityOptions activityOptions,
boolean isForward, ProfilerInfo profilerInfo, IBinder assistToken,
IActivityClientController activityClientController,
FixedRotationAdjustments fixedRotationAdjustments, IBinder shareableActivityToken,
boolean launchedFromBubble, IBinder taskFragmentToken) {
LaunchActivityItem instance = ObjectPool.obtain(LaunchActivityItem.class);
if (instance == null) {
instance = new LaunchActivityItem();
}
setValues(instance, intent, ident, info, curConfig, overrideConfig, compatInfo, referrer,
voiceInteractor, procState, state, persistentState, pendingResults,
pendingNewIntents, activityOptions, isForward, profilerInfo, assistToken,
activityClientController, fixedRotationAdjustments, shareableActivityToken,
launchedFromBubble, taskFragmentToken);
return instance;
}
AMS会调用obtain方法来初始化一个LaunchActivityItem，看它里面的关键参数：
ActivityInfo info：封装了要启动的是哪个Activity以及相关信息
Bundle state：AMS保存的从app收集上来的数据，也就是保存环节 传递给AMS的数据，这不又发给app进程的。
上面的参数会保存在LaunchActivityItem instance中。
LaunchActivityItem通过binder传递到app进程后，会被post到ui线程执行，它的execute方法会被执行
2.1.2 execute方法
它的代码：（LaunchActivityItem.java)
@Override
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mActivityOptions, mIsForward, mProfilerInfo,
client, mAssistToken, mFixedRotationAdjustments, mShareableActivityToken,
mLaunchedFromBubble, mTaskFragmentToken);
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
从这个方法开始，后面的方法都运行与app进程的ui线程中。各种参数会构造一个ActivityClientRecord r，它里面的mState就是存放了保存的数据，因为ActivityThread继承了ClientTransactionHandler，进入它的
handleLaunchActivity方法
2.1.3 handleLaunchActivity方法
它的代码：（ActivityThread.java)
@Override
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
......省略代码
final Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfigurationController.getConfiguration());
reportSizeConfigurations(r);
//activity没有主动销毁并且pendingActions不为null
if (!r.activity.mFinished && pendingActions != null) {
pendingActions.setOldState(r.state);
//下面这个值设为true 很关键，如果不为true后面的恢复操作不会执行
pendingActions.setRestoreInstanceState(true);
pendingActions.setCallOnPostCreate(true);
}
} else {
// If there was an error, for any reason, tell the activity manager to stop us.
ActivityClient.getInstance().finishActivity(r.token, Activity.RESULT_CANCELED,
null /* resultData */, Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
}
......省略代码
return a;
}
上面方法调有performLaunchActivity方法。
pendingActions.setRestoreInstanceState(true)这行代码很关键，如果不为true，后面onRestoreInstanceState的恢复流程就不会执行
2.1.4 performLaunchActivity方法
它的代码：（ActivityThread.java)
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//拿到ActivityInfo信息
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
//下面代码主要是通过反射来生成一个Activity实例
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(isProtectedComponent(r.activityInfo),
appContext.getAttributionSource());
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 {
......省略代码
if (activity != null) {
......省略代码
//若是持久化了，则调用这
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
//最终会调用到Activity的onCreate方法，r.state就是AMS传递的保存的数据
mInstrumentation.callActivityOnCreate(activity, r.state);
}
......省略代码
}
r.setState(ON_CREATE);
} catch (SuperNotCalledException e) {
throw e;
} catch (Exception e) {
if (!mInstrumentation.onException(activity, e)) {
throw new RuntimeException(
"Unable to start activity " + component
+ ": " + e.toString(), e);
}
}
return activity;
}
上面的代码最终会调用到Activity的onCreate方法，onCreate方法的参数Bundle savedInstanceState就是代表AMS传递的保存的数据
2.1.5 小结
AMS会通知app启动相应的Activity，并且会把启动的activity信息，及上次保存的数据等信息放在ActivityClientRecord对象中，当Activity的onCreate方法被调用的时候会把保存数据传递过来。并且还做了一个工作：pendingActions.setRestoreInstanceState(true);后面的onRestoreInstanceState恢复操作会用到它。
上面的流程分析了进入Activity的onCreate方法的过程，恢复的流程可以在onCreate方法中进行（不建议在onCreate中进行恢复）。恢复操作也可以在onRestoreInstanceState方法中，这也是我们接下来要重点分析的.
onRestoreInstanceState恢复是在Activity进入start状态后调用的，因此从这作为入口，
2.2 Activity进入start状态，并进行恢复数据的分发
2.2.1 handleStartActivity方法
它的代码：（ActivityThread.java)
@Override
public void handleStartActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, ActivityOptions activityOptions) {
final Activity activity = r.activity;
......省略代码
//调用Activity的onStart方法
activity.performStart("handleStartActivity");
r.setState(ON_START);
//pendingActions 为null则不需要进行恢复等工作
if (pendingActions == null) {
// No more work to do.
return;
}
// Restore instance state
//进入恢复工作，pendingActions.shouldRestoreInstanceState()这个值在launch的时候设置为true了
if (pendingActions.shouldRestoreInstanceState()) {
if (r.isPersistable()) {
if (r.state != null || r.persistentState != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
r.persistentState);
}
} else if (r.state != null) {
//r.state代表保存的数据，存在则开始进入callActivityOnRestoreInstanceState方法
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
......省略代码
}
上面方法会通知Activity进入start状态，并且执行它的onStart方法。
pendingActions.shouldRestoreInstanceState()为true并且r.state不为null则进入callActivityOnRestoreInstanceState方法
2.2.2 callActivityOnRestoreInstanceState方法
它的代码：（Instrumentation.java）
public void callActivityOnRestoreInstanceState(@NonNull Activity activity,
@NonNull Bundle savedInstanceState) {
activity.performRestoreInstanceState(savedInstanceState);
}
2.2.3 onPostCreate方法
它的代码：（Activity.java)
final void performRestoreInstanceState(@NonNull Bundle savedInstanceState) {
onRestoreInstanceState(savedInstanceState);
restoreManagedDialogs(savedInstanceState);
}
2.2.4 onRestoreInstanceState方法
它的代码：（Activity.java)
protected void onRestoreInstanceState(@NonNull Bundle savedInstanceState) {
if (mWindow != null) {
//若保存了WINDOW_HIERARCHY_TAG，则进行恢复
Bundle windowState = savedInstanceState.getBundle(WINDOW_HIERARCHY_TAG);
if (windowState != null) {
mWindow.restoreHierarchyState(windowState);
}
}
}
2.2.5 restoreHierarchyState方法
它的代码：（PhoneWindow.java）
@Override
public void restoreHierarchyState(Bundle savedInstanceState) {
if (mContentParent == null) {
return;
}
SparseArray<Parcelable> savedStates
= savedInstanceState.getSparseParcelableArray(VIEWS_TAG);
if (savedStates != null) {
mContentParent.restoreHierarchyState(savedStates);
}
// restore the focused view
int focusedViewId = savedInstanceState.getInt(FOCUSED_ID_TAG, View.NO_ID);
if (focusedViewId != View.NO_ID) {
View needsFocus = mContentParent.findViewById(focusedViewId);
if (needsFocus != null) {
needsFocus.requestFocus();
} else {
Log.w(TAG,
"Previously focused view reported id " + focusedViewId
+ " during save, but can't be found during restore.");
}
}
......省略代码
}
进入mContentParent.restoreHierarchyState方法
2.2.6 restoreHierarchyState方法
它的代码：（View.java)
public void restoreHierarchyState(SparseArray<Parcelable> container) {
dispatchRestoreInstanceState(container);
}
2.2.7 ViewGroup的dispatchRestoreInstanceState方法
因为mContentParent是一个ViewGroup，因此进入ViewGroup的方法
它的代码：（ViewGroup.java)
@Override
protected void dispatchRestoreInstanceState(SparseArray<Parcelable> container) {
super.dispatchRestoreInstanceState(container);
final int count = mChildrenCount;
final View[] children = mChildren;
//遍历它包含的所有的子view
for (int i = 0; i < count; i++) {
View c = children[i];
if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
c.dispatchRestoreInstanceState(container);
}
}
}
2.2.8 View的dispatchRestoreInstanceState方法
它的代码：（View.java)
protected void dispatchRestoreInstanceState(SparseArray<Parcelable> container) {
//必须有id，否则不进恢复
if (mID != NO_ID) {
Parcelable state = container.get(mID);
if (state != null) {
// Log.i("View", "Restoreing #" + Integer.toHexString(mID)
// + ": " + state);
mPrivateFlags &= ~PFLAG_SAVE_STATE_CALLED;
//调用onRestoreInstanceState方法开始恢复操作
onRestoreInstanceState(state);
if ((mPrivateFlags & PFLAG_SAVE_STATE_CALLED) == 0) {
throw new IllegalStateException(
"Derived class did not call super.onRestoreInstanceState()");
}
}
}
}
2.2.9 onRestoreInstanceState方法
它的代码：（View.java)
protected void onRestoreInstanceState(Parcelable state) {
mPrivateFlags |= PFLAG_SAVE_STATE_CALLED;
if (state != null && !(state instanceof AbsSavedState)) {
throw new IllegalArgumentException("Wrong state class, expecting View State but "
+ "received " + state.getClass().toString() + " instead. This usually happens "
+ "when two views of different type have the same id in the same hierarchy. "
+ "This view's id is " + ViewDebug.resolveId(mContext, getId()) + ". Make sure "
+ "other views do not use the same id.");
}
if (state != null && state instanceof BaseSavedState) {
BaseSavedState baseState = (BaseSavedState) state;
if ((baseState.mSavedData & BaseSavedState.START_ACTIVITY_REQUESTED_WHO_SAVED) != 0) {
mStartActivityRequestWho = baseState.mStartActivityRequestWhoSaved;
}
if ((baseState.mSavedData & BaseSavedState.IS_AUTOFILLED) != 0) {
setAutofilled(baseState.mIsAutofilled, baseState.mHideHighlight);
}
if ((baseState.mSavedData & BaseSavedState.AUTOFILL_ID) != 0) {
// It can happen that views have the same view id and the restoration path will not
// be able to distinguish between them. The autofill id needs to be unique though.
// Hence prevent the same autofill view id from being restored multiple times.
((BaseSavedState) state).mSavedData &= ~BaseSavedState.AUTOFILL_ID;
if ((mPrivateFlags3 & PFLAG3_AUTOFILLID_EXPLICITLY_SET) != 0) {
// Ignore when view already set it through setAutofillId();
if (Log.isLoggable(AUTOFILL_LOG_TAG, Log.DEBUG)) {
Log.d(AUTOFILL_LOG_TAG, "onRestoreInstanceState(): not setting autofillId "
+ "to " + baseState.mAutofillViewId + " because view explicitly set"
+ " it to " + mAutofillId);
}
} else {
mAutofillViewId = baseState.mAutofillViewId;
mAutofillId = null; // will be set on demand by getAutofillId()
}
}
}
}
上面方法是默认实现，如自定义view需要恢复操作，则需要重写该方法。
2.3 小结
到此恢复流程分析完毕，恢复数据可以在onCreate方法中进行（但是不建议在这操作），最好是onRestoreInstanceState方法中进行。
onRestoreInstanceState方法会在onStart方法执行完毕后调用，这个调用是有前提条件的：首先必须是Activity第一次创建的时候也就是执行了onCreate方法后，其次AMS传递了保存的数据；否则不会被调用。
对于像横竖屏切换这种导致Activity保存数据的过程有一个小小的差别，这种情况下收集的数据不会发送给AMS，一般会把收集的数据直接用于新创建的Activity。
总结
Activity界面状态保存恢复这机制，android底层封装了一套完美的框架，让我们不需要关心底层的细节，让我们使用的时候能有多简单就有多简单，比如我们想保存和恢复Activity层面的数据，那就重写Activity的onSaveInstanceState和onRestoreInstanceState方法，比如我们想对自定义view，进行保存和恢复操作，同样也只需要重写onSaveInstanceState和onRestoreInstanceState方法即可。这就是框架的魅力所在吧。
思考
为啥不能保存大数据？
我个人认为是从两方面考虑：一方面是app进程与系统进程进行通信用的是binder，而binder对传输的数据有大小限制。如果想保存和恢复大数据就需要使用到ViewModel。另外一方面是每个系统都要求系统保存大量的数据的话，那系统的压力就非常大了。
模板方法
在搭建保存恢复这机制这套框架的时候用到了模板方法设计模式。
BaseClientRequest定义了三个方法：preExecute，execute，postExecute。它的子类StopActivityItem和LaunchActivityItem都是它的子类，根据自己的需求实现了相应的方法。preExecute，execute，postExecute这三个方法什么时候被调用，子类完全不需要关心。
还有Activity/Viiew的onSaveInstanceState和onRestoreInstanceState方法，它们啥时候被调用，子类不需要关心，只需要把细节实现了就行。
为啥保存数据的所有权交给app？
首先站在系统的角度考虑，我系统给app提供了保存数据的功能，但是啥时候应该保存，保存哪些数据等等这些细节系统不关心，它也关心不过来。所以把保存的所有权交给app，系统的压力也少了很多。
为啥在Activity进入stop状态的时候保存数据？
既然要以Activity为单位来保持数据，那总得选一个合适的时机，在Activity处于create，start，resume状态的时候都不行，因为这时候的界面数据是不稳定的，并且尤其处于resume状态，进程处于前台，几乎不会被杀掉。
Activity进入stop状态后，它所在的进程变为后台不可见进程，这时候的Activity被杀掉的风险是比较大的，并且这时候Activity要保存的数据状态处于稳定态（因为进入stop用户也不可能与Activity进行交互），所以这时候是一个非常好的时机把数据保存起来。
