iOS Swift开发无内存泄漏时内存持续上涨是否需要担忧？

结论 #

这种情况绝大多数情况下无需过度担忧，你观测到的内存上涨基本都属于系统层面的合理缓存占用，不是你业务代码导致的内存泄漏。

具体原因解释 #

• 首先你已经通过多个维度排除了自身代码的泄漏问题：所有自定义VC的deinit正常调用、Instruments Leaks工具无泄漏报警、甚至空项目也能稳定复现该现象，已经可以完全排除你代码写法错误导致的泄漏问题。
• 你观测到的内存增长，大多来自UIKit内部的全局缓存：比如渲染资源缓存、系统组件的复用缓存、高频UI操作下自动释放池的延迟排空。这类缓存本身的设计目的就是提升UI响应速度，系统会在App收到内存警告时自动释放这部分空间，不会无限占用内存。
• 你的测试场景属于极端操作：普通用户完全不可能做到10000次连续的VC弹出销毁操作，高频重复操作下系统会倾向于保留更多缓存避免重复创建资源，自然会出现内存持续小幅上涨的表现，这是系统的性能优化策略，不是问题。

验证方法 #

你可以通过以下操作进一步确认没有问题：

1. 在SecondVC的deinit方法中添加打印日志，确认每次dismiss后SecondVC的实例都会被销毁，只要deinit正常触发，你自己写的业务代码占用的内存就已经完全释放。
2. 用Instruments的Allocations工具筛选你自定义的类，观测VC实例的存活数量，dismiss后SecondVC的存活数回到0就完全正常。
3. 测试过程中当内存上涨到较高值时，点击Xcode调试栏的「模拟内存警告」按钮，观测内存回落幅度，如果内存明显下降，就可以确认上涨部分全部是可释放的系统缓存。

实际项目的处理建议 #

你提到实际项目同测试后内存涨到162MB，完全在iOS系统的安全内存区间内：

• 只要正常用户使用过程中内存不会无限持续上涨、不会出现因为内存过高导致的系统杀进程、后台挂起后不会被频繁回收，就不需要做额外处理。
• 不要以极端测试场景的内存数值作为优化依据，应该以普通用户连续使用1-2小时的内存走势作为判断标准，正常使用下内存稳定在一个波动区间就没有问题。

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