Android:Activity生命周期事件的几个小细节

Activity跳转生命周期事件您清楚吗?

最近在面试的过程中,发现一些小朋友对Activity生命周期事件掌握的还不是特别牢固。当然,这里我指的不是单个Activity的生命周期事件,而是从一个Acitivty跳转到另外一个Activity的时候,2个Activity的生命周期事件是按照什么顺序发生的。

单个Activity的生命周期事件

这个大家都知道,在这里就简单列一下:

Activity启动的时候:onCreate() -> onStart() -> onResume()
Activity退出的时候:onPause()-> onStop()-> onDestroy()

从ActivityA跳转到ActivityB的生命周期事件

如果两个Activity事件搅和在一起,您能确定它们的事件顺序吗?

首先,看看从ActivityA跳转到ActivityB的事件:


从ActivityA跳转到ActivityB的事件

通过上图可以清晰的看到,当从ActivityA跳转到ActivityB的的时候,首先执行的是ActivityA的onPause()方法,然后是ActivityB的一系列生命周期方法,最后再是ActivityA的onStop()方法。ActivityA的onDestroy()方法不会被调用。

看看用户从ActivityB返回ActivityA的情况:


从ActivityB返回ActivityA

ActivityB的onPause()方法先被调用,然后是ActivityA的生命周期方法,当ActivityA的onResume()执行之后,ActivityB的onStop()onDestroy()会被调用。

生命周期事件背后的设计思想

其实,要记住以上事件的顺序不是什么难事。但是重要的是,我们需要考虑:Android为什么会这样设计?

为什么不管是跳转还是返回,都是当前Activity的onPause()方法先被调用?

为什么不管是跳转还是返回,前一个Activity的onStop()方法总是在新的Activity的onResume()方法后被调用?

其实,这背后隐藏着一个重要的Android设计思想:在任何时候,都是UI优先。保证用户体验永远是第一位的。

以跳转为例,当Activity发生跳转的时候,第一个事件肯定是要交给当前处于前台的ActivityA,这样可以保证UI事件可以第一时间执行。然后,再执行ActivityB的生命周期事件,当ActivityB已经出现在前台之后,再调用ActivityA的onStop()方法,因为此时ActivityA已经在后台了,所以onStop()不会影响到前台的用户体验。

onPause()和onStop()的区别

在日常开发中,很多同学对这两个方法都是混着用的,没有想的特别清楚。实际上,根据上面的分析,这两个方法还是有一定区别的:

首先,onPause()方法是跳转前的第一个方法,所以在这个方法里面一定不能做耗时的操作,否则会影响下一个Activity的出现,让用户觉得不流畅。

而ActivityA的onStop()方法被调用的时候,ActivityB已经在前台了,所以可以在onStop()方法里做一些清理的工作,不会影响到用户的体验。

onSaveInstanceState()方法的调用时机

Android里onSaveInstanceState()的调用时机也是让人比较困惑的事情。首先,onSaveInstanceState()并不是Activity的生命周期方法,这意味着这个方法不是总会被调用的。只有在Activity可能会被系统销毁的时候才可能被调用。

拿上面的例子来说,从ActivityA跳转到ActivityB,ActivityA被压在ActivityB下面,这种情况可能会被系统销毁,所以onSaveInstanceState()会被调用。如果在ActivityB的页面里用户按Home退出,onSaveInstanceState()也是会被调用的。

相反的,如果用户在ActivityB页面按Back键返回ActivityA,此时,ActivityB的onSaveInstanceState()是不会被调用的。

再说从ActivityA跳转到ActivityB的时候,还有个很奇怪的情况:

在Android P之前,ActivityA的onSaveInstanceState()是在onStop()之前被调用的,而且和ActivityA的onPause()的调用谁先谁后不确定!

在Android P及之后,onSaveInstanceState()是在onStop()之后被调用的。

下面是官方的解释:

If called, this method will occur after onStop() for applications targeting platforms starting with Build.VERSION_CODES.P. For applications targeting earlier platform versions this method will occur before onStop() and there are no guarantees about whether it will occur before or after onPause().

总结

Android的生命周期方法,其实是很基础的知识。但是细抠的话,还是有不少细节的。

最后,还是拿这张大家都看过的图来镇楼:


Activity的生命周期
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 156,907评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,546评论 1 289
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,705评论 0 238
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,624评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,940评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,371评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,672评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,396评论 0 195
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,069评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,350评论 2 242
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,876评论 1 256
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,243评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,847评论 3 231
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,004评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,755评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,378评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,266评论 2 259

推荐阅读更多精彩内容