Android開发中如何正确保存view的状态.doc

Android开发中如何正确保存view的状态？ 本文是由国外资深开发转件对，Android开发中view的状态正确保存方法的一个深入介绍。为什么是对view的讲解，而不是对Activity 和 Fragment状态保存的讲解呢？是因为前者比后两者稍微复杂，且网上还有太多混淆开发者的讲解。 为什么我们需要保存View的状态？ 因为，我坚信移动应用应该是帮助开发者解决问题，而不是制造问题。 想象一下一个非常复杂的设置页面： 这并不是从一个移动应用的截图（这不是典型的win32程序吗。。），但是适合用于说明我们的问题： 这里有非常多的文字输入控件，多选框，开关（switch）等等，你花了15分钟填完所有这些格子，总算轮到点击完成按钮了，但是突然，你不小心旋转了下屏幕，omg，所有的改动都没了，一切都回归到了初始状态。 当然，总有一些用户喜欢你的app简直到不行，不在乎重新填一次。但是老实说，这样做真的正确吗？别犯傻，你不尊重客户体验度，客户就不会喜欢你的APP，我们需要保存用户的修改。 如何保存View的状态？ 假设我们这里有一个带有图像，文字和 Switch toggle控件的简单布局： LinearLayout xmlns:android=/apk/res/android android:layout_width=match_parent android:layout_height=match_parent android:orientation=horizontal android:padding=@dimen/activity_horizontal_margin ImageView android:layout_width=wrap_content android:layout_height=wrap_content android:src=@drawable/ic_launcher/ TextView android:layout_width=0dip android:layout_weight=1 android:layout_height=wrap_content android:text=My Text/ Switch android:layout_width=wrap_content android:layout_height=wrap_content android:layout_margin=8dip/ /LinearLayout 看吧，非常简单的布局。但是当我们滑动一下switch开关然后旋转屏幕方向，switch又回到了原来的状态。 通常，安卓会自动保存这些View（一般是系统控件）的状态，但是为什么在我们的案例中不起作用了呢？ 让我们先停下来，弄明白安卓是如何管理View状态的。这里是正常情况下保存与恢复的示意图： saveHierarchyState(SparseArrayParcelable container) - 当状态需要保存的时候被安卓framework调用，通常会调用dispatchSaveInstanceState() 。 dispatchSaveInstanceState(SparseArrayParcelable container) - 被saveHierarchyState()调用。 在其内部调用onSaveInstanceState()，并且返回一个代表当前状态的Parcelable。这个Parcelable被保存在container参数中，container参数是一个键值对的map集合。View的ID是加键Parcelable是值。如果这是一个ViewGroup，还需要遍历其子view，保存子View的状态。 Parcelable onSaveInstanceState() - 被 dispatchSaveInstanceState()调用。这个方法应该在View的实现中被重写以返回实际的View状态。 restoreHierarchyState(SparseArrayParcelable container) - 在需要恢复View状态的时候被android调用，作为传入的SparseArray参数，包含了在保存过程中的所有view状态。 dispatchRestoreInstanceState(Sp