我最近在我的应用中遇到了一些内存管理问题。
该应用程序利用了一些高质量的图像，这极大地增加了内存使用量。
以下是有关项目和图像详细信息的一些信息，以使问题更加清晰：
我的项目中添加了大约90张图片。其中一半设计为@ 2x尺寸，以支持新iPad Retina显示屏。因此，每台设备的最大图像数量约为45个。
所有图像的Retina版本的总大小约为25兆字节（每个单独图像的大小可在10 KB到6.8 MB之间变化）。同时，所有标准图像的大小等于11兆字节。
项目的XCode档案大小等于44兆字节。
标准版图像中个人图像的最大分辨率约为1500x4000像素，而最小分辨率约为60x60像素。
Retina版图像中个人图像的最大分辨率约为3000x8000像素，而最小分辨率约为120x120像素。
Retina版图片的名称后缀为“@ 2x~ipad”，其他名称后缀为“~ipad”。
在应用生命周期中只创建了大多数图片的一个实例。
大约25张图片在应用启动期间加载，其余图片在游戏过程中加载。
我使用[UIImage imageNamed：@“image_name.png”]无论我想加载图像（使用[UIImage imageWithContentsOfFile]和[UIImage imageWithData]效率极低）。
但这里有问题：
当我使用Instruments跟踪内存使用情况时，我发现应用程序的内存使用率非常高。以下是不同情况下内存分配的统计信息：
在启动时使用标准图像在iPad 2上分配内存：58 MB
在游戏过程中使用标准图像在iPad 2上分配内存（加载所有图像时）：131 MB
为什么分配内存的想法比图像的总大小要高很多？
答案 0 :(得分：0)
这可能是因为您使用的图像是使用png或jpg压缩的，而当解码到内存时，图像的大小远远大于原始文件的大小。无论图像内容如何，它都会占用宽度*高度* 4字节的内存。
答案 1 :(得分：0)
一个开始就是不使用-[UIImage imageNamed:]来获得符合任何资格的图像：
但您需要注意这些更改如何影响您的计划。你现在正在尽可能地依赖记忆。我的建议是将其中一些责任转移到其他领域。分配负载使其仍然感觉很快，但具有更好的资源平衡。一旦你使用较少的缓存，你会发现你最终可能会多次阅读和扩展一些文件。然后尝试找出你应该分享你加载的图像的位置。当然，只加载你需要的东西。然后拿走你学到的东西，看看它可以应用到你的其他图像。
另外，打破你的图像 - 你的图像比显示器的尺寸大几倍。如果它们需要那么大，那么就把它们拆开 - 如果它们只是在展示时缩小，那么在分发前调整它们的大小（例如它们不需要缩放 - 显示速度会快得多，看起来好多了，并消耗更少的内存。）