SwiftUI视图后台处理：定时轮询任务最佳实现方案咨询

首先给出两个核心判断的明确结论：

• 视图层仅负责状态绑定与UI渲染，不承载长期运行的业务逻辑，这个理解完全正确，也是SwiftUI官方推荐的数据流设计原则。
• 把轮询逻辑放在AppDelegate的didFinishLaunchingWithOptions里不是最优方案，属于UIKit时代的兼容写法，SwiftUI下有更符合架构设计的实现方式。

之前Timer方案失效的原因 #

SwiftUI的视图是值类型，会随着界面状态变化（全屏切换、导航栈进出、应用前后台切换）频繁重建销毁，和应用本身的生命周期并不同步：

• 你只监听了进入后台事件调用invalidate()销毁timer，但没有监听应用返回前台的事件重启timer，自然从后台切回后定时任务不会恢复。
• 用@State持有timer会随着视图重建被反复初始化、销毁，很容易出现timer泄漏、重复创建、提前失效的问题。
• 额外提醒：不要用UserDefaults做应用内状态同步，UserDefaults的设计定位是存储轻量用户偏好，频繁读写不仅有额外性能开销，也不具备状态订阅能力，视图无法自动响应数据变化。

最佳实现方案 #

推荐用单例形态的全局可观察状态管理器封装所有轮询逻辑，完全和视图层解耦，满足你“仅首次启动创建一次、前台运行、后台暂停、不重复创建”的全部需求：

1. 新建PlaybackStateManager类，统一管理轮询逻辑、生命周期监听、播放状态对外分发：

import SwiftUI
import MediaPlayer

class PlaybackStateManager: ObservableObject {
    static let shared = PlaybackStateManager()
    private var playbackTimer: Timer?
    
    // 对外暴露的可观察播放状态，视图绑定后会自动刷新
    @Published var currentTrack: MPMediaItem?
    @Published var currentPlaybackTime: TimeInterval = 0
    
    private init() {
        // 内部自行监听应用前后台事件，管理timer启停
        NotificationCenter.default.addObserver(
            self,
            selector: #selector(handleEnterBackground),
            name: UIApplication.didEnterBackgroundNotification,
            object: nil
        )
        NotificationCenter.default.addObserver(
            self,
            selector: #selector(handleEnterForeground),
            name: UIApplication.willEnterForegroundNotification,
            object: nil
        )
        // 初始化时应用处于前台，直接启动轮询
        startPolling()
    }
    
    @objc private func handleEnterBackground() {
        stopPolling()
    }
    
    @objc private func handleEnterForeground() {
        startPolling()
    }
    
    private func startPolling() {
        // 先销毁已有timer，避免重复创建
        stopPolling()
        playbackTimer = Timer.scheduledTimer(withTimeInterval: 5, repeats: true) { [weak self] _ in
            guard let self = self else { return }
            // 此处替换为你实际的获取当前播放歌曲逻辑
            let systemPlayer = MPMusicPlayerController.systemMusicPlayer
            self.currentTrack = systemPlayer.nowPlayingItem
            self.currentPlaybackTime = systemPlayer.currentPlaybackTime
        }
        // 将timer加入common模式，避免列表滚动等交互时timer暂停
        if let validTimer = playbackTimer {
            RunLoop.main.add(validTimer, forMode: .common)
        }
    }
    
    private func stopPolling() {
        playbackTimer?.invalidate()
        playbackTimer = nil
    }
    
    deinit {
        NotificationCenter.default.removeObserver(self)
    }
}

2. 在应用入口注入全局状态实例：

@main
struct MusicPlayerApp: App {
    @StateObject private var playbackManager = PlaybackStateManager.shared
    
    var body: some Scene {
        WindowGroup {
            MediaPlayerView()
                .environmentObject(playbackManager)
        }
    }
}

3. 视图层只需要绑定状态即可，不需要写任何业务逻辑、生命周期监听代码：

struct MediaPlayerView: View {
    @EnvironmentObject private var playbackManager: PlaybackStateManager
    
    var body: some View {
        VStack(spacing: 8) {
            if let track = playbackManager.currentTrack {
                Text(track.title ?? "未知曲目")
                    .font(.headline)
                Text(track.artist ?? "未知艺术家")
                    .font(.subheadline)
                    .foregroundColor(.secondary)
            }
        }
    }
}

方案优势 #

• 轮询逻辑与视图生命周期完全解耦，单例仅在应用首次启动时初始化一次，不会因为视图切换、全屏操作重复创建timer
• 内部自动管理前后台启停，进后台自动销毁timer减少资源占用，回前台自动恢复轮询，不会出现任务丢失的问题
• 基于ObservableObject的状态推送机制，数据更新后视图自动刷新，比手动读写UserDefaults效率更高，也完全符合SwiftUI的单向数据流设计
• 所有播放相关的业务逻辑收敛在同一处，后续修改轮询间隔、新增状态字段都不需要改动视图代码，维护成本更低

为什么不推荐放在AppDelegate #

如果你的应用采用SwiftUI原生生命周期，默认不会创建AppDelegate文件，强行添加AppDelegate承载逻辑反而会割裂生命周期管理；即便你用了UIKit生命周期的AppDelegate，依然需要解决状态同步的问题，最终还是要实现一套类似的状态管理逻辑，属于冗余的兼容写法，不是当前场景的最优解。

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