activity生命周期(二)

  • activity的生命周期分两种情况,一种的正常情况下的生命周期,一种是异常情况下的生命周期,而异常情况通常是指activity被系统回收或者系统配置发生改变而导致activity被销毁重建,比如屏幕的翻转。

正常情况下的生命周期

activity的生命周期

一个activity有四种状态,7个方法。四种状态是运行、暂停、停止、不存在状态,7个方法是:

  • onCreate():表示activity正在创建,此时系统内存中有activity的实例,这是生命周期中的第一个方法,在这个方法中我们可以做一些初始化,比如使用setContentView()去加载界面布局资源,初始化activity所需要的数据。
  • onRestart():表示activity重新启动,当activity停止后但并没有销毁时再次启动时,也就是当activity由不可见状态变为可见状态时,就会调用这个方法。
  • onStart():表示activity正在被启动,这时候的activity就可见了,但是却不能操作,不能与用户进行交互。
  • onResume():表示activity已经可见并且可以在前台和用户进行交互了,这与上面的onStart()方法的相同之处就是都可见,不同之处就是onStart()中activity是不在前台的,不能与用户进行交互,而在onResume()中,activity是在前台的,可以与用户进行交互。
  • onPause():表示暂停activity,一般在正常的情况下,紧接着会调用onStop()方法,这时activity又变为可见但不能交互的情况了,与onResume()是相对应的。
  • onStop():表示停止activity,这时activity会变为不可见的状态,但是activity的实例还在系统内存中的,在这个方法中,我们可以做一些轻量级的回收工作,不能做一些耗时的事情。
  • onDestroy():表示activity正在被销毁,这时activity即不可见并且系统内存中也没有了activity的实例了,这时activity生命周期中的最后一个回调,在这里,我们可以做一些自愿的额释放和回收工作。

activity的启动原理:启动一个activity的请求会由Instrumentation来处理,然后它通过Binder向AMS(ActivityManagerService)发送请求,AMS内部维护着一个ActivityStack并负责栈内的Activity的状态同步,AMS通过ActivityThread去同步activity的状态从而完成生命周期方法的调用。

异常情况下的生命周期

activity除了正常情况下的生命周期,还有异常情况的下的生命周期,其生命周期与正常生命周期有些许的不一样。从以下两种情况分析异常情况下的生命周期:

资源相关的系统配置发生改变导致activity被杀死并重建

比如在横竖屏切换的时候,由于资源要重新配置,在默认的情况下,activity会被销毁并且重建。

当系统配置发生改变后,activity会被摧毁,其中会调用onPause、onStop、onDestroy方法,同时,由于activity是异常终止的,系统会调用onSaveInstanceState来保存当前activity的状态,这个方法在onStop之前调用,既可以在onPause之前调用。也可以在onPause之后调用,这个方法只出现在activity异常终止的情况下,当activity又重新创建后,系统又会调用onRestoreInstanceState,并且将onSaveInstanceState保存的Bundle对象作为参数传递给onRestoreInstanceState方法和onCreate()方法,通过后面这两个方法可以判断activity是否被重建了,如果是重新建立的,那么Bundle对象就不为空,如果是新建的activity,那么Bundle对象就为null,重建的onRestoreInstanceState方法调用在onStart方法之后。在activity正常销毁的时候是不会调用onSaveInstanceState方法的,只有在activity异常终止并重建的时候才调用onSaveInstanceState和onRestoreInstanceState来存储和恢复数据

  • 如果当系统的资源配置发生改变时,不想重建activity,可以在AndroidMenifest.xml文件中给activity声明属性:
android:configchanges="orientation"

保存和恢复View层次结构,系统的工作流程

  • activity异常终止时,系统调用onSaveInstanceState方法去保存数据
  • 然后activity委托window去保存数据
  • 接着window再委托它上面的顶级容器去保存数据,(顶级容器是一个ViewGroup)
  • 顶级容器再通知子元素去保存数据

2.资源内存不足导致低优先级的activity被杀死

activity的优先级由高到低可以分为3种:

  1. 前台activity——优先级最高
  2. 可见但非前台activity——优先级次高
  3. 后台activity(不可见)——执行了onStop方法,优先级最低

当内存不足时,系统会按照优先级的高低去杀死目标activity所在的进程,如果一个进程中没有四大组件在执行,那么这样的进程很容易被杀死,一般比较好的方法是将后台工作放在四大组件中的Service中从而保证了进程有了一定的优先级,就不会轻易被系统给杀死了。

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