关于安卓活动的生命周期

Android的活动是层叠的,每启动一个新的活动,就会覆盖在原活动之上(类似于iOS的push,后进先出),按下Back键,移除栈顶的活动,显示下面的活动.

Android使用(Task)来管理活动,一个任务就是一组活动的集合,这个栈被称为返回栈(Back Stack).(恰恰iOS也是如此,push的界面也是以数组进行存储的).

Android点击Back键,调用finish( )方法,销毁当前栈顶活动.iOS则为调用pop方法,移除当前控制器.

Android活动.png

活动状态
先来下iOS的:
Not running:未运行,程序没启动 Inactive:未激活,程序在前台运行,不过没有接收到事件。在没有事件处理情况下程序通常停留在这个状态 Active:激活,程序在前台运行而且接收到了事件。这也是前台的一个正常的模式 Backgroud:后台,程序在后台而且能执行代码,大多数程序进入这个状态后会在在这个状态上停留一会。时间到之后会进入挂起状态(Suspended)。有的程序经过特殊的请求后可以长期处于Backgroud状态 Suspended:挂起,程序在后台不能执行代码。系统会自动把程序变成这个状态而且不会发出通知。当挂起时,程序还是停留在内存中的,当系统内存低时,系统就把挂起的程序清除掉,为前台程序提供更多的内存。
然后是Android的:
Running state:位于返回栈顶部的活动处于运行状态.系统对于运行状态的活动,很不乐意回收.因为这会产生很不好的用户体验. Hold state:当一个活动不再处于栈顶位置,但仍然可见时,这时活动就进入了暂停状态.(只要活动不会占满整个屏幕,处于暂停状态的活动就是存活的,因为它存活,系统也不乐意去回收,糟糕的用户体验). Stop state:当活动不再处于栈顶,而且完全不可见时,就进入了停止状态.系统仍会为这种活动保存响应的状态和成员变量.但这是不稳定的,因为,当其他地方需要内存时,这种活动就会被回收. Destruction of state:当一个活动从返回栈中移除后就变成了销毁状态,系统最喜欢回收这种状态的活动,因为这并不会带来糟糕的用户体验.
对比发现,没错,Android有点小坑了.处于停止状态的活动,有被回收的风险.这里就没有iOS的push好了.

活动的生存期
Activity类中定义了七个回调方法,覆盖活动生命周期的每一个环节: onCreat( ):活动第一次被创建的时候调用.在这里,我们会完成活动的初始化操作,例如加载布局,绑定事件等. onStart( ):活动由不可见变为可见的时候调用. onResume( ):活动准备好和用户进行交互的时候调用.此时的活动一定是位于栈顶,并处于运行状态.(能与用户交互,首先要用户看得到界面). onPause( ):系统准备去启动或者恢复另一个活动的时候调用.通常在这个时候,我们会将一些消耗CPU的资源释放掉,以及保存一些关键数据,但这个方法一定执行要快(执行要快?要快?要快?有安卓大神可以解释一下吗?),不然会影响到栈顶活动的使用. onStop( ):活动完全不可见的时候调用.和上面方法不同的是,如果启动的新活动是一个对话框形式的活动,那么onPause( )方法就会被执行,而onStop( )方法并不会执行.(请联系上文的暂停状态). onDestory( ):活动被销毁之前调用,之后活动的状态将变为销毁状态. onRestart( ):活动由停止状态变为运行状态之前调用,也就是活动被重新启动了.

根据上述七个方法,除onRestart()以外,均为两两相对,又可以将活动分为3种生存期:
完整生存期:活动处于onCreat()方法和onDestory()之间,就是完整生存期.一个活动会在onCreat()中完成各种初始化操作,而在onDestory()中完成释放内存的操作. 可见生存期:活动在onStart()和onStop()之间经历的,就是可见生存期.在此期间,活动对于用户总是可见的,即便有可能无法和用户进行交互.我们可以通过这两个方法,合理地管理那些对用户可见的资源.可以在onStart()方法中,对资源进行加载,而在onStop()中进行释放,以保证处于停止状态的活动不会占用过多内存. 前台生存期:活动在onResume()方法和onPause()方法之间所经历的就是前台生存期.在前台生存期内,活动总是处于运行状态的,此时的活动是可以和用户进行交互的,我们平时看到和接触最多的也就是这个状态下的活动.

活动的生命周期.jpg

iOS的控制器:
当一个视图控制器被创建,并在屏幕上显示的时候。 代码的执行顺序 1、 alloc 创建对象,分配空间 2、init (initWithNibName) 初始化对象,初始化数据 3、loadView 从nib载入视图 ,通常这一步不需要去干涉。除非你没有使用xib文件创建视图 4、viewDidLoad 载入完成,可以进行自定义数据以及动态创建其他控件 5、viewWillAppear 视图将出现在屏幕之前,马上这个视图就会被展现在屏幕上了 6、viewDidAppear 视图已在屏幕上渲染完成 当一个视图被移除屏幕并且销毁的时候的执行顺序,这个顺序差不多和上面的相反 1、viewWillDisappear 视图将被从屏幕上移除之前执行 2、viewDidDisappear 视图已经被从屏幕上移除,用户看不到这个视图了 3、dealloc 视图被销毁,此处需要对你在init和viewDidLoad中创建的对象进行释放
两者对比下,个人感觉iOS的更清晰明了.暂时先写到这里,接下来会对不清楚的细节,进一步研究下.

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

推荐阅读更多精彩内容