这个问题我之前帮朋友排查过类似的，本质就是macOS的节能机制在后台对非活跃应用的RunLoop做了节流处理——当你的显示应用不在前台、没有用户交互时，系统会降低它的CPU优先级甚至暂停部分RunLoop活动来节省电量，这就导致了NSTimer的触发延迟，尤其是首次唤醒和长时间运行后的卡顿。

下面给你几个靠谱的解决方案，按推荐优先级排序：

1. 改用GCD内核定时器（最推荐） #

NSTimer依赖主RunLoop的运行状态，而GCD的定时器由系统内核直接管理，不受RunLoop模式和应用活跃状态的影响，稳定性高得多。

示例代码：

// 保存定时器引用，避免被释放
@property (nonatomic, strong) dispatch_source_t updateTimer;

// 初始化并启动定时器
- (void)startGCDTimer {
    // 创建定时器，绑定到主队列（确保UI更新在主线程）
    self.updateTimer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
    
    // 设置触发规则：立即启动，每0.2秒触发一次，容错范围0.1秒（允许系统微调）
    dispatch_source_set_timer(self.updateTimer, 
                              DISPATCH_TIME_NOW, 
                              0.2 * NSEC_PER_SEC, 
                              0.1 * NSEC_PER_SEC);
    
    // 设置触发回调
    dispatch_source_set_event_handler(self.updateTimer, ^{
        // 这里写你的时钟更新逻辑
        [self updateClockDisplay];
    });
    
    // 启动定时器
    dispatch_resume(self.updateTimer);
}

// 停止定时器
- (void)stopGCDTimer {
    if (self.updateTimer) {
        dispatch_cancel(self.updateTimer);
        self.updateTimer = nil;
    }
}

2. 申请后台活动权限，告诉系统你需要持续运行 #

如果一定要用NSTimer，可以让应用向系统申请后台活动权限，明确告知系统你的应用需要在后台持续执行任务（比如更新时钟），避免被过度节流。

步骤1：配置Info.plist #

添加NSBackgroundModes键，添加com.apple.background.processing值（表示应用需要后台处理能力）。

步骤2：使用NSBackgroundActivityScheduler调度任务 #

这个类是macOS专门用来处理后台重复任务的，能让系统合理分配资源：

@property (nonatomic, strong) NSBackgroundActivityScheduler *activityScheduler;

- (void)setupBackgroundActivity {
    self.activityScheduler = [[NSBackgroundActivityScheduler alloc] initWithIdentifier:@"com.yourcompany.displayapp.clockUpdate"];
    
    // 设置任务属性
    self.activityScheduler.repeats = YES;
    self.activityScheduler.interval = 0.2; // 任务间隔
    self.activityScheduler.qualityOfService = NSQualityOfServiceUserInteractive; // 高优先级，因为是用户可见的时钟
    self.activityScheduler.tolerance = 0.1; // 允许的时间误差
    
    // 设置任务回调
    __weak typeof(self) weakSelf = self;
    [self.activityScheduler setBlock:^(NSBackgroundActivityScheduler *scheduler) {
        dispatch_async(dispatch_get_main_queue(), ^{
            [weakSelf updateClockDisplay];
        });
        // 重新调度任务（因为repeats=YES，系统可能会自动调度，但手动调用更可靠）
        [scheduler schedule];
    }];
    
    // 启动任务
    [self.activityScheduler schedule];
}

3. 临时唤醒RunLoop（应急hack方案） #

如果上面两种方法暂时无法实现，可以用一个低频率的“心跳”定时器来保持RunLoop活跃，避免系统完全暂停它。这种方法不推荐长期使用，但能临时缓解问题：

// 添加一个每秒触发的空定时器
[NSTimer scheduledTimerWithTimeInterval:1 
                                 target:self 
                               selector:@selector(keepRunLoopAwake) 
                               userInfo:nil 
                                repeats:YES];

// 空实现，只是让RunLoop每隔1秒唤醒一次
- (void)keepRunLoopAwake {
    // 什么都不用做，只要这个定时器触发，RunLoop就会被唤醒
}

补充说明 #

• 你之前用[[NSRunLoop mainRunLoop] addTimer:_timer forMode:NSRunLoopCommonModes]能延缓问题，是因为NSRunLoopCommonModes包含了后台模式下的RunLoop模式，但还是逃不过系统的节能节流。
• 即使使用GCD或后台活动，系统在极端节能场景（比如低电量）下还是可能微调任务间隔，但相比NSTimer的6-10秒延迟，这种微调几乎可以忽略。

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