iOS App Life Circle

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/Q52077987/article/details/82688763

一个iOS App有以下五个状态:
这里写图片描述

需要注意的是Inactive 状态,常常被忽略,App被切换到后台时,并不是直接进入Background状态,而是有一个Inactive状态,同样一个App启动后,也要经过Inactive状态过渡。

系统状态的转换不能通过代码控制,只能通过用户操作由iOS系统控制。但是可以通过代码在状态转换的时候获取回调消息。这些回调函数都在AppDelegate中。

Launch

一个App启动有很多原因,可能是用户点击图标启动,也可能是用户点击推送,或者是URLSchema或者Universe Link调起,3D-Touch的Menu被点击等,App被启动的原因在Options中保存。无论通过哪种方式启动,都会执行以下两个回调。

application:willFinishLaunchingWithOptions: 
application:didFinishLaunchingWithOptions:

这两个回调是App启动时最早的两个回调。其中will函数回调的时候App处于Inactive状态,main storyboard已经加载,但是App的状态恢复还没进行(关于App的状态恢复技术,参见:state restoration)。因此will函数的一个用途就是配合启动参数,决定是否要恢复App状态。

This method is called after your app has been launched and its main storyboard or nib file has been loaded, but before your app’s state has been restored. At the time this method is called, your app is in the inactive state.

did函数的调用在state restoration之后,在App的主界面显示之前。这里是最后处理启动的Options的地方。为什么这么说呢?will函数和did函数的返回值是一个BOOL类型,如果两个函数返回值都是YES,或者其中一个函数没有实现,另外一个函数返回的是YES,那么接下来的Options处理函数将会被调用,只要有一个是NO,Options处理就不会调用。什么是Options的处理函数?比如,App是因为URL Schema调起的,则接下来会调用

application:openURL:options:

如果App是因为Home screen quick action被调起的,会调用:

application:performActionForShortcutItem:comletionHandler:

App被启动的原因在Options中保存,如果在will函数和did函数的分析中,决定不处理这个启动Options,则返回NO(系统正常启动)。但是推送的启动处理不受这两个返回值的影响。

启动流程:
这里写图片描述

总结一下,will函数和did函数都是App启动过程中的回调,区别是state restoration是否已经执行,如果App没使用state restoration技术,可以只写did函数。will函数和did函数都可以决定是否处理启动的Options,如果不处理,返回NO。只有did函数执行完之后,App主界面才会显示,因此,will函数和did函数中除了UI的操作,其他任务都应该使用异步,避免启动时间过长。

Activation

这个过程就是从Inactive到Active状态的过程,或者从background到Active过程,这个过程有两个回调函数:

applicationWillEnterForeground:
applicationDidBecomeActive:

如果程序在background状态,会先调用willEnterForeground函数,然后再调用didBecomeActive。如果程序是新启动的,则直接调用didBecomeActive。

App只有在Active状态才能执行dispatch_queue中的任务,改变UI,设置定时器等。

Deactivation & Background

这个过程是App从Active到Inactive的过程,这个状态变化可能是因为用户按了home键,或者应用程序进行了切换,还有电话打进来。

注意App可以从Background状态直接到Active状态,但是回到Background状态必经Inactive状态。

applicationWillResignActive:
applicationDidEnterBackground:

App先进入Inactive状态,然后过一段时间进入Background状态。这个两个回调分别会被调用。

Apple的文档建议开发者,在程序进入Inactive状态的时候:

  • 将用户数据保存到硬盘上,比如用户填了一半的表单。关闭打开的文件。
  • 不要进行关键的数据运算
  • 取消timers
  • 停止gameplay。

当进入Background状态的时候:

  • 隐藏敏感界面,比如银行的App都会将UI做模糊处理,保护隐私。否则应用程序的snapshot可能会泄漏数据。
  • 释放系统资源比如摄像头,数据库。如果不这样做,稍后App进入Suspend状态的时候会被系统直接杀掉。系统在杀掉应用的时候优先选择内存占用大的。
  • 取消Bonjour相关的服务。
  • 释放图片,媒体和临时对象。

App进入Background状态之后,系统会截一张图作为snapshot,也就是双击home键之后的应用程序切换界面使用的那张。

Suspend & Termination

应用程序进入Suspend状态并没有回调,当系统将要杀死程序的时候会回调

- (void)applicationWillTerminate:(UIApplication *)application;

系统会给这个方法大约5秒钟的时间执行,这是开发者最后处理一些事情的机会。比如可以在UserDefault中保存一些Flag,或者打个点(非网络请求的)。

Notification

除了在AppDelegate的回调中可以处理状态转移事件,还可以通过监听通知的方式来处理状态转移。

  • UIApplicationDidFinishLaunchingNotification 在 application:didFinishLaunchingWithOptions:方法返回之后发出。launchOptions的参数也都在Notification的userInfo中可以找到。
  • UIApplicationWillEnterForegroundNotification 在applicationWillEnterForeground:之后发出
  • UIApplicationDidBecomeActiveNotification 在 applicationDidBecomeActive:之后发出
  • UIApplicationWillResignActiveNotification 在 applicationWillResignActive:之后发出
  • UIApplicationDidEnterBackgroundNotification 在UIApplicationDidEnterBackgroundNotification:之后发出
  • UIApplicationWillTerminateNotification在applicationWillTerminate:之后发出

官方文档:Managing Your App’s Life Cycle

猜你喜欢

转载自blog.csdn.net/Q52077987/article/details/82688763