UIApplicationDelegate执行说明

在 iOS 应用的生命周期中，UIApplicationDelegate 方法的执行顺序与应用的状态变化密切相关。以下是典型场景下的方法调用顺序：

一、应用启动过程（冷启动）

1. application:willFinishLaunchingWithOptions:
   最早被调用，此时应用刚完成初始化，还未加载 UIWindow 和根视图控制器。可在此做一些早期初始化工作。
2. application:didFinishLaunchingWithOptions:
   应用完成基本启动，UIWindow 已初始化，但尚未显示。通常在此设置根视图控制器、初始化第三方框架等，返回 YES 表示允许应用启动。
3. applicationDidBecomeActive:
   应用从 "非活跃" 状态切换到 "活跃" 状态，此时用户可以交互。启动完成后会最终进入此状态。

二、应用进入后台

1. applicationWillResignActive:
   应用即将失去焦点（如来电、下拉通知中心），进入 "非活跃" 状态。需暂停正在进行的任务（如游戏逻辑、视频播放）。
2. applicationDidEnterBackground:
   应用完全进入后台。需保存数据、释放内存，若需后台运行（如下载），需在此申请后台任务标识符。

三、应用从后台返回前台

1. applicationWillEnterForeground:
   应用即将从后台回到前台，仍处于 "非活跃" 状态。可恢复数据、重新初始化界面。
2. applicationDidBecomeActive:
   应用完全激活，用户可再次交互。需恢复之前暂停的任务。

四、应用终止

1. applicationWillTerminate:
   应用即将被终止（如用户强制关闭、系统内存不足）。仅在此做最后的数据保存，无法执行耗时操作。

简化流程图

plaintext

冷启动 → willFinishLaunching → didFinishLaunching → didBecomeActive（活跃状态）

活跃 → willResignActive → didEnterBackground（后台状态）

后台 → willEnterForeground → didBecomeActive（回到活跃）

终止 → willTerminate

注意事项

• 不同场景（如通过推送启动、从后台被系统杀死后重启）可能触发部分方法的差异。

• didFinishLaunchingWithOptions: 的 launchOptions 参数可获取启动原因（如点击推送、URL Scheme 唤醒）。

• iOS 13+ 后，基于 UISceneDelegate 的场景生命周期逐渐替代传统 UIApplicationDelegate，但核心状态切换逻辑类似。

理解这些顺序有助于合理安排初始化、资源管理和状态恢复的代码逻辑。

推送启动的怎么执行

当应用通过推送通知（远程推送或本地推送）启动时，UIApplicationDelegate 方法的执行顺序与普通冷启动基本一致，但会在启动参数中携带推送相关信息。具体流程如下：

一、推送启动的完整执行顺序

1. application:willFinishLaunchingWithOptions:

   最早被调用，此时可通过 launchOptions 参数获取推送信息（键为 UIApplicationLaunchOptionsRemoteNotificationKey 或 UIApplicationLaunchOptionsLocalNotificationKey）。

2. application:didFinishLaunchingWithOptions:

   核心启动方法，launchOptions 参数会包含推送数据 ，需在此处理推送相关逻辑（如跳转指定页面、展示推送内容）。

   示例：

   objective-c

   - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
       // 检查是否通过远程推送启动
       NSDictionary *remoteNotification = launchOptions[UIApplicationLaunchOptionsRemoteNotificationKey];
       if (remoteNotification) {
           // 处理推送逻辑，如跳转页面
           [self handlePushNotification:remoteNotification];
       }
       return YES;
   }

3. applicationDidBecomeActive:

   应用完全激活后调用，若有需要在前台展示的推送相关 UI（如弹窗），可在此处理。

二、特殊情况：应用已在后台运行时收到推送

若应用处于后台而非完全关闭状态，点击推送启动时：

1. 先调用 application:didReceiveRemoteNotification:fetchCompletionHandler: （远程推送）或 application:didReceiveLocalNotification:（本地推送），获取推送数据。
2. 接着执行：
   applicationWillEnterForeground: → applicationDidBecomeActive:
   可在这两个方法中处理前台展示逻辑（如从后台切换到前台时的页面跳转）。

三、关键区别

• 冷启动（应用完全关闭） ：推送信息仅在 launchOptions 中传递，需在 didFinishLaunchingWithOptions: 中处理。

• 后台运行时 ：推送信息通过 didReceiveRemoteNotification: 等方法直接传递，无需依赖 launchOptions。

通过判断启动参数和应用状态，可区分 "点击推送启动" 和 "普通启动"，从而执行对应的业务逻辑（如根据推送内容跳转到特定页面）。

URL Scheme 唤醒的怎么执行

当应用通过 URL Scheme 唤醒时（例如从其他应用或浏览器点击自定义链接打开），UIApplicationDelegate 方法的执行顺序会根据应用当前状态（未启动 / 已在后台）有所不同，核心是通过特定方法接收 URL 信息。

一、应用完全关闭时（冷启动通过 URL Scheme 唤醒）

此时执行顺序与普通冷启动类似，但会在启动参数中携带 URL 信息：

1. application:willFinishLaunchingWithOptions:

   最早被调用，可通过 launchOptions 获取唤醒的 URL：

   objective-c

   NSURL *url = launchOptions[UIApplicationLaunchOptionsURLKey];
   if (url) {
       // 提前处理 URL 信息（可选）
   }

2. application:didFinishLaunchingWithOptions:

   核心启动方法，必须在此处理 URL 逻辑 （如解析 URL 参数、跳转对应页面）。

   示例：

   objective-c

   - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
       // 初始化窗口和根控制器（必需步骤）
       self.window = [[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds];
       self.window.rootViewController = [[UINavigationController alloc] initWithRootViewController:[[HomeViewController alloc] init]];
       [self.window makeKeyAndVisible];
       
       // 检查是否通过 URL Scheme 启动
       NSURL *url = launchOptions[UIApplicationLaunchOptionsURLKey];
       if (url) {
           [self handleURLScheme:url]; // 解析 URL 并处理（如跳转页面）
       }
       return YES;
   }

3. application:openURL:options:

   在 didFinishLaunchingWithOptions: 之后调用，再次传递 URL 信息 （建议在此统一处理，更规范）。

   示例：

   objective-c

   - (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
       // 统一处理 URL Scheme
       return [self handleURLScheme:url];
   }

4. applicationDidBecomeActive:

   应用激活后调用，可执行后续操作（如刷新页面数据）。

二、应用已在后台运行时（通过 URL Scheme 唤醒）

此时应用无需重新初始化，直接从后台切换到前台，执行顺序：

1. applicationWillEnterForeground:
   应用即将从后台进入前台。
2. application:openURL:options:
   核心方法，接收并处理唤醒的 URL（解析参数、跳转页面等）。
3. applicationDidBecomeActive:
   应用完全激活，完成后续交互逻辑。

三、关键说明

1. URL 处理的最佳实践 ：
   无论应用是冷启动还是后台唤醒，application:openURL:options: 都会被调用，建议在此方法中统一处理 URL 解析逻辑，避免代码冗余。
2. URL 格式示例 ：
   假设自定义 Scheme 为 myapp，唤醒链接可能为 myapp://page/detail?id=123，需解析 page 和 id 参数来决定跳转页面。
3. iOS 13+ 适配 ：
   若使用 UISceneDelegate，URL Scheme 唤醒逻辑会转移到 scene:openURLContexts: 方法中，流程类似但需适配场景生命周期。