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

前言

很高兴见到你!

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

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

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

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

文章目录一览

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

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

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

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

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

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

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

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

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

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

于是在经过源码分析和再三的实测检验后,我将 “重建机制” 及 “状态管理机制” 的内容整理成这篇文章,并且开源了全套测试代码(不要慌,文末链接给出)。

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

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

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

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

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

划重点 👆 👆 👆

系统资源回收是指:

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

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

配置发生变化是指:

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

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

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

top Created with Sketch.