阅读 5219

重学安卓:绝不丢失状态的 Activity 重建机制!

前言的前言

很抱歉上周我因为沉迷代码而忘了发文。

今天和大家分享的这篇,原本是《重学安卓》付费专栏连载的第三篇,没想到在我这几天业余时间独立开发的小应用《JDGD》中,连续遇上了 7 处 “状态重建” 的场景!

考虑到我在 <掘金> 等热门技术社区 发文的目标是,提供 “从 0 到 1”、易于理解和贯通的 摆渡文,致力于为读者拨开迷雾、建立感性认识。

因而 原味的、硬核的、钻研细节的 文章,我多是在小众的付费技术社区发布。对此感兴趣的朋友请不要慌,文末链接给出 😉

JDGD 的页面结构是,最外层由一个 Activity 装载着一个 ContainerFragment,然后 ContainerFragment 中又装载了 3 个 ChildFragment。相当于是个 3 层嵌套页面结构。

用户平时可以操作的,就是在这 3 个 ChildFragment 之间来回切换。并且当发生旋转屏幕时,来自 3 个层次的 5 个页面都会发生重建。

这要是换做以前的话,我八成是会被难住,因为我司的产品,手机端是固定竖屏,平板端是固定横屏,即使开启了旋转屏幕模式,也不会走重建的流程,因而多年来我都没有钻研过这个问题。

并且,网络上关于重建的文章 多是人云亦云、含糊不清,并没有把最关键的细节给讲明白、讲透,导致我最开始也在 半吊子文章中 白费不少时间。

好在上上星期,我亲自复盘和实证了 “状态重建” 的知识点,于是这回遇上的几个问题,都是轻轻松松地得到化解 😉。

考虑到页面重建和状态管理,真的是每个人都必然会遇到的问题,于是我就 破例 地将 Activity 状态重建的知识,无保留地分享给大家。

已经付费的小伙伴们请不要担心,今天仅仅是通过介绍 Activity 的重建,来奠定对重建的认知基础,真正的好戏还在后头 ~

还没阅读过的小伙伴也不要着急,正由于今天讲的是基础,即使只看这篇,你也没有白来

前言

很高兴见到你!

上一期,我在发表的 《重学安卓:Activity 生命周期的 3 个辟谣》 中,通过介绍网上 99% 的文章都不曾解析过的 “进程模式”,来帮助大家深入理解 Activity 生命周期 的设计依据、存在意义 及 注意事项。

并且,文末我还针对网文的 3 个讹传,来给大家辟了谣。

相信经过这样一次介绍,你对生命周期拥有了相比其他人更加深刻的认识。😉

那么这一期,我们来结合现实的案例,来讲解一下 Activity 的重建机制。

文章目录一览

  • 前言
  • 因为心里没底,而不敢用的状态恢复
  • 什么是重建?引发重建的场景有哪些?
  • 为何要设计出重建的机制?有何好处?
  • 状态保存和恢复的具体过程?(99% 的网文遗漏的关键细节)
  • 状态保存和恢复的的注意事项?
  • 如何避免 “配置发生变化” 导致的重建?
  • 综上

因为心里没底,而不敢用的状态恢复

就在上周五,我司向客户推送了 App 新版本,原以为万事大吉,毕竟经过了一周的打磨,各项功能都已趋于流畅稳定,没想到,在客户近乎变态的数据操作下,有客户反映 “页面切换巨卡”、“速度巨慢”。

为何会产生这种情况呢?我找到编写该页面的同事询问了缘由。

同事说,问题在于每次 onPause 时,为了避免App 切到后台被系统回收导致数据丢失,而做了大量的数据持久化操作。

那为什么不直接通过 Activity 的状态管理机制 来管理临时数据呢?

同事说,那东西“不靠谱”,用着感觉心里没底。

…… 是网上介绍 Activity 重建流程和状态管理的文章不够多吗?不是的,网文都有提到:当发生重建时,就会走 onSaveInstanceState 和 onRestoreInstanceState,

然而却没有一篇深入地探究过:当走 onSaveInstanceState 和 onRestoreInstanceState 时,过程中究竟经历了哪些细节、背后 决定状态被成功保存和恢复的关键条件 到底是怎样的。

这使得读者在使用这个机制时忐忑不安,无法 100% 确定不会出事。

于是在经过源码分析和再三的实测检验后,我将 “重建机制” 及 “状态管理机制” 的内容整理成这篇文章。

如果阅读完本文后,你对二者的缘起、规律有了明确的认识,从而 100% 放心地在日后工作中使用,那我的这番功夫就没白费 ~

什么是重建?引发重建的场景有哪些?

正常的生命周期流程,是页面从正常创建到销毁全流程。

而重建流程,则是在特定条件下,引发页面被销毁,并再次被创建的流程。

通常是 “系统资源的回收” 或 “配置发生变化” 导致的重建

划重点 👆 👆 👆

系统资源回收是指:

当 App 处于背景模式时,可能因系统内存不足而被回收。

例如按下 Home 键切回桌面,或是接电话跳转到电话程序,都有可能使此前的这个 App 处于背景模式。

配置发生变化是指:

当系统配置发生变化时,比如屏幕方向、语言的改变。

为何要设计出重建的机制?有何好处?

一来: 对于资源回收的情况,保存状态并等到使用时再恢复,要比后台存留进程 所占的资源要小得多

二来: 对于配置变化的情况,比如当屏幕方向发生变化时,唯有重建,才有机会加载不同的视图,如果横竖屏的布局不同的话。

状态保存和恢复的具体过程?

首先,“状态” 是指支撑 UI 界面内容展示的临时数据。

比如 EditText 中的文本、CheckBox 的勾选与否。

有且只有引发重建时,Activity 会走 onSaveInstanceState 和 onRestoreInstanceState,来保存和恢复状态。

onSaveInstanceState 执行在 onStop 之前,onRestoreInstanceState 执行在 onStart 之后。

其次,Activity 有两个数据结构用于保存状态:

一个是 View States,专门用于存储 View 的状态;

再一个是 Instance States,用于存储 View States 以及 开发者在 onSaveInstanceState 中手动保存的 Activity 成员变量。

在引发重建时,Activity 会自动为我们保存和恢复 View 的状态。具体表现为:

Activity 在 onSaveInstanceState 时,会 自动收集 View Hierachy 中每一个 “实现了状态保存和恢复方法” 的 View 的状态,这些状态数据会在 onRestoreInstanceState 时回传给每一个 View。并且回传时是依据 View 的 id 来逐一匹配的。

划重点 👆 👆 👆

其中,View 的状态数据会被收集到 View States 中,View States 也会随着 Activity 中其他被指定收集的成员变量,一同被收集到 Instance States 中,等待恢复时逐个恢复。

状态保存和恢复的的注意事项?

简言之:

1.为了成功保存状态,要求在 View 内部实现状态保存和恢复方法

原生的 View 都有做到;如果是自定义 View,务必记住这一点;如果第三方 View 没做到,可以通过继承其来实现保存和恢复方法。

2.为了成功恢复状态,要求在布局中给 View 赋予相应的 id

划重点 👆 👆 👆

3.如果是 Activity 的成员变量,需要额外在 Activity(子类)中重写 onSaveInstanceState 和 onRestoreInstanceState 方法

注意:

Activity 中重写仅仅是为了额外地保存成员变量。重写方法时,记得要保留基类(super)的实现,Activity 正是在基类中完成 View 状态的保存和恢复

划重点 👆 👆 👆

如何避免 “配置发生变化” 导致的重建?

在清单文件中为该 Activity 配置 android:configChanges 属性。

比如属性值 orientation|screenSize 对应着旋转屏幕,locale 对应着语言变化。

如此,在配置发生变化时,不会导致重建,而是走 onConfigurationChanged 回调。

综上

只要遵循 《状态保存和恢复的的注意事项》一节所提到的关键细节,就能稳妥地保存和恢复状态。

你再也不用为了临时数据而在 onPause 或 onStop 中执行重量级的持久化存储操作啦!

xzl短

看不过瘾?这里只为你 而准备了一份 简洁有力的 《重学安卓》认知地图 😉

关注下面的标签,发现更多相似文章
评论