怎么处理SaveState

发表于

怎么处理SaveState

前文链接：是时候使用SaveState了

要使前文介绍的5.0新机制生效，应用需要设计为多Task结构，而且要处理好页面的SaveState相关逻辑。

这里先讨论SaveState的相关逻辑，再介绍怎么设计应用的Task结构。

处理SaveState的四个方面

在之前演示代码的基础上，我们稍做改动：代码链接

  1. ActivityTwo包含一个文字列表
  2. 文字列表中每一项的前缀是由启动的Intent的Extra决定
  3. 文字列表中每一项的后缀是由创建页面的时间戳决定

如果我们不处理SaveState，则在恢复ActivityTwo时，列表中每一项的后缀会发生变化，如果处理SaveState，则能保证返回时页面和创建时一样。在代码中通过修改ActivityTwo#ENABLE_SAVE_STATE可以切换两种状态。

创建时的页面：

创建时的页面

不处理SaveState恢复后的页面

不处理SaveState恢复后的页面

处理SaveState恢复后的页面

处理SaveState恢复后的页面

SaveState的处理应该包括4个部分

  1. 保存数据
  2. 恢复数据
  3. 处理View
  4. 处理Fragment

第一：保存数据

这一步相对简单，只要把页面中的数据变量保存到outState中

1
2
3
4
5
6
7
8
@Override
protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    if (ENABLE_SAVE_STATE) {
        outState.putString(KEY_PREFIX, mPrefix);
        outState.putString(KEY_SUFFIX, mSuffix);
    }
}

实际项目中，可能由Intent中传入页面id，再通过网络接口获取页面详情。这时，也需要将网络返回的数据也保存在outState中。

第二：恢复数据

恢复数据时，需要考虑onCreate的正常处理逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_two);
    mListView = (ListView) findViewById(R.id.lv);
    if (ENABLE_SAVE_STATE && savedInstanceState != null) {
        // 恢复流程
        mPrefix = savedInstanceState.getString(KEY_PREFIX);
        mSuffix = savedInstanceState.getString(KEY_SUFFIX);
        mListView.setAdapter(new TwoAdapter(mPrefix, mSuffix));
    } else {
        // 初始化流程
        mPrefix = getIntent().getStringExtra(KEY_PREFIX);
        mSuffix = String.valueOf(SystemClock.uptimeMillis());
        mListView.setAdapter(new TwoAdapter(mPrefix, mSuffix));
    }
}

实际项目中，初始化网络请求应放初始化流程中，而类似mListView.setAdapter的View更新逻辑应该在网络请求的回调中处理。

第三：处理View

上面的例子中，除了ListView的内容，我们还应注意到ListView的位置。不管我们是否处理SaveState，ListView都会恢复到离开时的位置。这是因为ListView的基类AbsListView实现了Save和Restore，下面是节选的一小段源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// AbsListView
    @Override
    public Parcelable onSaveInstanceState() {
        ......
        Parcelable superState = super.onSaveInstanceState();
        SavedState ss = new SavedState(superState);
        if (mPendingSync != null) {
            // Just keep what we last restored.
            ss.selectedId = mPendingSync.selectedId;
            ss.firstId = mPendingSync.firstId;
            ss.viewTop = mPendingSync.viewTop;
            ss.position = mPendingSync.position;
            ss.height = mPendingSync.height;
            ss.filter = mPendingSync.filter;
            ss.inActionMode = mPendingSync.inActionMode;
            ss.checkedItemCount = mPendingSync.checkedItemCount;
            ss.checkState = mPendingSync.checkState;
            ss.checkIdState = mPendingSync.checkIdState;
            return ss;
        }
        .......
     }

除了AbsListView，还有很多View实现了Save和Restore的机制，包括ViewPager当前的位置，EditText和TextView中的文本等。

关于View的处理主要注意以下几点：

  • 系统以一个Map来保存View的状态，以id为key
  • 没有id的View是不会被保存状态的
  • 如果id重复，则View的状态会被覆盖
  • 自定义的View，要注意处理View的Save和Restore
  • 如果View的恢复有特殊处理逻辑，需要充分考虑View更新的时机，注意onCreate、onRestoreInstanceState和网络请求回调的时序问题。

第三：处理Fragment

关于Fragment的处理，和Activity的处理基本一致。只需要注意一个特殊的地方

很多项目都会只在Manifest中声明一个FragmentContainerActivity的模式，各个页面通过Fragment实现。然后启动FragmentContainerActivity，通过Extra传递要展现的Fragment类名和Argument。FragmentContainerActivity#onCreate中创建并添加Fragment。

由于Activity的恢复机制会自动重建Fragment，所以在恢复时不要再重复创建添加Fragment。当然也不要新创建，并通过replace替换老的，这样会使Fragment的恢复机制失效。

这部的例子演示，可使用如下步骤复现：

  1. 修改ActivityThree#ENABLE_SAVE_STATE进行切换
  2. 启动Three
  3. 点击Three的文字可返回到One
  4. 在One中消耗内存，直到logcat中出现ActivityThree#onDestroy
  5. 再次启动Three

合理区分Task

Android关于Task的定义十分复杂，而且很多特性在普通应用开发中根本用不到。而且在5.0之后，又引入了android:documentLaunchMode让它变得更加复杂了。

关于Task，还需要另一篇专题来讨论。这里只举两类多Task的例子。

使用singleInstance

给一些特定的页面设置singleInstance，可使他们处于单独的Task中。这类页面一般和其他页面没有很强的逻辑关系，同时又是消耗资源的大户。

适用场景：

  • 视频播放或录制页（视频的编码解码，视频上的绚丽弹幕和礼物等）
  • 应用介绍页（包含很多大图和动画）
  • 应用内用于现实外部网页的单WebView页
  • ViewPager实现的大图图集页

使用taskAffinity

给一组完成某一功能的Activity设置相同的taskAffinity，就可使用FLAG_ACTIVITY_NEW_TASK启动新Task。使用taskAffinity启动的新Task一般都包括多个Activity，而且和别的参数相互影响，请谨慎使用。

适用场景：

  • 注册、登陆、找回密码等页面（这类页面一般占用的资源并不多，不一定要设计在独立的Task中）
  • 自定义的选择相册，照相机，图片预览，图片裁剪等页面

关于多Task的补充

由于不同的Task之间不能通过StartActivityForResult传递结果，可能需要EventBus或其他机制在Task之间传递信息。

默认的每个Task都会出现在最近应用中。上述的这些情况中，都可使用android:excludeFromRecents避免这些Task在最近应用中出现

后面单独补充了一节进程被杀的介绍，因为它很容易和Task中Activity销毁混淆

Task中Activity销毁 vs 进程被杀

我们先看下再ActivityManagerService中进程Process和Task的关系

Task&Process

  1. ActivityManagerService通过一个列表mHistory来管理所有ActivityRecord
  2. 相同TaskRecord中的ActivityRecord在列表中处于连续位置
  3. 同一个TaskRecord中的ActivityRecord可能处于不同的ProcessRecord中

由于以下两个因素，使得很难找到Task和进程之间关联的清晰线索。

  • 同一Task中的Activity可能属于不同进程
  • 进程中不仅有Activity，还有Service和BroadcastReceiver

先看Task中Activity销毁

  • 处理的问题：一个进程内部，前后台Task的资源协调
  • 触发时机：进程使用的内存接近上限时（根据机型不同，大约在64M～256M之间）

再看进程被杀

  • 处理的问题：系统控制中，多进程之间的资源协调
  • 触发时机：整个系统使用的内存接近机器配置的内存上限时

我们以一个简化的例子讨论两者的关系。假设：

  • 单进程最大可使用内存为100M，进程使用内存超过90M时会触发后台Task销毁。
  • 系统总可用内存为200M，系统使用内存超过190M时会触发后台进程被杀。
  • 系统中运行着3个进程，他们在三个Task中的分布和内存使用如下
  • Task1处于前台运行
Momory Usage Process1 Process2 Process 3
Task1 60M 20M -
Task2 20M 20M -
Task3 - - 40M

如果T1 P1部分消耗的内存由60M上升到75M，由于P1的总内存消耗达到95M，所以会导致P1 T2中的Activity被销毁。

如果T1 P2部分消耗的内存由20M上升到50M，会导致系统总内存消耗达到190M。此时三个Process中，P1和P2和前台Task关联，优先级较高，所以系统会杀掉P3。

这个例子，只是对两者关系的一个简要说明。系统对进程的实际处理方式要复杂得多！