标签（空格分隔）：Actiivty 状态保存和恢复
当我们在前台和后台切换，或者横竖屏切换的时候，Activity会被重新创建，Android系统默认是帮我们自动保存和恢复了和这个Activity有关的一些状态,涉及到ActivityThread Ams的调度机制，这里暂时不要去case，我们主要看包括界面ui上view的状态，如何保证能够恢复回来。我们都知道，保存的时候会调用onSaveInstanceState保存一些数据到bundle中，恢复的时候会调用onRestoreInstanceState来恢复。那么这套机制又是什么样子的?保存的是哪些信息?又是以一个什么流程去恢复的。
1.Activity.onSaveInstanceState
protected void onSaveInstanceState(Bundle outState) {
outState.putBundle(WINDOW_HIERARCHY_TAG, mWindow.saveHierarchyState());
Parcelable p = mFragments.saveAllState();
if (p != null) {
outState.putParcelable(FRAGMENTS_TAG, p);
}
getApplication().dispatchActivitySaveInstanceState(this, outState);
}
这个方法中,outState是在ActiivtyThread中新出来的,此时将mWindow的state保存到了bundle中。然后获取了当前应用的Application对象,分发交给ActivityLifecycleCallbacks去处理,等于Application预留的接口,这里不用去关注,除非有主动去注册。下面分析mWindow.saveHierarchyState的具体实现,mWindow对象是一个PhoneWindow对象。
2.PhoneWindow.saveHierarchyState
@Override
public Bundle saveHierarchyState() {
Bundle outState = new Bundle();
if (mContentParent == null) {
return outState;
}
SparseArray states = new SparseArray();
mContentParent.saveHierarchyState(states);
outState.putSparseParcelableArray(VIEWS_TAG, states);
// save the focused view id
View focusedView = mContentParent.findFocus();
if (focusedView != null) {
if (focusedView.getId() != View.NO_ID) {
outState.putInt(FOCUSED_ID_TAG, focusedView.getId());
} else {
if (false) {
Log.d(TAG, "couldn't save which view has focus because the focused view "
+ focusedView + " has no id.");
}
}
}
// save the panels
SparseArray panelStates = new SparseArray();
savePanelState(panelStates);
if (panelStates.size() > 0) {
outState.putSparseParcelableArray(PANELS_TAG, panelStates);
}
if (mDecorContentParent != null) {
SparseArray actionBarStates = new SparseArray();
mDecorContentParent.saveToolbarHierarchyState(actionBarStates);
outState.putSparseParcelableArray(ACTION_BAR_TAG, actionBarStates);
}
return outState;
}
这个方法中,mContentParent对应的是顶级视图DecorView下的child(id为 com.android.internal.R.id.content),如果它为空，直接返回。接下来分别是创建了三个SparseArray,它是android提供的一个类似HashMap的类,效率比Map高,不过key必须为Interger,分别用来保存view ,panels和actionbar state的状态,构建了整个window对象的state。这里我们着重分析view层的state。因为其他两个也是类似的效果。分析mContentParent.saveHierarchyState的实现。mContentParent是一个ViewGroup对象.
3.View.saveHierarchyState(SparseArray
public void saveHierarchyState(SparseArray container) {
dispatchSaveInstanceState(container);
}
View和ViewGroup均由实现这个dispatchSaveInstanceState方法，类似组合模式我们见的比较多,可以推测ViewGroup中会继续分发给的child去保存状态,下面分别看看view和viewgroup中的实现,看是否是这样一回事。
View中的dispatchSaveInstanceState实现：
protected void dispatchSaveInstanceState(SparseArray container) {
if (mID != NO_ID && (mViewFlags & SAVE_DISABLED_MASK) == 0) {
mPrivateFlags &= ~PFLAG_SAVE_STATE_CALLED;
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号是否有设置,以及根据mViewFlags来判断是否需要保存,一般来说如果这个view没有被设置id,系统会认为你根本就没有进行操作,会认为不需要去保存状态,当然这里只是系统给出的一个规则,不用去纠结好还是不好,实际使用过程中我们需要去遵守就好,接下来回调onSaveInstanceState去保存状态,这个接口是给用户根据不同的情况去客制化保存的一些信息,每一个view都有自己的实现方式,最后将保存的Parcelable对象存储到container中，以mId--Parcelable键值对的形式存储。
ViewGroup中的dispatchSaveInstanceState实现：
@Override
protected void dispatchRestoreInstanceState(SparseArray container) {
super.dispatchRestoreInstanceState(container);
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
View c = children[i];
if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
c.dispatchRestoreInstanceState(container);
}
}
}
看代码实现,和我们推测的一致,分为两步,首先是super.dispatchRestoreInstanceState先保存自己的状态,而后是遍历去保存子child的state。以递归view树的形式去执行。通过在ViewGroup以及android的主要容器LinearLayout,RelativeLayout中发现,有些类似的容器也是不需要保存的，只需要它的子child保存了一些信息即可在重新layout的时候去恢复ui显示,因此对于容器来说,一般也就不需要保存状态了。当然如果有特殊需要,比如动态改变了容器的颜色,padding值等等,那么要想恢复也必须手动去处理保存和恢复了。
由于View是一个所有控件的父类,一般也极少直接去使用,我们来看看典型的TextView究竟是保存了哪些state
TextView.onSaveInstanceState
@Override
public Parcelable onSaveInstanceState() {
Parcelable superState = super.onSaveInstanceState();
// Save state if we are forced to
boolean save = mFreezesText;
int start = 0;
int end = 0;
if (mText != null) {
start = getSelectionStart();
end = getSelectionEnd();
if (start >= 0 || end >= 0) {
// Or save state if there is a selection
save = true;
}
}
if (save) {
SavedState ss = new SavedState(superState);
// XXX Should also save the current scroll position!
ss.selStart = start;
ss.selEnd = end;
if (mText instanceof Spanned) {
Spannable sp = new SpannableStringBuilder(mText);
if (mEditor != null) {
removeMisspelledSpans(sp);
sp.removeSpan(mEditor.mSuggestionRangeSpan);
}
ss.text = sp;
} else {
ss.text = mText.toString();
}
if (isFocused() && start >= 0 && end >= 0) {
ss.frozenWithFocus = true;
}
ss.error = getError();
return ss;
}
return superState;
}
从这段保存的code来看,对于TextView主要是保存了它的mText信息和selection信息,一般来说TextView是不满足条件的,对于它的子类EditText可以满足条件,主要工作就是保存了mText信息到了SavedState的text字段中。有了这个初步的印象,下面来看看恢复的流程。
4.Activity.onRestoreInstanceState
protected void onRestoreInstanceState(Bundle savedInstanceState) {
if (mWindow != null) {
Bundle windowState = savedInstanceState.getBundle(WINDOW_HIERARCHY_TAG);
if (windowState != null) {
mWindow.restoreHierarchyState(windowState);
}
}
}
与保存类似,onRestoreInstanceState首先会通过Bundle拿到前面onSaveInstanceState存储在WINDOW_HIERARCHY_TAG key中的bundle对象,那么这两个bundle对象是一个吗？这里我可以解释下,这两个bundle对象是同一个,每一个Activity创建的时候会同时新建一个ActivityClientRecord的binder对象,用以和远程的ams进行通信,调度Actiivty的生命周期,同时在ActivityThread的ArrayMap<>[IBinder, ActivityClientRecord] mActivities对象中会保存这些ActivityClientRecord的信息。在ActivityClientRecord中的字段token就是远程ams中标识一个Activity的标示符。mActivities中的key即是对应的这些token。这里说了这么多,就需要明白一点,当一个Activity恢复的时候,也就是relaunch的时候,会根据token去mActivities查找ActivityClientRecord,所以是会公用上一次的ActivityClientRecord对象的。这里继续跟踪可以发现,onSaveInstanceState的Bunlde对象就是ActivityClientRecord对象中的state字段,恢复的时候也是取的state字段,一步步传给onRestoreInstanceState去恢复。到这里为止,我们已经知道onSaveInstanceState和onRestoreInstanceState操作的是同一个Bundle对象,并且对应的就是ActivityClientRecord对象中的state字段。
取到onSaveInstanceState保存的信息之后,接下来分析mWindow.restoreHierarchyState的实现。
5.PhoneWindow.restoreHierarchyState(Bundle)
@Override
public void restoreHierarchyState(Bundle savedInstanceState) {
if (mContentParent == null) {
return;
}
SparseArray 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.");
}
}
// restore the panels
SparseArray panelStates = savedInstanceState.getSparseParcelableArray(PANELS_TAG);
if (panelStates != null) {
restorePanelState(panelStates);
}
if (mDecorContentParent != null) {
SparseArray actionBarStates =
savedInstanceState.getSparseParcelableArray(ACTION_BAR_TAG);
if (actionBarStates != null) {
doPendingInvalidatePanelMenu();
mDecorContentParent.restoreToolbarHierarchyState(actionBarStates);
} else {
Log.w(TAG, "Missing saved instance states for action bar views! " +
"State will not be restored.");
}
}
}
这里我们可以看到,和PhoneWindow.saveHierarchyState就是一个一一对应的关系,也是一个逆向的过程。首先是取到保存在bunlde对象VIEWS_TAG中的SparseArray
6.View.restoreHierarchyState(SparseArray
public void restoreHierarchyState(SparseArray container) {
dispatchRestoreInstanceState(container);
}
和上面类似,View中dispatchRestoreInstanceState实现如下：
protected void dispatchRestoreInstanceState(SparseArray container) {
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(state);
if ((mPrivateFlags & PFLAG_SAVE_STATE_CALLED) == 0) {
throw new IllegalStateException(
"Derived class did not call super.onRestoreInstanceState()");
}
}
}
}
ViewGroup中dispatchRestoreInstanceState实现如下：
@Override
protected void dispatchRestoreInstanceState(SparseArray container) {
super.dispatchRestoreInstanceState(container);
final int count = mChildrenCount;
final View[] children = mChildren;
for (int i = 0; i < count; i++) {
View c = children[i];
if ((c.mViewFlags & PARENT_SAVE_DISABLED_MASK) != PARENT_SAVE_DISABLED) {
c.dispatchRestoreInstanceState(container);
}
}
}
由此可以看到,在一个恢复case中,也会以递归view树的形式去恢复,如果是ViewGroup首先会恢复自己的state,然后递归去恢复它的child。在View中dispatchRestoreInstanceState方法中,获取保存在mID key中的Parcelable对象,回调onRestoreInstanceState接口,会去真正的执行restore state操作。这个接口中我们可以实现自己的业务逻辑。
下面具体来看我们上面TextView保存的逻辑和恢复的过程
TextView.onRestoreInstanceState
@Override
public void onRestoreInstanceState(Parcelable state) {
if (!(state instanceof SavedState)) {
super.onRestoreInstanceState(state);
return;
}
SavedState ss = (SavedState)state;
super.onRestoreInstanceState(ss.getSuperState());
// XXX restore buffer type too, as well as lots of other stuff
if (ss.text != null) {
setText(ss.text);
}
if (ss.selStart >= 0 && ss.selEnd >= 0) {
if (mText instanceof Spannable) {
int len = mText.length();
if (ss.selStart > len || ss.selEnd > len) {
String restored = "";
if (ss.text != null) {
restored = "(restored) ";
}
Log.e(LOG_TAG, "Saved cursor position " + ss.selStart +
"/" + ss.selEnd + " out of range for " + restored +
"text " + mText);
} else {
Selection.setSelection((Spannable) mText, ss.selStart, ss.selEnd);
if (ss.frozenWithFocus) {
createEditorIfNeeded();
mEditor.mFrozenWithFocus = true;
}
}
}
}
if (ss.error != null) {
final CharSequence error = ss.error;
// Display the error later, after the first layout pass
post(new Runnable() {
public void run() {
setError(error);
}
});
}
}
可以看到保存和恢复就是一个写入和读取的过程,整个过程也是一一对应的关系。是一个可逆的过程。将这些数据恢复之后,系统重新布局,也就达到了恢复ui界面的目的。
至此,关于Activitty状态保存onSaveInstanceState和恢复onRestoreInstanceState也就分析完了,主要是一个流程问题,整个过程中保存和恢复都是共享的同一份bundle实例。对于特殊情况,系统并未handle的case,我们需要自己去实现onSaveInstanceState和onRestoreInstanceState方法。