iOS ARC ram只能成长

如果记忆继续上升,它可能是各种不同的东西,但"强参考周期"是主要的嫌疑人.可悲的是,这也不一定会出现在仪器的泄漏工具中.

在Allocations工具中执行快照/生成,并确定未发布的内容(特别是如果它包含任何类)并从那里开始.具体来说,按照其步调运行应用程序,然后标记快照/生成,执行更多操作,然后标记另一个快照/生成.查看第二个快照,查看自上一个快照以来捕获的内容(但未发布),重点关注您的类.你会很快找到罪魁祸首.

请参阅WWDC视频iOS App性能:内存进行实际演示.

例如,这是一个健康的应用程序,我通过仪器的"泄漏"工具进行了分析,但我将专注于"分配"工具:

在这个配置文件中,我等待应用程序安静下来,点击"Mark Generation"按钮(产生"Generation A",我的时间轴中的第一个标志).然后我去了一个观点,然后解散了它,再次做了"Mark Generation",得到了"B代"."增长"专栏告诉我,在A代和B代之间,消耗了100kb,但没有发布.但我并不担心这个问题,因为UIKit元素可能会有一些iOS内部缓存.所以,我再一次重复这个过程来获得"C代".现在这很有趣,现在报告的增长率仅为8.26kb,这可以忽略不计.这与Leaks仪器的清洁健康状况相结合,让我对任何严重记忆问题的风险感到非常满意.

现在,让我们将其与一些存在严重问题的"强参考周期"的代码进行对比:

现在这是一个完全不同的画面,即使这个过程是相同的"现在和解散"过程,重复两次.现在告诉我,我的世代之间增长了14mb,更值得注意的是,我可以清楚地看到有问题的增长曲线.值得注意的是,虽然Allocations工具显然正在解决一个严重的问题,但Leaks工具没有任何报告.

现在,在实践中,使用Allocations工具的实际经验可能会介于这两个极端之间.您的应用程序可能有自己的缓存或模型对象慢慢占用内存,但如果您正确响应内存警告,您应该恢复该内存.但坦率地说,大多数设计良好的应用程序根本不应该生成内存警告(通常通过正确配置缓存,避免imageNamed适当的情况,移动到大型或不常访问的数据的持久存储等来实现).目标是达到应用程序稳定在一些合理的基线内存分配水平附近的点,始终返回到该基线.

但是,在您对应用程序进行基本概要分析并诊断出您所拥有的各种内存问题之前,我们无法为您提供建议.