在编写基于物理的游戏时，我从子类 NSObjects 创建了所有内容。每个粒子对象的力向量存储在 NSArrays 中，然后使用 CADisplayLink 以 60fps 的速度计算加速度、速度和位置。
版本 1 并不意味着要进行优化，但它似乎运行得很好。CADisplayLink 快速且一致。但是，当我查看分配统计信息时……嗯，我从未见过类似的情况。ARC 在将 Live Bytes 保持在 1 兆字节以下方面做得很好，但是这东西正在通过每分钟 6 gig 的整体分配来粉碎。
所以我的问题是：
这段代码在设备上长时间运行是否危险？这有多“糟糕”？如果我继续这样开发，苹果会接受这个还是我会炒 iPad？
优化以最小化分配吞吐量是一种非常有效的方法。
值得注意的是，每次分配都可能需要访问分配中的大部分字节，可能是分配中的每个字节，可能需要少量写入和多次读取。所有这些读/写都需要跨系统总线的 CPU 周期和事务。
所以，是的，它会消耗电池并增加系统温度。但是，烧毁设备的可能性不大。:)
按“#Transitory”排序并开始弄清楚如何消除临时分配。我最初通常会忽略各种 Malloc ## Bytes 分配，因为它们通常是某些类的实例中的后备存储。消除临时实例和 malloc 的数量也下降。
对于任何给定的分配类型，您可以单击查看所有该类型分配的创建位置列表。按函数名称排序，然后感受一下最常用的函数。在那里定位您的优化。
使用这种方法，我已经能够对一些大型应用程序进行大规模优化；有时通过简单地最小化分配率将某些操作的执行时间减少 75% 以上！