在开发者选项里,叫“不保留活动”。
官方描述写得很短:
Destroy every activity as soon as the user leaves it.
用户离开,立刻销毁。
这个"立刻"是关键词。
它不挑场景。切到后台,销毁。跳转到下一个页面,也销毁。按返回键退出去,还是销毁。
任何形式的"离开",都触发同一个结果:当前页面被系统直接干掉。
等你再回到这个页面,一切都是重新开始的。
我第一次打开这个开关,是在调试一个列表详情页。
列表页展示了一堆商品,我滑到中间位置,点进详情。
看完详情,按返回键回来。
列表回到了顶部。
我当时以为是网络请求重新加载了。
后来才知道是页面本身被重建了——每次跳转,列表页都被系统销毁,返回时重新创建。
那个滚动位置,根本没机会保留。
同样的,返回后页面闪一下然后开始重新加载,
最开始我还当成了一个bug去提。
这个开关打开之后,页面跳转的性质变了。
正常情况下的跳转:A启动B,A进入后台但还活着,只是看不见了。从B返回,A从后台切回来,状态都在。
打开开关后的跳转:A启动B,A被直接杀死,彻底销毁。从B返回,A重新创建,所有东西从头加载。
普通用户不会遇到前者吗?会的——当系统内存紧张时,后台的A确实可能被回收。
但那是偶发的。
而打开这个开关,每一次跳转都在模拟那种极端情况。
每一次返回,都是一次冷启动。
我后来养成了一个习惯。
拿到一个新的测试版本,先去开发者选项里打开"不保留活动"。
然后不做任何特殊操作,就正常地用。
点进一个页面,返回。再点进另一个,再返回。
有时候在列表页和详情页之间来回跳转,反复十几次。
看滚动位置还对不对。看筛选条件还在不在。看表单里的输入内容丢没丢。
这些场景很普通,普通到几乎所有用户都会遇到。
但在这个开关下,它们变成了压力测试。
从测试的角度来看,这个功能的作用很具体。
第一,暴露跳转链路中的状态盲区。
页面与页面之间传递的数据,哪些用Intent传了,哪些用全局变量存了,哪些根本没存。
跳转一次,回来。没存的东西就没了。
第二,检验重建逻辑的完整性。
Activity重建时走onCreate(),这里面的初始化代码,和首次创建时是不是同一套。
如果是,那没问题。如果依赖了某些只在首次创建时才有的条件,空指针就来了。
第三,发现Fragment附着时机的问题。
宿主Activity重建时,Fragment也会重新附着。如果Fragment在onCreate()里就尝试访问宿主的方法,而宿主还没准备好,就会崩溃。
这个场景在普通测试里很难触发,在这个开关下,每次返回都触发。
我现在不把"不保留活动"当成一个"测试技巧"来看。
它更像是把安卓系统的一种底层行为,强制提到了前台。
系统本来就会销毁后台Activity,只是用户看不见。
这个开关让用户看见了——开发者看见,测试工程师看见。
看见了,才能去处理。
这个开关在开发者选项里躺了很多年。
大部分用户不知道它,大部分测试工程师也不常用它。
但它一直在那里。
有时候也会感叹安卓生态系统的强大。赞美!