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

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实现：

@Override
protected 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

@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<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<Parcelable>对象,然后交给mContentParent.restoreHierarchyState(savedStates)去处理。

6.View.restoreHierarchyState(SparseArray<Parcelable>)

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实现如下：

@Override
protected 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

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