我的 ipod 中有一个应用程序。
1.打开app，查看内存Instruments（Activity monitor），8.95M
2.点击一个按钮，它会在屏幕上添加一个大图的UIImageView，现在内存是17.8M。
3.从屏幕上移除UIImageView，稍等一下，现在内存是9.09M。
我确信 UIImageView 在从屏幕上移除后会被释放。这是非常简单的代码。所以当它被删除时，应用程序的状态应该与添加 UIImageView 添加到屏幕之前一样，对吗？但是为什么内存是9.09M而不是8.95M呢？如果在屏幕上添加更复杂的 View，区别就更明显了。
这个是正常的。这是由于“延迟增长，延迟收缩”算法。这意味着您拥有一个可以针对少量项目或大量项目调整大小的数据结构。少量项目的大小调整使用非常少的内存，但在处理大量项目时效率不高。大数字的大小对于管理大量事物的集合非常有效，但会使用更多内存来索引对象。
“惰性增长，惰性收缩”算法试图避免调整结构索引大小的成本，方法是仅在索引太小时才增加索引，而在索引太大时才收缩它。例如，一个典型的算法可能仅在其理想大小至少是其理想大小的三倍时才会增大索引，而仅当它超过其理想大小的三倍时才可能缩小它。如果应用程序快速分配和释放资源集合，这也是防止大量调整大小操作所必需的——您希望索引大小有点“粘性”。
当您打开大对象并使用 GUI 对象时，您会使索引变得太小，并且它会增长。但是当你关闭大对象时，你只会让索引有点太大，所以它不会缩小。
如果设备受到内存压力，索引将缩小。如果应用程序继续减少其对 UI 资源的使用，则索引将缩小。如果应用程序使用更多的 UI 资源，则索引不需要很快再次增长。
一个很好的类比可能是你桌上的一摞纸。如果您可能需要查找 30 篇论文，则可以将它们分成 4 叠。但是如果你有 5,000 篇论文，4 叠就会使搜索变得乏味。在这种情况下，您将需要更多的堆栈。因此，当论文的数量对于 4 叠来说太大时，您需要重新索引到更多的叠中。但是当数量变小时，你不会费心不断地重新索引，直到你有太多的堆栈，因为搜索仍然很快。
当你处理完所有这些文件后，你的办公桌就会多出几叠。这样可以避免它在下次需要处理大量论文时重新编制索引。