SwiftUI与Firebase联动的MVVM架构下PlayerViewModel大量驻留内存问题求助

你遇到的百万级PlayerViewModel实例堆积、内存爆涨的问题，不是单纯靠加几个weak修饰就能解决的，是三个层层叠加的泄漏点共同导致的，按影响程度排序：

• Firestore快照监听器完全没有生命周期管理：addSnapshotListener返回的注册句柄没有被存储，每次调用loadData都会创建一个永久驻留的后台监听器，没有任何机制能移除它。
• PlayerViewModel存在100%的循环引用链：Combine的订阅和闭包强持有VM实例，就算VM从数组里被移除，也永远不会被系统回收。
• PlayerListViewModel的VM映射逻辑无差量复用：每次收到球员数据更新就全量新建一套PlayerViewModel，旧的VM因为循环引用根本释放不掉，实例数会随监听器数量、数据触发次数线性堆积，最终突破百万量级。

1. Firestore监听器泄漏的原理 #

你现在调用addSnapshotListener时，方法返回的ListenerRegistration对象是控制监听器生命周期的唯一入口：只要不调用这个对象的remove()方法，监听器就会一直保持和Firestore服务的长连接，持续接收数据变更事件。
因为你的PlayerRepository是单例，只要页面反复进入、切球队时多次调用loadData，就会无限叠加监听器。每个监听器只要收到任何一次数据变更，就会触发闭包给$players发布新的数组值，直接触发下游VM的批量创建。
按你现在的实例规模反推，大概率loadData被重复调用了上百次，叠加出上百个常驻监听器，每个监听器每次触发都会批量生成VM，最终堆出百万级实例。

2. PlayerViewModel的循环引用锁 #

你现在写的VM初始化代码里，有三处会形成强引用循环，导致VM无法释放：

• assign(to:on:) 方法会强持有传入的目标对象（也就是self）。你在VM里写的两个assign订阅，被VM自己的cancellables集合持有，形成“VM → cancellables → 订阅 → VM”的闭环。
• 带防抖的sink闭包没有做弱引用捕获，直接强抓了self，同样被存到cancellables里，又加了一层循环引用锁。
  这意味着只要VM被创建，哪怕被从playerViewModels数组里删除，也没有任何内存回收的可能，全部驻留到进程结束。

3. 全量VM重建的放大效应 #

你在PlayerListViewModel里的管线逻辑，只要repository.$players发任何一次新值，就会把数组里的所有DBPlayer直接map成全新的PlayerViewModel，完全不对已经存在的VM做复用。
哪怕只是1个球员的1个字段触发了snapshot更新，你也会把当前所有球员对应的VM全部销毁重建，叠加循环引用的问题，这些新建的VM一个都不会被释放，内存占用会随着每次snapshot触发线性上涨。
另外你在PlayerListViewModel里同样用了assign(to:on:) 绑定到self，这个方法的强持有特性会让列表VM本身也无法释放，连带它持有的所有PlayerViewModel全部驻留内存，进一步放大泄漏规模。

第一步：给Firestore监听器加生命周期管控 #

修改PlayerRepository代码，存储当前的监听器注册对象，每次加载前清理旧监听器：

class PlayerRepository: ObservableObject{
    static let shared = PlayerRepository()
    var db = Firestore.firestore()
    @Published var players = [DBPlayer]()
    @Published var chosenPlayer: DBPlayer? = nil
    // 新增：存储当前球员列表的监听器
    private var playersListener: ListenerRegistration?

    func loadData(teamID: String){
        let userID = Auth.auth().currentUser?.uid
        // 新增：移除之前的旧监听器，避免重复叠加
        playersListener?.remove()
        
        playersListener = db.collection("players")
            .order(by: "name")
            .whereField("userID", isEqualTo: userID!)
            .whereField("teamID", isEqualTo: teamID)
            .addSnapshotListener { (querySnapshot, error) in
                // 原有snapshot处理逻辑保持不变
                if let querySnapshot = querySnapshot{
                    self.players = querySnapshot.documents.compactMap { document in
                        do{
                            let x = try document.data(as: DBPlayer.self)
                            return x
                        }
                        catch{
                            print(error)
                        }
                        return nil
                    }
                }
            }
    }
    
    // 可选：在不需要监听时（比如退出球员模块）手动移除监听器
    func stopListening(){
        playersListener?.remove()
        playersListener = nil
    }
}

第二步：拆掉PlayerViewModel的循环引用 #

首先删掉完全没必要的两个assign订阅，把原来的Published属性改成计算属性，从根源上消除循环引用：

class PlayerViewModel: ObservableObject, Identifiable{
    @Published var playerRepository = PlayerRepository.shared
    @Published var player: DBPlayer
    // 删掉原来的Published playerName、id，改成计算属性
    var id: String { player.id ?? "" }
    var playerName: String { player.name }
    
    private var cancellables = Set<AnyCancellable>()
    
    init(player: DBPlayer){
        self.player = player
        // 原来的两个assign代码全部删除，不需要多余的绑定管线
        
        // 修改sink闭包，用[weak self]打破强引用
        $player
            .dropFirst()
            .debounce(for: 0.8, scheduler: RunLoop.main)
            .sink { [weak self] player in
                self?.playerRepository.updatePlayer(player)
            }
            .store(in: &cancellables)
    }
}

这个修改的效果是：VM不再被自己的Combine订阅强持有，只要从playerViewModels数组里移除，系统就能正常回收内存。

第三步：改差量VM复用逻辑，避免全量重建 #

修改PlayerListViewModel的绑定逻辑，替换掉会产生强引用的assign(to:on:)，改用带弱引用捕获的sink，同时实现VM差量复用：

class PlayerListViewModel: ObservableObject{
    @Published var playerRepository = PlayerRepository.shared
    @Published var playerViewModels = [PlayerViewModel]()
    
    private var playerCancellables = Set<AnyCancellable>()
    
    init(){
        playerRepository.$players
            // 避免内容无变化的数组重复触发刷新
            .removeDuplicates()
            .sink { [weak self] players in
                guard let self = self else { return }
                // 按id建立现有VM的查找表
                let existingVMs = Dictionary(
                    uniqueKeysWithValues: self.playerViewModels.map { ($0.id, $0) }
                )
                // 遍历新的球员数组，差量生成VM列表
                self.playerViewModels = players.map { player in
                    // 找到已存在的VM就更新数据，没找到就新建
                    if let vm = existingVMs[player.id ?? ""] {
                        vm.player = player
                        return vm
                    } else {
                        return PlayerViewModel(player: player)
                    }
                }
            }
            .store(in: &playerCancellables)
    }
}

• 永远只有一个Firestore监听器在跑，不会无限叠加后台连接
• 所有PlayerViewModel没有循环引用，不需要的实例会被正常回收
• 每次数据更新只会给新增的球员创建VM实例，不会全量重复创建，从根源上消除百万级实例堆积的可能
• 内存峰值会回落到正常的几十MB级别，不会再出现8GB的异常占用

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