这有多糟糕？在30秒内
问题描述：
分配在编码基于物理的游戏3GB的总字节数，我已经创造了一切，从子类NSObjects。力矢量被存储在NSArrays每个粒子对象，那么加速度，速度和位置在与CADisplayLink 60fps的计算。这有多糟糕？在30秒内
的一个版本是不是意味着要进行优化，但它似乎运行得很好。 CADisplayLink快速且一致。但是，当我查看分配统计数据时......我从来没有见过这样的事情。 ARC做了伟大的工作，在保持在1兆字节实时字节，但是这件事情经过6场演出的整体分配的碎纸分钟。
所以我的问题是：
这是危险的代码，为长时间在设备上运行？这有多“坏”？如果我继续像这样开发，苹果是否会接受这个或者我会炒iPad？
答
优化以最小化分配的吞吐量是采用一个非常有效的方法。
值得注意的是，每次分配很可能将需要在大部分配置中的字节被触动，可能一些写入和读出许多，每每一个字节的分配。所有这些读/写都需要系统总线上的CPU周期和事务。
所以，是的，它会吃电池，并会增加系统温度。尽管如此，烧毁设备不太可能。 :)
排序由“#Transitory”，并开始思考如何消除暂时性的拨款。我通常最初忽略了各种MalloC## Bytes分配，因为这些分配通常是在某些类的实例中支持的商店。消除暂时的实例和malloc的数量也会下降。
对于任何给定的分配类型，您可以通过点击看到该类型的所有拨款创建的列表。按功能名称排序，然后感受最常用的功能。针对您的优化。
使用这种方法，我已经能够大规模优化一些大型的应用程序;有时通过简化分配率将某些操作的执行时间缩短75％以上！
这可能会耗尽任何设备的电池它试图使用的应用程序非常迅速，如果任何可能会引起与苹果的关注。 –
分配工具不是很好。看看VM跟踪器之一。 – Macmade
分配工具太棒了。 VM跟踪器只有在映射/取消映射大量数据时才有用。由于大多数地图/非地图事件将与分配相关联，因此无论如何，最好关注分配率。 – bbum