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 参数获取推送信息(键为 UIApplicationLaunchOptionsRemoteNotificationKeyUIApplicationLaunchOptionsLocalNotificationKey)。

  2. application:didFinishLaunchingWithOptions:

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

    示例:

    objective-c

    objectivec 复制代码
    - (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

    ini 复制代码
    NSURL *url = launchOptions[UIApplicationLaunchOptionsURLKey];
    if (url) {
        // 提前处理 URL 信息(可选)
    }
  2. application:didFinishLaunchingWithOptions:

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

    示例:

    objective-c

    objectivec 复制代码
    - (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

    objectivec 复制代码
    - (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,需解析 pageid 参数来决定跳转页面。
  3. iOS 13+ 适配
    若使用 UISceneDelegate,URL Scheme 唤醒逻辑会转移到 scene:openURLContexts: 方法中,流程类似但需适配场景生命周期。
相关推荐
2601_955767422 小时前
iPhone 17 护眼保护膜怎么选?圆偏振光 + AR 抗眩方案,解读 96% 透光率与 ≤0.5% 反射率的协同价值
ios·ar·iphone·圆偏振光·#观复盾护景贴·scinique双护技术
三雒2 小时前
KMP 实战:Android 开发如何快速统一双端 IM 模块
android·ios·kotlin
秋雨梧桐叶落莳3 小时前
iOS——抽屉视图详解
开发语言·macos·ui·ios·objective-c·cocoa
库奇噜啦呼4 小时前
【iOS】源码学习-方法交换
学习·ios·cocoa
hurrycry_小亦16 小时前
苹果WWDC 2026前瞻:Ferret-Pro端侧大模型即将亮相|小亦之闻|AI 编程三日速递!(5月26日~5月28日)
macos·ios·wwdc
UTF_819 小时前
一次NSMutableAttributedString误用的思考
ios·面试·github
人月神话-Lee1 天前
【图像处理】Core Image 与 GPU 渲染管线——让滤镜飞起来
图像处理·人工智能·ios·chatgpt·ai编程·swift·gpu
夏天的峰没有风1 天前
Typora+gitcode+picgo搭建免费图床
开发语言·ios·swift
库奇噜啦呼1 天前
【iOS】源码学习-分类、扩展、关联对象
学习·ios·分类
帅次2 天前
Android 17 开发者实战:核心更新与应用场景落地指南
android·java·ios·android studio·iphone·android jetpack·webview