为何下拉通知中心时UIApplicationDelegate会收到applicationDidBecomeActive回调？

没错，你看到的这种applicationDidBecomeActive刚触发就立刻被applicationWillResignActive中断的情况，是iOS 11及后续版本的正常表现——和iOS 10.3的行为差异，是苹果调整了通知中心/控制中心交互时的应用生命周期回调逻辑导致的。

为什么会有这个变化？ #

在iOS 10及更早版本里，下拉通知中心会直接让应用进入非活跃状态，只触发applicationWillResignActive。但从iOS 11开始，系统会先短暂激活应用（触发applicationDidBecomeActive），紧接着又把它打回非活跃状态。这么做是为了支持通知中心和应用界面的部分交互能力，比如富通知的交互操作、3D Touch预览等，需要应用先快速完成UI状态更新，再进入后台交互模式。

怎么解决你的重操作被中断的问题？ #

既然你在applicationDidBecomeActive里的大量操作会被这种短暂激活打断，建议你调整任务的触发逻辑：

• 把重操作移到applicationWillEnterForeground：这个回调只会在用户主动把应用从后台切到前台时触发，不会被通知中心/控制中心的操作触发，完全适合执行需要持续完成的恢复任务。
• applicationDidBecomeActive只做轻量工作：比如刷新UI状态、恢复暂停的动画、重置计时器这类即使被快速中断也不会出问题的操作。
• 加个“激活时长判断”兜底：如果必须在applicationDidBecomeActive里处理任务，可以记录回调触发的时间，在applicationWillResignActive时检查激活时长，如果短于200ms左右，就取消或回滚正在执行的重操作。

给你个Objective-C的简单示例参考：

@property (nonatomic, strong) NSDate *activeStartTime;

- (void)applicationDidBecomeActive:(UIApplication *)application {
    self.activeStartTime = [NSDate date];
    // 先做轻量的UI刷新
    [self refreshAppUIState];
    
    // 延迟一点再判断是否执行重操作，避免短暂激活的干扰
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        if ([UIApplication sharedApplication].applicationState == UIApplicationStateActive) {
            // 确认应用确实处于稳定的活跃状态，再执行重操作
            [self performHeavyForegroundTasks];
        }
    });
}

- (void)applicationWillResignActive:(UIApplication *)application {
    NSTimeInterval activeDuration = [[NSDate date] timeIntervalSinceDate:self.activeStartTime];
    if (activeDuration < 0.2) {
        // 属于短暂激活，取消正在执行的重操作
        [self cancelHeavyTasks];
    }
}

关于苹果文档的补充说明 #

苹果文档里提到用applicationDidBecomeActive重启任务，是针对应用真正从后台切换到前台、或者从锁屏状态恢复的场景，并不包含这种系统触发的短暂激活情况。所以你需要结合不同的生命周期回调，区分场景来处理任务，避免被这种特殊情况干扰。

内容的提问来源于stack exchange，提问作者Anthony Wieser