SwiftUI应用内存泄漏排查求助：系统库为责任库的原因及方向

嘿，我太懂你这种困惑了——当Instruments把内存泄漏的锅甩给SwiftUI这类系统库时，第一反应肯定是“难道是苹果的bug？”但绝大多数情况下，我们的代码才是触发这类泄漏的导火索。下面给你拆解下可能性和具体的排查方向：

先明确：系统库≠系统Bug #

Instruments显示责任库是系统库，只是说明泄漏的对象属于系统框架，但触发泄漏的根源往往在我们的代码里——比如我们的代码创建了强引用环，导致系统框架里的关联对象无法被正确释放。

核心排查方向 #

1. 闭包捕获循环（SwiftUI里最常见的坑） #

SwiftUI的各类回调闭包（比如onTapGesture、task、onAppear）很容易不小心形成强引用环：

• 比如你在闭包里直接使用self（或者间接引用了ViewModel里的属性），却没添加[weak self]或[unowned self]的捕获列表；
• 再比如ViewModel里的闭包同时捕获了自身和SwiftUI的View对象，导致两者互相持有，连带系统库的内部视图资源无法释放。
• 排查动作：逐行检查所有带闭包的SwiftUI回调，确认捕获列表是否正确，避免不必要的强引用。

2. ObservableObject的生命周期管理错误 #

@StateObject、@ObservedObject、@EnvironmentObject的误用是SwiftUI内存泄漏的重灾区：

• 比如在根视图里用@ObservedObject创建ViewModel，而不是@StateObject（后者会绑定View的生命周期，前者可能被重复创建或无法销毁）；
• 或者把ViewModel传递给了全局单例、长期存活的对象，导致ViewModel无法被释放，进而牵连系统库中关联的视图对象泄漏。
• 排查动作：检查所有ViewModel的声明，确保根视图用@StateObject，子视图用@ObservedObject/@EnvironmentObject，避免不必要的全局持有。

3. Combine订阅未正确清理 #

SwiftUI深度依赖Combine框架，订阅管理不当很容易引发泄漏：

• 比如在ViewModel的init里创建了Combine订阅，但没有把AnyCancellable实例存储到Set<AnyCancellable>中；
• 或者手动创建的PassthroughSubject/CurrentValueSubject被长期持有，没有在合适时机取消订阅。
• 排查动作：检查所有Combine订阅代码，确保每个订阅都通过store(in: &cancellables)存储，并且在View销毁或ViewModeldeinit时清理。

4. 跨框架自定义View的资源泄漏 #

如果你用UIViewRepresentable/NSViewRepresentable封装了UIKit/AppKit组件，很容易因为生命周期处理不当导致泄漏：

• 比如在updateUIView里重复添加子视图，或者没有在disassembleUIView（或类似清理方法）里移除代理、闭包引用；
• 或者在自定义View里持有了SwiftUI的环境对象，却没有用弱引用管理。
• 排查动作：检查所有跨框架自定义View的实现，确保生命周期方法里的资源都被正确清理，代理和闭包都使用弱引用。

5. 系统已知Bug（最后考虑） #

确实存在部分SwiftUI版本有已知的内存泄漏问题，比如某些版本的List、NavigationStack在特定布局下的泄漏。

• 排查动作：先升级到最新的iOS/macOS版本，看看泄漏是否消失；如果还是存在，可以去苹果开发者反馈系统搜索类似问题，确认是否是官方已记录的Bug。

实用排查小技巧 #

• 用Instruments的Leaks工具展开“Call Tree”，查看系统库调用栈的起点——很多时候会指向你写的某个方法或闭包，顺着这个线索找问题；
• 给ViewModel和关键View添加deinit打印：deinit { print("\(Self.self) deinit") }，如果某个对象没有触发deinit，说明它被强引用了，顺着引用链排查；
• 最小化测试：创建一个极简Demo，只保留疑似泄漏的代码片段，看看泄漏是否复现——快速定位是代码问题还是系统问题。

总结一下，先从闭包引用、ViewModel生命周期、Combine订阅这几个方向入手排查，90%以上的情况都是我们的代码写法导致的系统库对象无法释放。如果排查完这些都没问题，再考虑系统Bug的可能性。

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