怎么处理SaveState

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

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

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

处理SaveState的四个方面

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

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

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

创建时的页面:

《怎么处理SaveState》 create.png
《怎么处理SaveState》 创建时的页面

不处理SaveState恢复后的页面

《怎么处理SaveState》 restore.png

处理SaveState恢复后的页面

《怎么处理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的处理主要注意以下几点:

  • 系统以一个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的关系

《怎么处理SaveState》 Task&Process.gif

  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 UsageProcess1Process2Process 3
Task160M20M
Task220M20M
Task340M

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

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

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

    原文作者:黄怡菲
    原文地址: https://www.jianshu.com/p/962be059f56c
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞