Android面试经验基础Android知识

怎么处理SaveState

2016-10-14  本文已影响220人  黄怡菲

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

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

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

处理SaveState的四个方面

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

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

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

创建时的页面：

create.png restore.png

处理SaveState恢复后的页面

create.png

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

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

第一：保存数据

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

    @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的正常处理逻辑

    @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，下面是节选的一小段源码。

// 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的处理主要注意以下几点：

第三：处理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中。这类页面一般和其他页面没有很强的逻辑关系，同时又是消耗资源的大户。

适用场景：

使用taskAffinity

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

适用场景：

关于多Task的补充

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

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

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

Task中Activity销毁 vs 进程被杀

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

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

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

先看Task中Activity销毁

再看进程被杀

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

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。

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

上一篇下一篇

猜你喜欢

热点阅读