性能方面：很多小型PNG或一个大型PNG？

Question

为iPhone开发一款简单的游戏，能带来更好的性能吗？

1. 为我的UIViews的背景使用了很多小的（10x10到​​30x30像素）PNG。
2. 使用一个大型PNG并剪切到我的UIViews边界。

我的想法是，第一种技术需要每个UIView更少的内存，但是复杂化了iPhone处理大量图像的方式，因为它试图将图像组合成更大的纹理或尝试在所有小纹理之间切换很多。

另一方面，第二种技术让iPhone有机会处理一个大的PNG，但是每个UIView必须携带的图像重量会增加。

• 我对iPhone的尝试是否正确，按照我描述的方式处理图像？
• 那么，该怎么办？

到目前为止看到答案，仍有疑问。似乎需要权衡两个参数：复杂性和CPU密集型编码。 决定使用哪种技术的转折点是什么？

Answer 1

如果您最终引用相同的CGImageRef（例如通过共享UIImage *），则不同视图将不会多次加载图像。这是videowall Core Animation demo at the WWDC 07 keynote使用的技术。这是OSX代码，但UIViews与CALayers非常相似。

核心图形处理图像的方式（无论如何我的观察）都经过大量调整，以便及时加载并在内存紧张时积极释放。

如果CGImageRef指向的解码图像的内存已由系统回收，则使用大图像最终可能会在绘制时加载图像。

有什么区别不是你有多少张图片，而是UIKit遍历你的代码的频率。

如果您要求（-setNeedsDisplay），UIViews和Core Animation CALayers都会重新绘制，而瓶颈通常是您的代码，并将渲染的内容转移到图形芯片的纹理中。

所以我的建议是以一种允许一起更改的部分同时更新的方式来考虑你的UIView布局，这会变成单个纹理上传。

Answer 2

一张大图片主要为您提供更多工作和更多头痛。维护起来比较困难但可能不那么严格，因为内存中只有一个结构+数据而不是许多结构+数据。 （虽然可能还不足以注意到）。

在常规Mac OS上查看.app软件包的内容，通常认可的存储方法是每个图像一个文件/资源​​。

当然，这假设您没有从网络获取图像资源，其中瓶颈将是http及其指定的最多两个并发请求。

Answer 3

一个大号为您提供更好的表现。 （原因是你应该渲染所有图片）。

Answer 4

一张大图像将消除与打开和操作内存中的许多图像相关的任何开销。

Answer 5

我想说这个问题没有权威性的答案。单个大图像减少（慢速）闪存访问并一次性完成解码，但是许多较小的图像可以让您更好地控制处理时发生的事情...但是它的内存很耗尽，您必须将图像切片或掩饰它。

您必须实施一个解决方案并进行测试。如果它不够快并且您无法优化，请实施另一个。我建议实现你个人觉得更容易想象实现的版本，因为这将是最容易实现的。