Activitty状态保存onSaveInstanceState和恢复onRestoreInstanceState

标签（空格分隔）：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

@Overridepublic Bundle saveHierarchyState() {    Bundle outState = new Bundle();    if (mContentParent == null) {        return outState;    }    SparseArray<Parcelable> states = new SparseArray<Parcelable>();    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<Parcelable> panelStates = new SparseArray<Parcelable>();    savePanelState(panelStates);    if (panelStates.size() > 0) {        outState.putSparseParcelableArray(PANELS_TAG, panelStates);    }    if (mDecorContentParent != null) {        SparseArray<Parcelable> actionBarStates = new SparseArray<Parcelable>();        mDecorContentParent.saveToolbarHierarchyState(actionBarStates);        outState.putSparseParcelableArray(ACTION_BAR_TAG, actionBarStates);    }    return outState;}这个方法中,mContentParent对应的是顶级视图DecorView下的child(id为 com.android.internal.R.id.content),如果它为空，直接返回。接下来分别是创建了三个SparseArray<Parcelable>,它是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<Parcelable> container) {    dispatchSaveInstanceState(container);}

View和ViewGroup均由实现这个dispatchSaveInstanceState方法，类似组合模式我们见的比较多,可以推测ViewGroup中会继续分发给的child去保存状态,下面分别看看view和viewgroup中的实现,看是否是这样一回事。

View中的dispatchSaveInstanceState实现：

protected void dispatchSaveInstanceState(SparseArray<Parcelable> 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实现：

@Overrideprotected void dispatchRestoreInstanceState(SparseArray<Parcelable> 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

@Overridepublic 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)

@Overridepublic 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.");        }    }    // restore the panels    SparseArray<Parcelable> panelStates = savedInstanceState.getSparseParcelableArray(PANELS_TAG);    if (panelStates != null) {        restorePanelState(panelStates);    }    if (mDecorContentParent != null) {        SparseArray<Parcelable> 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对象,然后交给mContentParent.restoreHierarchyState(savedStates)去处理。

6.View.restoreHierarchyState(SparseArray)

public void restoreHierarchyState(SparseArray<Parcelable> container) {    dispatchRestoreInstanceState(container);}

和上面类似,View中dispatchRestoreInstanceState实现如下：

protected void dispatchRestoreInstanceState(SparseArray<Parcelable> 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实现如下：

@Overrideprotected void dispatchRestoreInstanceState(SparseArray<Parcelable> 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

@Overridepublic 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方法。